Strip-version Anzahl von Abhängigkeit, basierend auf die Gruppen-ID in maven
Ich habe ein Projekt, das die 3rd-party-Abhängigkeiten sowie die Abhängigkeiten auf interne Projekte. Ich muss ausziehen, das Versionsnummern aus den abhängigen Artefakte werden im eigenen Haus entwickelt.
Beispiel: spring-2.5.6.jar sollte in der endgültigen Ausgabe als spring-2.5.6.jar aber MyInternalProject-1.0.17.jar geändert werden muss, um MyInternalProject.jar.
Ich kann erkennen, die internen Abhängigkeiten, die leicht genug ist, indem Sie Ihre group-ID (Sie sind alle so etwas wie com.mycompany.*). Die maven-dependency-plugin hat eine stripVersion option, aber es scheint nicht selektiv genug. Gibt es eine Möglichkeit, dies zu tun, kurz explizit benennen jede Abhängigkeit, und, was Ihre endgültige name sein sollte?
Formuliert einen anderen Weg:
Ich würde gerne verschiedene outputFileNameMappings für das maven-assembly-plugin für Artefakte basierend auf der group-ID. Gibt es eine Möglichkeit, dies zu tun?
- Darf ich Fragen, warum Sie wollen, um Streifen die Versionen einiger Artefakte?
- Was meinst du mit "final output" Einige Montage .Krieg .zip -, .Ohr?
- Es ist ein zip-Archiv.
- Also willst du einfach nur die zip-Datei nicht die version? Oder möchten Sie die jar-Dateien enthalten in der zip, die gebaut wurden aus internen Artefakte nicht zu haben-Versionen, oder?
- Der Grund, den ich bekam, war, dass schließlich, das Archiv wird entpackt und die Gläser und Dateien werden in die Quellcodeverwaltung eingecheckt. Sie möchten revision der Geschichte für die intern entwickelte Gläser, so dass die Dateinamen nicht haben version zahlen. 3rd party jars ändern, viel weniger Häufig, und Sie hätte lieber Versionsnummern in den Dateinamen, so dass Sie sehen können, welche version der jar-Datei, die Sie verwenden.
- Die in-house-Elemente in der zip-Datei sollte keine Versionsnummern, die 3rd-party-Artefakte in der zip-Datei sollte version zahlen. Für die zip-Datei selbst ist es wohl egal (aber ich weiß, wie zu Steuern, dass schon, wenn ich muss).
- Ich denke, dieser Ansatz kann einige Probleme haben ... ich poste meine ausführliche Antwort mit details
- Ich nehme an, Sie sind mit dem maven-assembly-plugin, um schließlich machen Sie Ihre .zip?
- Ja.
- Ich nehme an, Sie können dies tun, werden die Definition von benutzerdefinierten Zuordnungen in Ihrer assembly-descriptor - siehe maven.apache.org/plugins/maven-assembly-plugin/... . Leider habe ich kein Beispiel bei der hand, können dies überprüfen, bei der Arbeit morgen. (Einstellung
sourceunddestNamesollte den trick tun) - Ja, würd ich schon gespielt, um mit
outputFileNameMapping. Das problem ist, dass es gilt für alle Artefakte, die ich anwenden möchten, um verschiedene mappings basierend auf den unterschiedlichen Artefakt-Gruppen-IDs.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ich denke, Sie können mit dem folgenden Rezept:
Erste, in Ihrem aggregator pom verwenden Sie die
dependency:copy-dependenciesZiel zu kopieren Sie Ihre Krüge, um einige Zwischenstation. Sie müssen zwei Ausführungen, eine mit<stripVersion>true</stripVersion>für Ihre internen Abhängigkeiten; und eine mit<stripVersion>false</stripVersion>für 3rd-party-Bibliotheken. Sie können include/exclude-Artefakte basierend auf der Gruppen-id, siehe http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html für volle details.Dann sollte es eine einfache Aufgabe zu bauen .zip über das maven-assembly-plugin!
Basierend auf den Kommentaren, ich würde neu zu bewerten, Ihren Ansatz. In der Regel prüfen Gläser in die Quellcodeverwaltung ist nicht eine gute Idee, vor allem nicht versionierte Gläser. Stell dir vor, ich hatte gerade ein Projekt, verwiesen someArtifact.jar und ich habe versucht zu Debuggen - wie würde ich wissen, welche version er verwendet?
Tools wie artifactory und nexus sind für das speichern von Versionen Ihrer Gläser, sowohl interne als auch 3rd-party (Sie können auch proxy-öffentliche repositories wie maven central). Um reproduzierbare builds, ich würde Ihr Binärdateien in ein tool für, dass, und dann können Sie auf diese version. Während der Entwicklung können Sie auf SNAPSHOT-Versionen Ihrer Gläser zu Holen Sie sich die neuesten, und dann, wenn Sie tun, eine Version, können Sie auf stabile Versionen der Binärdateien.
Source-control-Systeme gedacht waren, für die Speicherung der Quelle, nicht Binärdateien.
MyJar-1.0.0.jar,MyJar-1.0.1.jar, undMyJar-1.0.2.jares werden drei verschiedene Dateien in der Quellcodeverwaltung. Wenn ich check-in jeweils eine DateiMyJar.jardrei mal (jedes mal, wenn eine neuere version), gibt es eine einzelne Datei in der version Kontrolle, und ein Benutzer kann eine Datei-history für die Datei und zeigt jedem check-in. Auch gibt es keine integration von Quellcodeverwaltung und Maven. 🙁