2010-11-30 10 views
17

Ich erstelle mein Anwendungsarchiv mit dem Maven Assembly Plugin. Alle Abhängigkeiten in meinem POM sind ohne Probleme enthalten.Maven Assembly: verschiedene Versionen desselben Artefakts hinzufügen

Jetzt muss ich zwei oder mehr Versionen des gleichen Artefakts enthalten.

Wenn in meinem pom Ich habe

<dependencies> 
     [...] 
     <dependency> 
      <groupId>db.test</groupId> 
      <artifactId>my-model</artifactId> 
      <version>1.0.3</version> 
     </dependency> 
     <dependency> 
      <groupId>db.test</groupId> 
      <artifactId>my-model</artifactId> 
      <version>1.1.0</version> 
     </dependency> 
</dependencies> 

Von Quelle der dependenvcy Resolver die alte Version entfernen und nur die 1.1.0 ist im Archiv verpackt

Ich versuche, das Glas schließen durch Montage mit XML-Deskriptordatei. Und ich habe keine Lösung gefunden.

Eine mögliche Lösung besteht darin, alle benötigten model.jar manuell in einen Ordner zu stellen und die Assembly anzuweisen, sie in das Archiv zu kopieren. Aber ich suche nach einer besser konfigurierbaren Lösung.

Irgendeine Idee?

+0

Keine Sorgen über die Notwendigkeit/Konflikt/.. etwas anderes. – Vlagorce

Antwort

12

Ich fand eine Lösung mit maven-dependency-plugin, um aufgelöste Pom-Abhängigkeiten und zusätzliche jar zu kopieren.

<plugin> 
<groupId>org.apache.maven.plugins</groupId> 
<artifactId>maven-dependency-plugin</artifactId> 
<version>2.1</version> 
<executions> 
    <execution> 
     <id>copy-dependencies</id> 
     <phase>package</phase> 
     <goals> 
      <goal>copy-dependencies</goal> 
     </goals> 
     <configuration> 
      <outputDirectory>${project.build.directory}/lib</outputDirectory> 
      <overWriteReleases>false</overWriteReleases> 
      <overWriteSnapshots>false</overWriteSnapshots> 
      <overWriteIfNewer>true</overWriteIfNewer> 
      <includeScope>runtime</includeScope> 
     </configuration> 
    </execution> 
    <execution> 
     <id>copy-model</id> 
     <phase>package</phase> 
     <goals> 
      <goal>copy</goal> 
     </goals> 
     <configuration> 
      <artifactItems> 
       <artifactItem> 
        <groupId>my.test.pkg</groupId> 
        <artifactId>my-model</artifactId> 
        <classifier>server</classifier> 
        <version>1.0.3</version> 
        <type>jar</type> 
       </artifactItem> 
       <artifactItem> 
        <groupId>my.test.pkg</groupId> 
        <artifactId>my-model</artifactId> 
        <classifier>server</classifier> 
        <version>1.1.0</version> 
        <type>jar</type> 
       </artifactItem> 
      </artifactItems> 
      <outputDirectory>${project.build.directory}/lib</outputDirectory> 
     </configuration> 
    </execution> 
</executions> 

Jetzt muss ich nur noch

<fileSet> 
     <directory>${project.build.directory}/lib</directory> 
     <outputDirectory>/lib</outputDirectory> 
     <filtered>false</filtered> 
     <includes> 
      <include>*.jar</include> 
     </includes> 
     <fileMode>0600</fileMode> 
    </fileSet> 
+1

kann fragen, wenn Sie dies tun, wenn beide Versionen nach jvm geladen sind, sollte es keinen Konflikt geben? –

+0

Ich hatte genau die gleiche Anforderung und Ihre Lösung Zeit gespart. @lucky_start_izumi - in den meisten Fällen, aber in meinem Fall ist es für eine Anwendung, die YAJSW verwendet, die eine ältere Bibliothek benötigt und meine Anwendung benötigt eine neuere. In meinem Szenario laufen sie auf verschiedenen Klassenpfaden. –

10

Maven geht davon aus, dass es keinen Sinn macht, mehr als eine Version eines Moduls gleichzeitig zu haben. Es wird davon ausgegangen, dass eine neuere Version die ältere Version ersetzt. Wenn nicht, ist es nicht das gleiche Modul. Ich schlage vor, dass Sie dem neueren Modul einen anderen Namen geben und sicherstellen, dass es verschiedene Pakete hat, um die Auswahl eines zufälligen Moduls zu vermeiden.

Im Allgemeinen hat Maven versucht, gutes Anwendungsdesign zu fördern und macht es bewusst schwierig, Dinge zu tun, von denen es sich als eine schlechte Idee herausgestellt hat.

+0

Dieses Glas hat verschiedene Klassen mit unterschiedlichen Paketnamen. Sie werden mithilfe von ServiceLoader geladen, um ein anderes XML-Modell zu erstellen, um die Kompatibilität zu erhalten. Ich denke in meinem Fall ist es keine schlechte Übung. Ich werde versuchen zu sehen, ob es möglich und nicht langweilig ist, den Namen bei jeder Veröffentlichung zu ändern. – Vlagorce

+2

Ich würde für die Namensänderung zwei bürgen, wenn Sie beide verwenden. –

+0

Natürlich ja! Alles ist anders, nur die Grouper und die Artefakte sind gleich. – Vlagorce

1

Eine andere hässliche Lösung könnte darin bestehen, WAR-Datei-Overlays zu verwenden, wobei die Tatsache ausgenutzt wird, dass dieser Mechanismus den Versionen von JAR-Dateien bei der Anwendung der Overlays keine Beachtung schenkt.

0

Ich bin damit einverstanden, verschiedene Versionen Mittel ersetzen die älteren die folgenden Zeilen in meiner Montage xml hinzuzufügen. Wenn wir für eine geschäftliche Anforderung zwei verschiedene Versionen eines Webdienstes benötigen. Es ist eine gute Idee, die Stubs in verschiedenen Paketen zu generieren, und beim Hinzufügen zu maven können Sie sie in groupid anders angeben. Das sollte funktionieren.

Verwandte Themen