2016-06-24 17 views
2

Ich habe ein Multi-Modul-Projekt, in dem eine der beiden Submodule von der anderen abhängig ist. This question bedeutet, dass mvn install sich um diese Abhängigkeiten kümmern soll.Multi-Modul Maven-Abhängigkeit mit Repository, nicht lokal auf Travis CI

Alles funktioniert auf lokaler Ebene auf meinem Rechner (sowohl in Eclipse als auch in der Befehlszeile). Wenn ich jedoch das Modul aktualisiere, das den Code ändert, den das zweite Modul benötigt, und mich in mein github-Repository festlege, schlägt das zweite Modul den Travis-CI-Build fehl. Ich habe das Problem auf die Tatsache zurückgeführt, dass es seine Abhängigkeit von einem Repository herunterlädt, anstatt das gerade kompilierte zu verwenden.

Das Problem ist sehr ähnlich zu the one reported in this question, mit der Ausnahme, dass ich anstelle von meinem lokalen Repository mit dem Travis CI automatisierten Build beschäftigen. Die Kommentare und Antwort auf diese Frage zeigen, dass:

The dependency has a snapshot version. For snapshots, Maven will check the local repository and if the artifact found in the local repository is too old, it will attempt to find an updated one in the remote repositories.

jedoch in diesem Fall „zu alt“ nicht gelten. Das lokale Artefakt wurde buchstäblich gebaut. Es sollte Sekunden alt sein.

Hier sind die entsprechenden Abschnitte pom.xml des oshi-json Modul, auf oshi-core die Abhängigkeit der Feststellung (beide ihre Versionsnummer mit dem Elternteil):

<parent> 
    <groupId>com.github.dblock</groupId> 
    <artifactId>oshi-parent</artifactId> 
    <version>3.0-SNAPSHOT</version> 
</parent> 

<artifactId>oshi-json</artifactId> 
<packaging>jar</packaging> 

<name>oshi-json</name> 

<dependencies> 
    <dependency> 
     <groupId>${project.groupId}</groupId> 
     <artifactId>oshi-core</artifactId> 
     <version>${project.version}</version> 
    </dependency> 
</dependencies> 

und einen Auszug aus dem Eltern pom.xml :

<groupId>com.github.dblock</groupId> 
<artifactId>oshi-parent</artifactId> 
<version>3.0-SNAPSHOT</version> 
<packaging>pom</packaging> 

<name>oshi-parent</name> 

<modules> 
    <module>oshi-core</module> 
    <module>oshi-json</module> 
</modules> 

Die vollständigen Dateien sind hier:

Relevante Auszüge aus den Protokolldateien finden Sie weiter unten. Ein vollständiges Beispiel für eine failed Travis CI build can be found here. Beachten Sie, dass das Symptom (Kompilierungsfehler) darauf zurückzuführen ist, dass Travis den neuesten Snapshot für oshi-core verwendet, der die in oshi-json referenzierte Klasse nicht enthält. Die Klasse befindet sich jedoch in der übergebenen Pull-Anforderung und kompiliert (und erstellt mit mvn install) lokal.

Wenn ich ein neues commit machen, Travis die Build ausführt, wie folgt:

$ mvn install -DskipTests=true -Dmaven.javadoc.skip=true -B -V 

Der Reaktor anordnet richtig die um baut:

[INFO] Reactor Build Order: 
[INFO] 
[INFO] oshi-parent 
[INFO] oshi-core 
[INFO] oshi-json 

Die Mutter baut und dann oshi-core aufbaut, Speichern des kompilierten Codes lokal:

[INFO] Building jar: /home/travis/build/dblock/oshi/oshi-core/target/oshi-core-3.0-SNAPSHOT.jar

Dies ist die j Ich möchte das nächste Modul abhängig machen.Wenn jedoch die oshi-json Build beginnt, es stattdessen lädt das Artefakt von Maven statt:

[INFO] Downloading: https://oss.sonatype.org/content/repositories/snapshots/com/github/dblock/oshi-core/3.0-SNAPSHOT/oshi-core-3.0-20160624.032041-9.jar

[INFO] Downloaded: https://oss.sonatype.org/content/repositories/snapshots/com/github/dblock/oshi-core/3.0-SNAPSHOT/oshi-core-3.0-20160624.032041-9.jar (199 KB at 708.5 KB/sec)

EDIT: Gerade bemerkt die folgende Warnung, die kurz vor dem Download auftritt, die nicht relevant sind oder nicht (an error in Travis settings aber), dass die Warnung Fixierung löst immer noch nicht mein Problem, here's a failed build without the warning:

[WARNING] Failure to transfer com.github.dblock:oshi-core:3.0-SNAPSHOT/maven-metadata.xml from https://nexus.codehaus.org/snapshots/ was cached in the local repository, resolution will not be reattempted until the update interval of codehaus-snapshots has elapsed or updates are forced. Original error: Could not transfer metadata com.github.dblock:oshi-core:3.0-SNAPSHOT/maven-metadata.xml from/to codehaus-snapshots (https://nexus.codehaus.org/snapshots/): nexus.codehaus.org

Dies ist ein vorübergehendes Problem im Zusammenhang nur mit Travis-CI; Das Pom-Setup wird funktionieren, sobald ich alle Module freigegeben habe, und ich kann es umgehen, indem ich lokal mvn clean deploy ausführe, um das neue oshi-core zum OSS-Repository zu schieben, damit Travis glücklich ist. Dies scheint jedoch ein schlechter Workaround zu sein.

Gibt es eine Möglichkeit, dass Travis CI das gerade kompilierte jar verwenden kann, anstatt ein neues herunterzuladen - und zwar so, dass der beabsichtigte Download der Abhängigkeit vom Repository nicht unterbrochen wird Sobald es veröffentlicht ist?

+0

Können Sie aus allen relevanten Modulen der pom geben Dateien sonst ist es schwer etwas Nützliches zu sagen. Während eines Multi-Modul-Builds sollte nichts von irgendwo heruntergeladen werden, da es aus dem Reaktor gelöst wird. – khmarbaise

+0

@khmarbaise Ich erweiterte die Auszüge und verlinkte mit den ursprünglichen Poms (und einem fehlgeschlagenen Build) auf meiner Github-Site. Sie können wahrscheinlich [upstream Projekt verzweigen] (https://github.com/dblock/oshi), um lokal zu experimentieren, wenn Sie möchten. –

Antwort

2

So Ok ich einen tieferen Einblick in Ihre Build genommen haben lassen Sie mich hier einige meiner Gedanken zusammenfassen:

Ich fand, dass Sie maven-clean-plugin mit unterschiedlichen Werten konfiguriert haben, die nicht notwendig sind, noch haben sie einen Vorteil haben. Gehen Sie mit Convention over Configuration Paradigma. Verstehe es nur, wenn du einen wirklich guten Grund hast (Um ehrlich zu sein, sehe ich keinen. Vielleicht kannst du es erklären).

Sie haben die Maven-Source-Plugin konfiguriert während des Standardlebenszyklus zu laufen, was bedeutet, es mit jedem mvn clean package oder mit mvn install laufen wird, die in der Regel nicht notwendig ist, werden Pakete Ursache Quelle in der Regel nur erforderlich, wenn Sie ein Release tun und Transfer nach Maven Central. Abgesehen davon haben Sie konfiguriert, das Ziel von maven-source-plugin jar zu verwenden, das den Lebenszyklus bildet, was bedeutet, einige Teile von Anfang an zu starten. Das Beste zu remove the forked life cycle goal. Am besten ist es, nur Quellpakete hinzuzufügen during the release run. (Bitte beachten Sie, dass Sie das Release-Profil deaktiviert haben).

Also komm zu maven-javadoc-plugin. Sie haben es so gebunden, dass es jedes Mal über mvn clean package oder mvn install läuft. Ich würde empfehlen, das nur während des site Lebenszyklusses zu laufen, weil es javadoc tooks viel Zeit erzeugt ...

Aus welchem ​​Grund haben Sie Konfiguration Wagen-ssh als Erweiterungen? Was ist der Zweck davon? Wenn es darum geht, die generierte Site zu Github besser zu veröffentlichen, nehmen Sie unter Maven SCM Publish Plugin viel more simpler and faster.

Sie haben auch maven-assembly-plugin mit einigen seltsamen Eigenschaften src.relative.loc konfiguriert. Wenn Sie wirklich einen einzelnen Deskriptor haben, der wiederverwendet werden kann, sollten Sie einen Blick in die documtation about shared descriptors werfen. Deklarieren von Maven-Montage-Plugin in die Mutter bedeutet, dass es für alle pom die ausgeführt werden, einschließlich der Eltern, die die folgenden Warnungen in Ihrem Build erzeugt:

[INFO] --- maven-assembly-plugin:2.6:assembly (oshi-assembly) @ oshi-parent --- 
[WARNING] Cannot include project artifact: com.github.dblock:oshi-parent:pom:3.0-SNAPSHOT; it doesn't have an associated file or directory. 
[INFO] Building tar: /Users/kama/ws-git-so/oshi/target/oshi-parent-3.0-SNAPSHOT-oshi-assembly.tar.gz 
[WARNING] Cannot include project artifact: com.github.dblock:oshi-parent:pom:3.0-SNAPSHOT; it doesn't have an associated file or directory. 
[INFO] Building tar: /Users/kama/ws-git-so/oshi/target/oshi-parent-3.0-SNAPSHOT-oshi-assembly.tar.bz2 
[WARNING] Cannot include project artifact: com.github.dblock:oshi-parent:pom:3.0-SNAPSHOT; it doesn't have an associated file or directory. 
[INFO] Building zip: /Users/kama/ws-git-so/oshi/target/oshi-parent-3.0-SNAPSHOT-oshi-assembly.zip 
[INFO]                   

Ah ... sehr wichtig: Sie sind mit dem Ziel assembly die ist veraltet und sollte nicht verwendet werden. Verwenden Sie das einzige vorhandene: single nichts anderes. Ursache assembly ist auch Gabelung des Lebenszyklus, die Ihren Build verlangsamt.

Ich bin mir nicht sicher, was Sie hier produzieren möchten? Ein binäres Verteilungspaket?Wenn ja, sollten Sie ein separates Modul erstellen, das so etwas wie oshi-dist genannt wird, das die Konfiguration von maven-assembly-plugin enthält und andere verteilungsbezogene Informationen wie Skripte usw. sein kann. Und dann sollte die Erstellung wie this gehandhabt werden. Dies hängt mit der Trennung von Bedenken zusammen. Warum sollte die generierte Site Teil davon sein?

BTW: Jedes Plugin, das in <build><plugins>... definiert ist, wird an alle Childs vererbt und wird ausgeführt, was normalerweise nicht der richtige Weg ist. Die ausgeführten Plugins sollten durch den entsprechenden Verpackungstyp definiert werden, der in der POM angegeben ist.

Update: Warum haben Sie maven-scm-plugin konfiguriert?

Update 2: Ich habe eine PR erstellt ..so Sie einen tieferen Einblick in meine Vorschläge nehmen kann ... Vielleicht ich einige Teile Ihrer Bedürfnisse verpasst ..

+1

Danke für die ausführlichen Kommentare und PR. Der größte Teil des POM wurde von einem anderen Projekt ausgeliehen und für ein einzelnes Projekt vor etwa einem Jahr konfiguriert; einige der Probleme, die Sie bemerken, sind ein Ergebnis von mir nur zu versuchen, die Dinge aufzuteilen und die Multi-Modul-Build arbeiten. Ich werde sehen, ob diese Änderungen das Problem "Lokal gegen Repository" beheben. –

+0

Es sieht so aus, als ob das neue Pom-Setup mein Problem behoben hat, danke! Habe nicht einen Schritt für Schritt gemacht, um genau zu sehen, welche der vielen Fehler es verursacht haben (wahrscheinlich das Maven Source Plugin Setup). Ich werde weiter daran arbeiten, die Pom nach Ihren Vorschlägen zu verfeinern, aber das Hauptproblem ist gelöst. –

+0

@khmarbaise Ich schulde dir ein Bier –