Meilleure pratique Maven pour générer plusieurs fichiers JAR avec des classes différentes / filtrées?
J'ai développé une bibliothèque d'utilitaires Java) (similaire à Apache Commons) que j'utilise dans divers projets. En plus des gros clients, je l'utilise également pour les clients mobiles (PDA avec profil J9 Foundation). fois la bibliothèque qui a commencé comme un seul projet réparti sur plusieurs packages.En conséquence, je me retrouve avec beaucoup de fonctionnalités, ce qui n'est pas vraiment nécessaire dans tous les projets.
Puisque cette bibliothèque est également utilisée dans certains projets mobiles/PDA, j'ai besoin d'un moyen de collecter uniquement les classes utilisées et de générer les jars spécialisés réels.
Actuellement dans les projets qui utilisent cette bibliothèque, j'ai des tâches Ant jar qui génèrent (à partir du projet utilitaire) les fichiers jar spécialisés (ex: my-util-1.0-pda.jar, my-util-1.0-rcp.jar) en utilisant les fonctionnalités de tâche d'inclusion/exclusion de jar. Ceci est principalement nécessaire en raison des contraintes de taille sur le fichier jar généré, pour les projets mobiles.
Migrer maintenant vers Maven Je me demande simplement s'il existe des meilleures pratiques pour arriver à quelque chose de similaire. Je considère les scénarios suivants:
[1] - en plus de l'artefact jar principal (my-lib-1.0.jar) générant également à l'intérieur my-lib projeter le/artefacts spécialisés utilisant des classificateurs (ex: my-lib-1.0-pda.jar) utilisant Maven Jar Plugin ou Maven Assembly Plugin filtering/includes. Je ne suis pas très à l'aise avec cette approche car elle pollue la bibliothèque avec les demandes des consommateurs de bibliothèque (filtres).
[2] - Créer des projets Maven supplémentaires pour tous les clients/projets spécialisés, qui "encapsuleront" le "my-lib" et généreront les artefacts jar filtrés (ex: my-lib -wrapper-pda-1. ... etc). En conséquence, ces projets wrapper incluront le filtrage (pour générer l'artefact filtré) et dépendront uniquement du projet "my-lib" et les projets clients dépendront de my-lib-wrapper-xxx-1. au lieu de my-lib-1.. Cette approche peut sembler problématique car même cela laissera le projet "my-lib" intact (sans classificateurs ni artefacts supplémentaires), doublera fondamentalement le nombre de projets puisque pour chaque projet client, j'aurai une bibliothèque, juste pour collecter le nécessaire classes de la bibliothèque "my-util" (le projet "my-pda-app" aura besoin d'un projet/dépendance "my-lib-wrapper-for-my-pda-app").
[3] - Dans chaque projet client qui utilise la bibliothèque (ex: my-pda-app), ajoutez des plugins Maven spécialisés à supprimer (lors de la génération de l'artefact final/package) les classes qui ne sont pas requises (ex: maven-Assembly-plugin, maven-jar-plugin, proguard-maven-plugin).
Quelle est la meilleure pratique pour résoudre ce genre de problèmes à la "manière Maven"?
La règle générale de Maven est "un artefact principal par POM" pour des raisons de modularité et les raisons pour lesquelles il ne faut pas enfreindre cette convention (en général) sont très bien expliquées dans le Comment créer deux JAR à partir d'un projet ( ... et pourquoi vous ne devriez pas) article de blog. Il existe cependant des exceptions justifiées (par exemple un projet EJB produisant un JAR EJB et un JAR EJB client avec uniquement des interfaces). Ayant dit cela:
Le article de blog (vérifiez également tilisation de Maven lorsque vous ne pouvez pas utiliser les conventions ) explique comment vous pouvez implémenter Option 1 en utilisant des profils séparés ou le plugin JAR . Si vous décidez d'implémenter cette solution, gardez à l'esprit que cela devrait être une exception et que cela pourrait rendre la gestion des dépendances plus délicate (et, comme vous l'avez mentionné, polluer le projet avec une "logique de filtrage client"). Juste au cas où, j'utiliserais plusieurs exécutions de plugins JAR ici.
L'option 2 n'est pas très différente de Option 1 IMO (sauf que il sépare les choses): en gros, avoir N autres projets de wrapping/filtrage est très similaire à avoir N règles de filtrage dans un projet. Et si le filtrage a du sens, je préfère l'option 1.
Je n'aime pas du tout Option 3 parce que je pense qu'il ne devrait pas être de la responsabilité d'un client d'une bibliothèque de "supprimer" les éléments indésirables . Premièrement, un projet client n'a pas nécessairement les connaissances requises (quoi couper) et, deuxièmement, cela pourrait créer un gros désordre avec d'autres plugins.
[~ # ~] mais [~ # ~] si les gros clients sont pas en utilisant l'ensemble my-lib (comme le code côté serveur nécessiterait l'intégralité du JAR EJB), alors le filtrage n'est pas le bon "maven façon "de gérer votre situation. La bonne façon serait Option 4 : mettre tout ce qui est commun dans un projet (produisant my-lib-core-1.0 .jar ) et des parties spécifiques dans des projets spécifiques (qui produiront my-lib-pda-1.0.jar etc ). Les clients dépendraient alors de l'artefact principal et de ceux spécialisés.