Apache Ivy und lokale Maven Repo - wie Snapshots mit Maven 3

Question

Wir haben derzeit ein Projekt-Setup, das Ivy für die Abhängigkeitsverwaltung und Ant als das allgemeine Build-Tool verwendet (obwohl das wahrscheinlich nicht relevant ist hier). Zusätzlich haben wir eine Reihe von Bibliotheken, die mit Maven erstellt werden und von denen die Projekte (wir haben mehrere davon) abhängig sind. Wir wissen, dass diese Situation alles andere als ideal ist, und wir prüfen, wie wir das verbessern können, aber wir können das nicht so schnell ändern, wie wir es gerne hätten. Also müssen wir mit dem arbeiten, was wir gerade haben.

Wie auch immer, hier ist das Problem: Es hat mit Maven 2 und Ivy funktioniert, aber wir haben vor kurzem aus mehreren Gründen auf Maven 3 umgestiegen (eine bessere Konfliktlösung) und diese Kombination hat unsere Builds zerstört.

Zuerst werde ich versuchen zu beschreiben, wie unsere Builds mit Maven 2 und Ivy funktionierten. Danach werde ich hinzufügen, wo das brach beim Einschalten 3.

Ivy + Maven Maven 2

Wenn neue Versionen unserer Bibliotheken entwickeln, sind wir SNAPSHOT Versionen verwenden, die in den lokalen installiert sind Maven Repo (.m2). Zusätzlich stellen wir diese Snapshots in unserem Artifactory bereit, um Zwischenversionen für eine parallele Entwicklung freizugeben.

Unsere Projekte deklarieren dann Abhängigkeiten von diesen Snapshots. Die entsprechende ivysettings.xml sieht wie folgt aus:

<ivysettings> 
    <settings defaultResolver="default" /> 
    <include url="${ivy.default.settings.dir}/ivysettings-local.xml" /> 
    <resolvers> 
    <ibiblio name="public" root="path.to.our.artifactory" m2compatible="true" /> 

    <filesystem name="local-maven2" m2compatible="true" checkmodified="true" changingPattern=".*SNAPSHOT">  
     <ivy pattern="${user.home}/.m2/repository/[organisation]/[module]/[revision]/[module]-[revision].pom" /> 
     <artifact pattern="${user.home}/.m2/repository/[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]" /> 
    </filesystem> 
    <filesystem name="local" checkmodified="true" changingPattern=".*SNAPSHOT"> 
     <ivy pattern="${ivy.local.default.root}/${ivy.local.default.ivy.pattern}" /> 
     <artifact pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}" /> 
    </filesystem> 
    <filesystem name="local2" checkmodified="true" changingPattern=".*SNAPSHOT"> 
     <ivy pattern="${user.home}/.ivy2/cache/[organisation]/[module]/ivy-[revision].xml" /> 
     <artifact pattern="${user.home}/.ivy2/cache/[organisation]/[module]/[artifact]-[revision].[ext]" /> 
    </filesystem> 

    <chain name="default" checkmodified="true" changingPattern=".*SNAPSHOT"> 
     <resolver ref="local" /> 
     <resolver ref="local-maven2" /> 
     <resolver ref="public" /> 
    </chain> 
    </resolvers> 
    <include url="${ivy.default.settings.dir}/ivysettings-shared.xml" /> 
</ivysettings> 

Durch diese Einrichtung Ivy für neuere Versionen eines Schnappschusses aussehen sollte und das richtig lösen. Neuere Versionen werden durch Vergleichen des Dateidatums der entsprechenden POM-Datei identifiziert.

Wenn wir einen Snapshot mit Maven 2 erstellen, erhält das entsprechende .pom das Dateidatum des aktuellen Builds und damit funktioniert diese Überprüfung und Ivy löst die korrekten Snapshot-Versionen auf.

Ivy + Maven 3

Die Auflösung über Pausen beschrieben beim Aufbau der Snapshots mit Maven 3. Der Grund scheint zu sein, dass die installierte .pom Datei nicht die aktuellen Zeitstempel als Dateidatum bekommt aber behält das Dateidatum der ursprünglichen pom.xml bei, die kopiert wird. Daher kann Ivy nicht erkennen, ob der Schnappschuss neuer ist.

Es scheint, als ob Maven 3 die Update-Zeitstempel in maven-metadata-local.xml speichert, aber Ivy liest diese nicht. Wir wissen, dass es den ibiblio-Resolver gibt (den wir verwenden), aber gemäß dem, was wir wissen (z. B. aus Fragen wie this), ist es mit wirklich entfernen Repositories arbeiten und könnte Probleme bei der lokalen .m2 Repo.

Wir haben auch darüber nachgedacht, die Dateidaten anderer Dateien zu verfolgen, z. maven-metadata-local.xml oder die tatsächlichen Artefakte, aber wir sind nicht sicher, ob das sinnvoll ist oder den Build in anderen Situationen durchbrechen könnte.

Also wie sollten/könnten wir das lösen?

TL; DR

Was ist der Standard/vorgeschlagene Weg Ivy Abhängigkeiten von Snapshots zu behandeln, die mit Maven 3 und Einsatz in der lokalen .m2 Repo gebaut werden?

UPDATE 2016-07-26

Hier gibt es 2 Dinge, die ich versucht, das Problem zu lösen, aber ich bin mir nicht sicher, ob es irgendwelche Nebenwirkungen würde ich nicht gedacht. Ich wäre Ihnen dankbar, wenn jemand etwas Licht auf diesem verschütten könnte:

1. das Dateisystem Resolver für die lokale .m2 Repository verwenden, aber in conjection mit einem Cache, die useOrigin="true" (und optional einen niedrigen DefaultTTL) aufweist. Auf diese Weise scheint es, als ob nur die XML-Dateien im .ivy2-Cache gespeichert sind und die Artefakte im .m2-Repository referenziert werden, d. H., Sie werden nicht kopiert.
   
   
   Dies scheint zu funktionieren, aber ich bin mir nicht sicher, ob es wäre, wenn die erste Suche den Snapshot aus Shared Snapshot Repository (Artifactory) herunterladen würde und diese von einem lokalen Build später aktualisiert werden würde. In diesem Fall würden wir wahrscheinlich mit der Remote-Version des Artefakts, das in .ivy2 zwischengespeichert wird, und einer neueren Version, die in .m2 installiert wird, enden, wobei die Daten der .pom-Datei in beiden Fällen identisch sind.
2. Verwenden Sie den ibiblio-Resolver mit root="file://${user.home}/.m2/repository/", der die meisten Artefakte zu lösen scheint (Ausnahme siehe unten), aber beim Lesen der Metadaten immer noch fehlschlägt, dh er aktualisiert den Cache nicht mit der neueren Version, die gefunden werden soll im .m2 Repo.
   Während ich die meisten Artefakte im .m2 Repo auflösen kann, bekomme ich anscheinend Auflösungsfehler für einige "URLs" wie file://{user.home}/.m2/repository/javax/enterprise/cdi-api/1.0/cdi-api-1.0.jar, während die Artefakte existieren, d. H. Ich kopierte den Pfad direkt vom Windows Explorer und es ist "${user.home}\.m2\repository\javax\enterprise\cdi-api\1.0\cdi-api-1.0.jar".

Answer 1

... Wir wissen, dass sich diese Situation bei weitem nicht ideal ist und wir die Bewertung Möglichkeiten, das zu verbessern, aber wir können ...

Vollkommen normal in meiner Erfahrung. Viele große Unternehmen haben viele Projekte mit einer Mischung aus ANT, Maven und zunehmend Gradle.

Was ein paar Empfehlungen folgt, würde ich

Verwenden

Die beste Art und Weise machen, diese verschiedenen Technologien ein Repository-Manager zu integrieren, ist ein Zwischenspeicher laufen alle Ausgänge bauen zu halten. Dies entkoppelt effektiv den Build-Schritt von der späteren Verwendung der binären Artefakte.

Die empfohlene Repository-Technologie eine Maven-Repository (Java Standard an dieser Stelle), und Sie haben eine Auswahl an Open-Source-Technologien zur Verfügung Repository Gastgeber:

• Nexus
• Artifactory
• Archiva

Beim Ausführen eines zusätzlichen Servers scheint es sich um einen Overhead zu handeln, der in Pik als Zahl zurückzahlt r von abhängigen Projekten erhöhen (mit einem einzigen großen freigegebenen Dateisystem skaliert nicht).

In jedem Fall müssen Sie sowieso eine Referenzkopie Ihrer Release-Binärdateien haben.Mit diesen Maven-Repository-Managern können Sie die Abhängigkeiten von Drittanbietern, aus denen Ihre Projekte bestehen, steuern und Dateien zwischenspeichern, wodurch Ihre Build-Zeiten verkürzt und das gemeinsame Abhängigkeitsmanagement vereinfacht werden.

Schließlich wie konfiguriert man einen Ivy-Build, der ein Maven-Repository verwendet? Wie folgt dem ibiblio Resolver (und Sie werden entdecken, dass alle modernen Java Build-Tools ähnliche Unterstützung für ein lokales Maven Repository)

<ivysettings> 
    <settings defaultResolver="myrepo"/> 
    <resolvers> 
     <ibiblio name="myrepo" m2compatible="true" root="http://myrepo.com/path/to/repo"/> 
    </resolvers> 
</ivysettings> 

Vorsicht vor Snapshot-Releases

Snaphot Mitteilungen sind ein Konzept eingeführt von Maven Dies ist ein rechthaberischer Build-Framework. Meiner Meinung nach sollte man sich ganz bewusst sein, wenn sie mit:

• Snapshots are for Dev, Release Candidates are for QA

Wie Sie Schnappschüsse entdeckt haben, sich ständig verändern und sich nicht verlassen auf werden kann, wenn sie mit einer Gruppe zu teilen, die eine unveränderliche arefect erwarten für Testen (wie QA).

auf diese Mein Denken wurde durch das folgende Posting geformt, dass der Maven Ansatz diskutiert Management lösen:

• http://www.slideshare.net/wakaleo/continuous-deliverywithmaven

Schließlich, während ich die Verwendung von Snapshots zu begrenzen würde empfehlen, zu eng zusammenarbeitende Teams, Efeu unterstützt sie, es gibt nur einige bekannte Einschränkungen für ihre Verwendung. Weil sie ein Maven-Konstrukt sind, werden sie nicht zu 100% von anderen Build-Technologien unterstützt. Dies ist, wo ein Repository-Manager hilft wirklich, da sie die korrekten Metadaten zur Regeneration unterstützen Snapshot-Releases fähig sind:

• What's wrong with this Ivy changingPattern/SNAPSHOT configuration?
• Publishing Ivy SNAPSHOTS with Maven metadata

Hoffnung, das hilft.