2010-01-25 12 views
50

Ich habe eine Ant-Build, die derzeit in Maven konvertiert wird. Der Ant-Build hat jedoch zwei Build-Ziele - eines, das die gesamte App erstellt, und eines, das aus einigen dieser Dateien eine JAR erstellt (nur ein paar). In Ant ist es einfach, mehrere Build-Ziele zu haben, um damit umzugehen, aber ich versuche, den besten Weg zu finden, damit in Maven umzugehen.Ant to Maven - mehrere Build-Ziele

Ich könnte die Teilmenge von Dateien in ein zweites Projekt aufteilen und es wird sein eigenes POM haben. Dann könnte das erste Projekt von diesem abhängen. Da die Teilmenge der Dateien jedoch so klein ist (weniger als 10), scheint es möglicherweise übertrieben zu sein, ein völlig neues Projekt dafür zu haben.

Gibt es andere Möglichkeiten, damit umzugehen?

Antwort

22

Ihr erster Gedanke ist der richtige. Teilen Sie die 2 Teile in 2 Projekte auf.

Die Maven Philosophie ist, dass jedes Projekt eine und einzige Artefakt bauen sollte (jar, Krieg, was auch immer)

Sie wahrscheinlich zusammen etwas hacken könnte, so dass Sie nur ein Maven-Projekt Gebäude 2 atrifacts haben, aber es wäre ein Hack.

Sie können ameise von maven anrufen, also wenn Sie das wirklich tun wollen, dann schlage ich vor, dass Sie sich das maven ant plugin ansehen. Die Artefakt-ID ist "Maven-antrun-Plugin"

5

Sie haben die Wahl zwischen 2 bekommen:

Wenn die Teilmenge nur eine Sammlung von Ressourcen ist, dann Ich würde es nicht zu einem separaten Modul machen.

Wenn das Projekt immer von der Teilmenge abhängig ist, die einheitlich verpackt ist, dann ist die Teilmenge ein guter Kandidat, um eine module zu werden.

Wenn die Teilmenge in mehreren verschiedenen "Geschmacksrichtungen" umgepackt wird, würde ich Assemblys für jede "Geschmacksrichtung" definieren und die Artefaktnamen mit einem "Klassifizierer" qualifizieren, siehe maven coordinates.

Schließlich können Sie Profile verwenden, um zu bestimmen, welche Assemblys erzeugt werden. Ihr Standardprofil erzeugt möglicherweise nur den ursprünglichen Artefakt- "Geschmack", der während der Entwicklung benötigt wird.
Ein "vollständiges" Profil kann alle "Flavor" -Varianten des Artefakts für die endgültige Bereitstellung erzeugen, sobald die Entwicklung abgeschlossen ist.

+1

+1 Danke, das erste Mal, dass ich von Assemblies hörte – stacker

+1

Ich habe Assemblys zum Packen des Artefakts verwendet, das ich zusammen mit Abhängigkeiten, Skripten usw. gebaut habe. Ist es üblich, die Assemblies zum Erstellen einer Teilmenge der Dateien zu verwenden? Oder ist es besser, die Teilmenge der Dateien in ein eigenes Projekt aufzuteilen? –

66

Sie könnten dies mit Profilen ...

Wenn Sie wirklich die JAR-Plugin enthalten und verstehen sich inklusive Muster der Klassen- und Paketnamen verwenden, um zwei separate Profile und anpassen wollten, können Sie dies leicht tun könnte durch so etwas wie diese setzen in Ihrem POM:

<profiles> 
    <profile> 
    <id>everything</id> 
    <build> 
     <plugins> 
     <plugin> 
      <artifactId>maven-jar-plugin</artifactId> 
      <configuration> 
      <classifier>everything</classifier> 
      <includes> 
       <include>**/*</include> 
      </includes> 
      </configuration> 
     </plugin> 
     </plugins> 
    </build> 
    </profile> 
    <profile> 
    <id>only-library</id> 
    <build> 
     <plugins> 
     <plugin> 
      <artifactId>maven-jar-plugin</artifactId> 
      <configuration> 
      <classifier>only-library</classifier> 
      <excludes> 
       <exclude>**/Main*</exclude> 
      </excludes> 
      </configuration> 
     </plugin> 
     </plugins> 
    </build> 
    </profile> 
</profiles> 

Abgesehen: Wenn das wie eine Menge Konfiguration scheint, Unterstützung polyglotte Maven für Groovy POMs bereit ist gerade dabei. Es wird den Zeilenzähler erheblich reduzieren.

Sie würden dies am Ende Ihres Pom setzen.xml (mit dem Projektelement) und fügt zwei Profile hinzu. Das erste Profil "alles" ist wirklich nur dazu da, um die Konfiguration zu demonstrieren. Dieses "alles" -Profil ist nicht notwendig, da es das Verhalten der standardmäßigen JAR-Plugin-Jar-Zielausführung einfach dupliziert. Das zweite Profil "only-library" schließt jede Klasse in einem Paket aus, die mit dem Text "Main" beginnt. So rufen Sie diese Profile:

mvn package -Peverything 
mvn package -Ponly-library 

Getestet habe ich diese gegen die Beispielanwendung, die Schiffe mit Chapter 6 of Maven by Example, und einen dieser Befehle ausgeführt wird produzieren eine JAR-Datei in $ {basedir}/Ziel, das einen Klassifikator hat. Da das JAR-Ziel des JAR-Plugins im Standard-Maven-Lebenszyklus an die Paketphase gebunden ist, ändern diese beiden Profile die Konfiguration für dieses Plugin.

Oder man könnte dies mit zwei JAR-Plugin Hinrichtungen ...

Wenn Sie zwei JAR-Dateien zu erstellen, ohne Profile zu verwenden. Sie können das JAR-Ziel des JAR-Plugins mehrmals mit der Paketlebenszyklusphase verknüpfen und für jede konfigurierte Ausführung eine andere Konfiguration verwenden. Wenn Sie zwei separate Ausführungen konfigurieren, verfügt jede Ausführung über einen ausführungsspezifischen Konfigurationsblock, sodass Sie für jede Ausführung einen eindeutigen Bezeichner und ein Ein-/Ausschlussmuster angeben können.

Hier ist das Build-Element, das Sie verwenden würden, um beide benutzerdefinierten JARs dem Lebenszyklus-Paket hinzuzufügen. Bei einem Projekt mit dem Paket "jar" würde dies dazu führen, dass das jar-Ziel dreimal ausgeführt wird. Einmal als Standardlebenszyklusbindung und dann zweimal für zwei benutzerdefinierte, klassifizierte JARs.

<build> 
    <plugins> 
     <plugin> 
     <artifactId>maven-jar-plugin</artifactId> 
     <executions> 
      <execution> 
      <id>only-library</id> 
      <goals><goal>jar</goal></goals> 
      <phase>package</phase> 
      <configuration> 
       <classifier>only-library</classifier> 
       <excludes> 
       <exclude>**/Main*</exclude> 
       </excludes> 
      </configuration> 
      </execution> 
      <execution> 
      <id>everything</id> 
      <goals><goal>jar</goal></goals> 
      <phase>package</phase> 
      <configuration> 
       <classifier>everything</classifier> 
       <includes> 
       <include>**/*</include> 
       </includes> 
      </configuration> 
      </execution> 
     </executions> 
     </plugin> 
    </plugins> 
    </build> 

Wenn Sie einen anderen Satz von Klassen in jedem Artefakt zu erfahren, wie nicht sprechen, sollten Sie Maven Assemblies verwenden. Wenn Sie die Details von Assemblies kennen möchten, finden Sie ein Kapitel am Ende dieser Antwort von Maven: The Complete Reference. Ehrlich gesagt, glaube ich nicht, dass dieses spezielle Kapitel eine gute einleitende Referenz ist; In der Tat hatte ich zahlreiche Berichte, dass dieses Kapitel fast nicht lesbar ist (und wir arbeiten daran, das zu beheben). Wenn Sie Baugruppen verwenden möchten, empfehle ich die Maven Assembly Plugin's documentation. Im linken Navigationsmenü sehen Sie eine Liste von Beispiel-Assembly-Deskriptoren.

Haftungsausschluss: (Bitte) dies nicht tun. Wenn Sie zwei unterschiedliche JARs mit zwei verschiedenen Klassen erstellen, wird dringend empfohlen, das Projekt in zwei voneinander abhängige Module aufzuteilen.

Während Sie dies mit Profilen tun können, wird es einfacher für Sie, das Projekt in zwei (eigentlich drei) zu teilen. Längerfristig werden sich Herausforderungen ergeben, mit denen Sie konfrontiert werden, wenn Ihre Anwendung skaliert. Sie sind dafür verantwortlich, diese manuelle Liste der Klassen und Pakete zu ermitteln, die in jedem Ihrer klassifizierten JARs enthalten sein sollen.

Der Aufwand für ein einfaches übergeordnetes Projekt, das auf zwei separate Module verweist, ist minimal. Wenn Sie sich das kostenlose Maven by Example-Buch ansehen, zeigen wir Ihnen, wie Sie den Übergang zwischen einem Einzelmodul- und einem Multi-Modul-Projekt durchführen können. Chapters 3-5 konzentrieren Sie sich auf einzelne Modulprojekte, und Chapter 6 zeigt Ihnen, wie Sie diese einzelnen Modulkomponenten zu einem größeren Multi-Modul-Projekt kombinieren würden.

Für weitere Informationen:

Sie Frage beinhaltet die folgenden Themen, hier sind einige Links, die mehr Details zu den einzelnen bieten wird:

Das Maven JAR-Plugin: http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html

Multi-Modul Maven Projekte: Chapter 6 of Maven by Example und Section 3.6.2 of Maven: The Complete Reference.

Der Maven Lifecycle (jar gebunden ist, zu verpacken, wenn Ihr packagin ist "jar"): Section 3.5.2 of Maven by Example "Core Concepts" und Chapter 4 of Maven: The Complete Reference

Maven Assemblies: Erstens, die Maven Assembly Plugin site, dann Chapter 8 of Maven: The Complete Reference für einige schwer (fast zu schwer) Details.

+4

Wow, nette Antwort Tom. Großes +1. –

+0

Danke für die ausführliche Antwort. Ich möchte mich von der Verwendung von Verpackungsmustern fernhalten. Scheint wie ein Maintenance-Kopfschmerz, wenn andere Entwickler herein kommen und nicht unbedingt die Muster kennen, die verwendet werden müssen. –