Wie gehen Sie mit Maven-3 timestamped Snapshots effizient umgehen?
https://stackoverflow.com/questions/4275466
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Nun, da maven-3 tat Drop-Unterstützung für das
Es schien am besten Praxis vor alle Snapshots zu uniqueVersion = false
einstellenNun scheint es kein großes Problem Schalter auf die timestamped Version, nach allem was sie von einer zentralen Nexus-Repository verwaltet werden, die alten Schnappschüsse in regelmäßigen Abständen zu löschen vermögen.
Das Problem sind die lokalen Entwickler-Arbeitsplätze. Ihre lokale Repository schnell wachsen sehr groß mit einzigartigen Schnappschüssen.
Wie mit diesem Problem umgehen?
Im Moment sehe ich die Folowing mögliche Lösungen:
- die Entwickler Stellen Sie das Repository in regelmäßigen Abständen zu reinigen (was zu viel fustration, wie es lange Zeit zu löschen und noch länger Download alles Nötige nimmt)
- Stellen Sie ein Skript, das alle tut löschen SNAPSHOT Verzeichnisse aus dem lokalen Repository und Entwickler stellen das Skript von Zeit zu Zeit laufen (besser als die ersten, aber dauert noch einige Zeit laufen zu lassen und Download aktuelle Snapshots)
- verwenden, um die Abhängigkeit: Purge-local-Repository-Plugin (Does Probleme haben, wenn sie von Eclipse ausführen, aufgrund offener Dateien, muss von jedem Projekt ausgeführt werden soll)
- einrichten nexus auf jeder Workstation und einen Job zu reinigen alte Schnappschüsse einrichten (beste Ergebnis, aber ich will nicht 50 + Nexus-Server erhalten, sowie Speicher ist immer dicht an Entwickler-Workstations)
- Stop SNAPSHOTS überhaupt mit
Was ist der beste Weg, um Ihr lokales Repository zu halten von der Befüllung des Festplattenplatzes?
Update:
Um die beaviour zu überprüfen und weitere Informationen i-Setup einen kleinen Nexus Server, bauen zwei Projekte geben (a und b) und versuchen Sie:
a:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>de.glauche</groupId>
<artifactId>a</artifactId>
<version>0.0.1-SNAPSHOT</version>
<distributionManagement>
<snapshotRepository>
<id>nexus</id>
<name>nexus</name>
<url>http://server:8081/nexus/content/repositories/snapshots</url>
</snapshotRepository>
</distributionManagement>
</project>
b:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>de.glauche</groupId>
<artifactId>b</artifactId>
<version>0.0.1-SNAPSHOT</version>
<distributionManagement>
<snapshotRepository>
<id>nexus</id>
<name>nexus</name>
<url>http://server:8081/nexus/content/repositories/snapshots/</url>
</snapshotRepository>
</distributionManagement>
<repositories>
<repository>
<id>nexus</id>
<name>nexus</name>
<snapshots>
<enabled>true</enabled>
</snapshots>
<url>http://server:8081/nexus/content/repositories/snapshots/</url>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>de.glauche</groupId>
<artifactId>a</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
</dependencies>
</project>
Nun, wenn ich Maven und laufen "deploy" auf "a", Ich werde
a-0.0.1-SNAPSHOT.jar
a-0.0.1-20101204.150527-6.jar
a-0.0.1-SNAPSHOT.pom
a-0.0.1-20101204.150527-6.pom
im lokalen Repository. Mit einer neuen Zeitstempel Version jedes Mal, wenn ich laufe das deploy Ziel. Das gleiche passiert, wenn ich zu aktualisieren Snapshots aus dem Nexus-Server versuchen (in der Nähe „a“ Projekt, löschen Sie es aus lokalen Repository, build „b“)
In einer Umgebung, wo viele Schnappschüsse Build (man denke hudson Server ...) erhalten, die lokale reposioty füllt sich mit alten Versionen schnell
nach obenUpdate 2:
zu testen, wie und warum dies versagt ich einige weitere Tests gemacht haben. Jeder Test wird laufen gegen alles sauber (de / Glauche löschen bekommt von beiden Maschinen und Nexus)
- mvn deploy mit Maven 2.2.1:
lokales Repository auf Maschine A enthält SNAPSHOT.jar + Snapshot-timestamp.jar
ABER: nur ein timestamped Glas in Zusammenhang, Metadaten lautet:
<?xml version="1.0" encoding="UTF-8"?>
<metadata>
<groupId>de.glauche</groupId>
<artifactId>a</artifactId>
<version>0.0.1-SNAPSHOT</version>
<versioning>
<snapshot>
<timestamp>20101206.200039</timestamp>
<buildNumber>1</buildNumber>
</snapshot>
<lastUpdated>20101206200039</lastUpdated>
</versioning>
</metadata>
- run Update Abhängigkeiten (auf Maschine B) in m2eclipse (embedded m3 final) -> lokales Repository hat SNAPSHOT.jar + Snapshot-timestamp.jar: (
- laufen Paket Ziel mit externen Maven 2.2.1 -> lokales Repository hat SNAPSHOT.jar + Snapshot-timestamp.jar: (
Ok, nächster Versuch mit Maven 3.0.1 (nach all Spuren des Projekt eines Entfernen)
-
lokales Repository auf Maschine A sieht besser, nur eine ein nicht-timestamped Glas
-
nur ein timestamped Glas in Zusammenhang, Metadaten lautet:
de.glauche ein 0.0.1-SNAPSHOT
<snapshot> <timestamp>20101206.201808</timestamp> <buildNumber>3</buildNumber> </snapshot> <lastUpdated>20101206201808</lastUpdated> <snapshotVersions> <snapshotVersion> <extension>jar</extension> <value>0.0.1-20101206.201808-3</value> <updated>20101206201808</updated> </snapshotVersion> <snapshotVersion> <extension>pom</extension> <value>0.0.1-20101206.201808-3</value> <updated>20101206201808</updated> </snapshotVersion> </snapshotVersions> -
laufen Update Abhängigkeiten (auf Maschine B) in m2eclipse (embedded m3 final) -> lokales Repository hat SNAPSHOT.jar + Snapshot-timestamp.jar: (
-
laufen Paket Ziel mit externen Maven 2.2.1 -> lokales Repository hat SNAPSHOT.jar + Snapshot-timestamp.jar: (
Also, zur Erinnerung: Das „deploy“ Ziel in maven3 funktioniert besser als in 2.2.1, sieht das lokale Repository auf der Schaffung Maschine in Ordnung. Aber der Empfänger immer endet mit vielen timestamed Versionen ...
Was mache ich falsch?
Update 3
Ich habe Test verschiedene andere Konfigurationen auch zuerst ersetzen Nexus mit artifactory -> gleichem Verhalten. Dann nutzen Linux Maven 3 Clients die Schnappschüsse aus dem Repository Manager zum Download -> lokale Repository noch timestamped Snapshots hat: (
Lösung
Die <uniqueVersion> Konfiguration angewendet zu Artefakten, die bereitgestellt wurden (über MVN implementierende) zu einem Maven Repository wie Nexus.
Um diese von Nexus zu entfernen, können Sie einfach einen automatisierten Auftrag erstellen jeden Tag die Snapshot-Repository zu löschen. Es kann konfiguriert werden, eine bestimmte Anzahl von shapshots zu behalten oder sie für einen bestimmten Zeitraum zu halten. Seine super einfach und funktioniert super.
Artefakte im lokalen Repository auf einer Entwicklermaschine dort von dem „install“ Ziel und verwenden Sie nicht, diese Zeitstempel ... sie halten nur den einen zu ersetzen und nur SNAPSHOT Version, wenn Sie auch die Revisionsnummer erhöht wird (zB 1,0 0,0-SNAPSHOT auf 1.0.1-SNAPSHOT).
Andere Tipps
Dieses Plugin entfernt Projekt Artefakte aus lokalen Repository. Nützliche nur eine Kopie von großen lokalen Snapshot zu halten.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>remove-old-artifacts</id>
<phase>package</phase>
<goals>
<goal>remove-project-artifact</goal>
</goals>
<configuration>
<removeAll>true</removeAll><!-- When true, remove all built artifacts including all versions. When false, remove all built artifacts of this project version -->
</configuration>
</execution>
</executions>
</plugin>
Nun habe ich nicht wie jede der vorgeschlagenen Lösungen. maven Cache löschen oft deutlich erhöht den Netzwerkverkehr und verlangsamt Build-Prozess. Build-Helfer-maven-Plugin hilft nur mit einem Artefakt, ich wollte Lösung, die alle veralteten timestamped Snapshot-Artefakte aus dem lokalen Cache in einem einfachen Befehl löschen kann. Nach wenigen Tagen des Suchens, gab ich auf und entschied kleines Programm zu schreiben. Das endgültige Programm scheint recht gut in unserer Umwelt zu arbeiten. Also habe ich beschlossen, es mit anderen zu teilen, die solches Werkzeug benötigen. Quellen können von Github gezogen werden: https://github.com/nadestin/tools/tree/ Master / MavenCacheCleanup
Was das Remote-Repository Stück von diesem, ich denke, die bisherigen Antworten, die eine Spülung von Schnappschüssen auf einem regelmäßigen Intervall Willen Arbeit diskutieren. Aber niemand hat befasste sich mit dem lokalen Entwickler-Workstation Synchronisation Teil Ihrer Frage.
Wir haben mit Maven3 noch nicht begonnen, so dass wir noch haben von Schnappschüssen beginnen aufzubauen auf lokalen Rechnern zu sehen.
Aber wir haben andere Probleme mit m2eclipse haben. Wenn wir von „Workspace Resolution“ aktiviert haben und das Projekt existiert in unserem Arbeitsbereich, Quelle Updates halten uns in der Regel auf der bleeding edge. Aber wir haben es sehr schwierig gefunden zu bekommen m2eclipse sich in Nexus mit kürzlich veröffentlichten Artefakte zu aktualisieren. Wir erleben ähnliche Probleme in unserem Team und es ist besonders problematisch, weil wir ein sehr großes Projekt Graphen haben ... es gibt eine Menge von Abhängigkeiten, die nicht in Ihrem Arbeitsbereich sein werden, aber werden immer von Schnappschüssen häufig veröffentlicht.
Ich bin mir ziemlich sicher, dass dies läuft darauf hinaus zurück zu einem Problem in m2eclipse wo es behandelt nicht von Schnappschüssen genau so, wie es sollte. Sie können in der Maven-Konsole in Eclipse sehen, wo m2eclipse Sie sagt es das Update einer kürzlich veröffentlichten SCHNAPPSCHUSS Skipping, weil es eine Cache-Version bekam ist. Wenn Sie eine -U aus einer Laufzeitkonfiguration oder von der Kommandozeile tun, Maven die Metadaten ändern abholen. Aber ein „Update Snapshots ...“ Auswahl sollte m2eclipse sagen haben Maven diesen Cache ablaufen. Es scheint nicht entlang weitergegeben werden immer. Es scheint ein Fehler da draußen zu sein, die für diese eingereicht worden ist, wenn Sie es in Abstimmung interessiert sind: https://issues.sonatype.org/browse/MNGECLIPSE-2608
Sie gemacht in einem Kommentar irgendwo diese erwähnen.
Die beste Abhilfe für dieses Problem scheint Entwickler reinigen ihre lokale Arbeitsplätze zu haben, wenn die Dinge beginnen von innen m2eclipse zu brechen. Ähnliche Lösung für ein anderes Problem ... Andere Probleme mit Maven 2.2.1 und 3 Unterstützung m2eclipse berichtet hat, und ich habe das gleiche gesehen.
Ich hoffe, wenn Sie Maven3 verwenden Sie es nur konfigurieren, können Sie für die Zeit, die neuesten SNAPSHOT und Cache zu ziehen, dass das Repository sagt (oder bis es von Hand verfallen). Hoffentlich dann werden Sie nicht ein Bündel von Schnappschüssen sitzen in Ihrem lokalen Repository haben müssen.
Es sei denn, Sie sprechen von einem Build-Server, der manuell eine mvn install auf sie tut. Soweit wie von Schnappschüssen zu verhindern, dass auf einer Umgebung wie ein Build-Server aufzubauen, haben wir Art, dass Kugel ausgewichen von jeder Build Verwendung seinen eigenen Arbeitsbereich und lokalen Repository mit (obwohl in Maven 2.2.1, bestimmten Dinge wie POMs scheinen der ~ / .m2 / Repository immer kommen) die zusätzlichen von Schnappschüssen wirklich nur für einen einzigen Build dableiben und dann werden sie fallen gelassen (und heruntergeladen wieder von vorne). Also haben wir diesen Ansatz gesehen hat am Ende mehr Platz beginnen zu essen, aber es neigt dazu, stabiler zu bleiben, als alles mit einer einzigen Repository aufgelöst werden. Diese Option (on Hudson) ist „Use Private Maven Repository“ und ist unter der Schaltfläche Erweitert des Build-Abschnitt auf Projektkonfigurationen, wenn Sie bauen mit Maven ausgewählt haben. Hier ist die Hilfe Beschreibung für diese Option:
Normalerweise verwendet Hudson der lokalen Maven Repository von Maven bestimmt - der genaue Prozess scheint zu sein, undokumentiert, aber es ist ~ / .M2 / Repository und außer Kraft gesetzt werden kann Von in ~ / .M2 / settings.xml (siehe Referenz für weitere Details.) bedeutet dies normalerweise dass alle Jobs, die ausgeführt werden, auf die gleichen Knoten teilt eine einzige Maven Repository. Der Vorteil davon ist, dass Sie können den Speicherplatz sparen, aber die Kehrseite der Medaille ist, dass manchmal diejenigen, baut mit jeder könnte stören andere. Zum Beispiel könnten Sie am Ende Builds falsch Erfolg hat, nur becAUSE Sie haben alle Abhängigkeiten in Ihrem lokalen Repository, trotz der Tatsache, dass keiner der Repositorys in POM könnte sie haben.
Es gibt auch einige gemeldete Probleme in Bezug auf mit gleichzeitigen Maven Prozesse versuchen, die gleiche lokale verwenden Repository.
Wenn diese Option aktiviert ist, Hudson wird zeigen, Maven zu verwenden $ ARBEITSBEREICH / .repository als lokales Maven-Repository. Das bedeutet, jeden Job wird seine eigene isolierte Maven bekommen Repository nur für sich. es behebt die oben genannten Probleme, auf Kosten der zusätzlicher Speicherplatz Verbrauch.
Wenn Sie diese Option verwenden, sollten Sie ein Maven Artefakt Manager Einrichtung so dass Sie sich remote nicht getroffen Maven-Repositories zu oft.
Wenn Sie diesen Modus zu aktivieren, würden es vorziehen, in alle ausgeführt die Maven Jobs auf Hudson, beziehen sich auf die Technik hier beschrieben.
Hope, das hilft -. Wenn es nicht Ihr Problem wenden Sie sich bitte lassen Sie mich wissen, wo ich verpasst
In groovy kann timestamped Dateien wie artifact-0.0.1-20101204.150527-6.jar zu löschen ganz einfach:
root = 'path to your repository'
new File(root).eachFileRecurse {
if (it.name.matches(/.*\-\d{8}\.\d{6}\-\d+\.[\w\.]+$/)) {
println 'Deleting ' + it.name
it.delete()
}
}
Installieren Groovy , Speichern Sie das Skript in eine Datei und die Ausführung planen in jeder Woche beginnen, Anmelde , was zu Ihnen passt.
Sie können aber auch die Ausführung in maven build verdrahten, mit gmavenplus-Plugin . Beachten Sie, wie ist der Repositoryposition Satz von in das Eigentum settings.localRepository maven und dann durch Konfiguration in variable repository binded:
<plugin>
<groupId>org.codehaus.gmavenplus</groupId>
<artifactId>gmavenplus-plugin</artifactId>
<version>1.3</version>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>execute</goal>
</goals>
</execution>
</executions>
<configuration>
<properties>
<property>
<name>repository</name>
<value>${settings.localRepository}</value>
</property>
</properties>
<scripts>
<script><![CDATA[
new File(repository).eachFileRecurse {
if (it.name.matches(/.*\-\d{8}\.\d{6}\-\d+\.[\w\.]+$/)) {
println 'Deleting snapshot ' + it.getAbsolutePath()
it.delete()
}
}
]]></script>
</scripts>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>2.3.7</version>
<scope>runtime</scope>
</dependency>
</dependencies>
</plugin>
Fügen Sie folgende Parameter in der POM-Datei
POM
<configuration>
<outputAbsoluteArtifactFilename>true</outputAbsoluteArtifactFilename>
</configuration>
https://maven.apache.org/plugins/ maven-Abhängigkeit-Plugin / copy-mojo.html
POM Beispiel
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.10</version>
<executions>
<execution>
<id>copy</id>
<phase>package</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<type>jar</type>
<overWrite>false</overWrite>
<outputDirectory>${project.build.directory}/alternateLocation</outputDirectory>
<destFileName>optional-new-name.jar</destFileName>
</artifactItem>
</artifactItems>
**<outputAbsoluteArtifactFilename>true</outputAbsoluteArtifactFilename>**
<outputDirectory>${project.build.directory}/wars</outputDirectory>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Konfigurieren in Jenkins:
// copy artifact
copyMavenArtifact(artifact: "commons-collections:commons-collections:3.2.2:jar", outputAbsoluteArtifactFilename: "${pwd()}/target/my-folder/commons-collections.jar")
