2009-09-03 2 views
4

Ich habe ein Projekt, das aus mehreren Maven-Modulen besteht, die alle Kinder eines Elternmoduls sind. Ich habe das übergeordnete Element eingerichtet, um Checkstyle zu verwenden, und alle unterordneten Module erben dieses Verhalten ordnungsgemäß. Ich möchte, dass alle Kindmodule die Eltern-Unterdrückungsdatei verwenden, die in ihrem Plugin definiert ist. definiere ich eine Eigenschaft checkstyle.suppression dieWie verwendet man eine einzige Checkstyle-Unterdrückungsdatei in Maven für alle Module

<properties> 
    <checkstyle.suppressions>${basedir}\src\checkstyle\suppressions.xml</checkstyle.suppressions> 
</properties> 

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-checkstyle-plugin</artifactId> 
    <version>2.2</version> 
    <configuration> 
     <configLocation>config/sun_checks.xml</configLocation> 
     <suppressionsLocation>${checkstyle.suppressions}</suppressionsLocation> 
     <suppressionsFileExpression>${checkstyle.suppressions}</suppressionsFileExpression> 
    </configuration> 
    </plugin> 
</plugins> 

im check Plugin verwendet wird, die für die Eltern gut funktioniert, aber alle Kind-Module versuchen, die Datei in ihrem basedir zu finden, die sinnvoll ist.
Ich bin mir sicher, dass es eine einfache Lösung geben muss, die ich vermisse, aber gibt es eine Möglichkeit, diesen Ort zu definieren, so dass alle untergeordneten Module den übergeordneten Speicherort verwenden, ohne ihn hart zu codieren?

Antwort

11

Die Antworten oben gefährlich sind. Ich behaupte, dass jedes Projekt in sich abgeschlossen sein sollte, so dass die Bezugnahme auf externe Dateien früher oder später einen Build sprengen wird. Checkstyle kann eine URL für die Datei nehmen, aber das bedeutet, dass Sie nicht offline erstellen können. Ein besserer Ansatz besteht darin, Ihre Datei zu packen (kann auch pmd.xml hinzufügen) und sie dann dem Klassenpfad des Checkstyle (oder pmd) -Plugins hinzuzufügen. Ich habe ein Beispiel dafür here und mehr über das Überschreiben eines Plug-in Klassenpfad here

+0

Danke Brian für diese Ressource, ich werde es für die zukünftige Verwendung Lesezeichen: Dies ist genau das, was ich brauchte, da ich keinen festen Speicherort für eine der Ressourcen aufgrund der Tatsache definieren wollte, dass Entwickler es überprüfen können Standort- und Build-Maschinen haben auch unterschiedliche Standorte und Dateisysteme. Wie im Beispiel werden die Ressourcen mit dem Assembly-Plugin gebündelt und dann wird es entpackt und in den untergeordneten Modulen verwendet. Dank –

+0

+1 sollten Sie vermeiden, Konfigurationen zu haben, die auf der lokalen Dateisystemstruktur basieren –

+0

Dieser Fehler: https://issues.apache.org/jira/browse/MCHECKSTYLE-228 macht es derzeit unmöglich, 'suppressions.xml' zu verwenden von einem JAR, leider. –

0

Haben Sie versucht, die Eigenschaft so in der Eltern Pom zu definieren oder in den Kindern neu zu definieren?

<properties> 
    <checkstyle.suppressions>${parent.project.basedir}\src\checkstyle\suppressions.xml</checkstyle.suppressions> 
</properties> 
+0

Ich habe dies versucht, aber da es immer Null zurückgibt, vielleicht weil es nur auf dem Eltern erklärt wird.
Wenn ich den Maven mit -X (Debug) ausführen, kann ich sehen, dass dieser Wert null ist. –

0

Wenn die Eltern werden nicht check laufen, können Sie nur in der Lage sein, es zu umschreiben zu

<properties> 
    <checkstyle.suppressions>..\..\src\checkstyle\suppressions.xml</checkstyle.suppressions> 
</properties> 

Oder so etwas. Oder Sie könnten etwas in settings.xml einfügen, um alles auf ein systemweites Konfigurationsverzeichnis zu verweisen.

Obwohl dies möglicherweise nicht empfohlen wird, können Sie ein Boot-Strap- oder Setup-Projekt oder eine Aufgabe verwenden, eine Kopie der Datei suppressions.xml an einen Speicherort in einer Eigenschaft in settings.xml kopieren und dann immer verweisen dazu an diesen Orten.

+0

Die Gründe, die dies für mich nicht funktioniert, ist Ich deklariere nicht das Checkstyle-Plugin in den untergeordneten Modulen (vielleicht sollte ich), so dass diese Eigenschaft im übergeordneten und die untergeordneten Module unterschiedliche Verzeichnistiefen festgelegt werden können: so Ich könnte haben Eltern> webservices> cxf> sso und sagen parent> Sicherheit> sso Ich könnte das Plugin in jedem Modul definieren und diese Notation verwenden, aber ich würde es nicht bevorzugen. Ich könnte es in der settings.xml definieren, aber dies beschränkt uns darauf, zu einem vordefinierten Speicherort auschecken oder daran zu erinnern, es zu ändern, wo Sie die Quelle heraus überprüfen. –

+0

Die Problemumgehung für eine XML-Lizenzdatei bestand darin, dass Benutzer sie nach $ home/.m2/license.xml kopieren und die Einstellungsdatei auf diese Datei verweisen ließ. Wir haben auch ein Setup-Projekt verwendet, das diese Datei heruntergeladen und in das Verzeichnis $ home/.m2/gestellt hat. Das könnte helfen. – sal

Verwandte Themen