Ant to Maven - plusieurs cibles de construction
J'ai une version Ant qui est actuellement en cours de conversion vers Maven. Cependant, la build Ant a 2 cibles de build - une qui construit l'application entière et une qui construit un JAR à partir de certains de ces fichiers (seulement quelques-uns). Dans Ant, il est facile d'avoir plusieurs cibles de build pour gérer cela, mais j'essaie de déterminer la meilleure façon de gérer cela dans Maven.
Je pourrais diviser le sous-ensemble de fichiers en un deuxième projet et il aura son propre POM. Le premier projet pourrait alors dépendre de celui-ci. Cependant, comme le sous-ensemble de fichiers est si petit (moins de 10), il semble qu'il soit exagéré d'avoir un projet entièrement nouveau pour cela.
Y a-t-il d'autres façons de gérer cela?
Votre première pensée est la bonne. Divisez les 2 pièces en 2 projets.
La philosophie maven est que chaque projet doit construire un seul et unique artefact (pot, guerre, peu importe)
Vous pourriez probablement pirater quelque chose ensemble afin de n'avoir qu'un seul projet maven construisant 2 atrifacts, mais ce serait un hack.
Vous pouvez appeler ant depuis maven, donc si vous voulez vraiment le faire, alors je vous suggère de commencer à regarder le plugin maven ant. L'identifiant de l'artefact est "maven-antrun-plugin"
Vous pouvez le faire avec des profils ...
Si vous vouliez vraiment utiliser deux profils distincts et personnaliser le plugin JAR pour inclure et exclure des modèles de noms de classe et de package, vous pouvez facilement le faire en mettant quelque chose comme ça dans votre 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>
En plus: Si cela semble être beaucoup de configuration, le support de polyglot Maven pour Groovy POMs est à peu près prêt. Cela réduira considérablement le compte à rebours.
Vous mettriez cela à la fin de votre pom.xml (avec l'élément de projet), et cela ajouterait deux profils. Le premier profil "tout" est vraiment juste là pour démontrer la configuration. Ce profil "tout" est inutile car il reproduit simplement le comportement de l'exécution par défaut de l'objectif du bocal du plug-in JAR. Le deuxième profil "only-library" exclut toute classe dans n'importe quel package qui commence par le texte "Main". Pour appeler ces profils:
mvn package -Peverything
mvn package -Ponly-library
J'ai testé cela par rapport à l'exemple d'application fourni avec Chapitre 6 de Maven par exemple , et l'exécution de l'une de ces commandes produira un fichier JAR dans $ {basedir}/target qui a un classificateur. Étant donné que l'objectif jar du plugin JAR est lié à la phase de package dans le cycle de vie maven par défaut, ces deux profils vont modifier la configuration de ce plugin.
Ou, vous pouvez le faire avec deux exécutions de plug-in JAR ...
Si vous devez créer deux fichiers JAR sans utiliser de profils. Vous pouvez lier l'objectif jar du plugin JAR à la phase de cycle de vie du package plusieurs fois et utiliser une configuration différente pour chaque exécution configurée. Si vous configurez deux exécutions distinctes, chaque exécution a un bloc de configuration spécifique à l'exécution afin que vous puissiez fournir un identifiant unique et inclure/exclure un modèle pour chaque exécution.
Voici l'élément de construction que vous utiliseriez pour ajouter les deux fichiers JAR personnalisés au "package" de la phase du cycle de vie. Faire cela sur un projet avec un emballage "pot" entraînerait l'exécution de l'objectif du pot trois fois. Une fois comme liaison de cycle de vie par défaut, puis deux fois pour deux fichiers JAR personnalisés et classés.
<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>
Si vous ne parlez pas d'inclure un ensemble différent de classes dans chaque artefact, vous voudrez utiliser des assemblages Maven. Si vous voulez connaître les détails des assemblages, il y a un chapitre répertorié à la fin de cette réponse de Maven: The Complete Reference. Franchement, je ne pense pas que ce chapitre particulier soit une bonne référence d'introduction; en fait, j'ai eu de nombreux rapports que ce chapitre est presque illisible (et nous travaillons pour résoudre ce problème). Si vous cherchez à utiliser des assemblys, je recommanderais la documentation du plugin d'assemblage Maven . Dans le menu de navigation de gauche, vous verrez une liste d'exemples de descripteurs d'assemblage.
Avertissement: (S'il vous plaît) ne faites pas cela. Si vous créez deux JAR différents avec deux ensembles de classes différents, je vous recommande fortement de diviser le projet en deux modules interdépendants.
Bien que vous puissiez le faire avec des profils, il vous sera plus facile de diviser le projet en deux (en fait trois). À plus long terme, vous devrez relever des défis à mesure que votre application évolue. Vous serez responsable de déterminer cette liste manuelle de classes et de packages à inclure dans chacun de vos JAR classifiés.
La surcharge d'un projet parent simple qui fait référence à deux modules distincts est minime. Si vous regardez le livre gratuit Maven by Example, nous montrons comment effectuer la transition entre un projet à module unique et un projet à modules multiples. Chapitres 3-5 concentrez-vous sur les projets à module unique, et Chapter 6 vous montre comment combiner ces composants à module unique dans un projet multi-module plus vaste.
Pour plus d'informations:
Votre question concerne les sujets suivants, voici quelques liens qui fourniront plus de détails pour chacun:
Le plugin Maven JAR: http://maven.Apache.org/plugins/maven-jar-plugin/jar-mojo.html
Projets Maven multi-modules: Chapitre 6 de Maven par l'exemple et Section 3.6.2 de Maven: La référence complète .
Le cycle de vie Maven (jar est lié au package si votre packagin est "jar"): Section 3.5.2 de Maven par l'exemple "Core Concepts" et Chapitre 4 de Maven: la référence complète
Assemblages Maven: D'abord, le site du plugin d'assemblage Maven , puis Chapitre 8 de Maven: La référence complète pour certains détails lourds (presque trop lourds).
Vous avez 2 choix:
Si le sous-ensemble n'est qu'une collection de ressources, je n'en ferais pas un module distinct.
Si le projet dépend toujours du sous-ensemble qui est empaqueté de manière uniforme, alors le sous-ensemble est un bon candidat pour devenir un module .
Si le sous-ensemble est reconditionné en plusieurs "saveurs" différentes, alors je définirais des assemblages pour chaque "saveur" et qualifierais les noms d'artefact avec un "classificateur" voir coordonnées maven .
Enfin, vous pouvez utiliser des profils pour déterminer quels assemblages seront produits, votre profil par défaut peut uniquement créer la "saveur" d'artefact initiale qui est requise pendant le développement.
Un profil "complet" peut produire toutes les variantes "d'arôme" de l'artefact pour un déploiement final une fois le développement terminé.