Migration d'un projet complexe d'Ant vers Maven - Comment gérer les structures de dossiers inhabituelles?

Question

Dans mon nouveau projet, je suis confronté à une infrastructure complexe avec plusieurs modules qui ont grandi au fil des ans de manière désagréable et incontrôlée.

Pour en venir au fait: le processus de construction est l'horreur. Il existe plus de 40 fichiers Ant complexes et différents, qui sont connectés plusieurs fois et le framework SOA génère également plusieurs fichiers Ant dynamiques. Il a fallu quelques jours pour vraiment comprendre toutes les dépendances et enfin construire l'ensemble du projet sans aucune erreur.

Mon plan était ou est de migrer l'ensemble du projet de Ant vers Maven, car de nouveaux composants sont prévus et j'aimerais éviter ces problèmes à l'avenir et bien, car c'est tout simplement horrible de la façon dont il est maintenant ;-)

Étant donné que je suis nouveau dans la migration de projets plus importants, je suis un peu confus quant au meilleur flux de travail. Il existe des dizaines de fichiers et de scripts XML impliqués, qui sont distribués dans une structure de répertoires non Maven. Globalement, plus de 3000 fichiers sont concernés. L'un des principaux problèmes est que je ne sais pas si je devrais vraiment essayer de tout migrer dans la structure de répertoires Maven connue et risquer donc de modifier et de refactoriser sans fin chaque fichier. Ou dois-je conserver la structure des dossiers telle qu'elle est et gonfler mes fichiers pom.xml et éventuellement rencontrer des problèmes avec tous les différents plugins impliqués? Honnêtement, les deux façons ne semblent pas très constructives.

Est-il même logique de migrer un projet dans cette dimension vers Maven? Surtout quand le framework SOA doit utiliser ses propres fichiers Ant - donc une combinaison de Ant et Maven serait nécessaire. Quelle serait la meilleure stratégie pour simplifier ce processus?

Merci pour toutes les suggestions.

David W. · Accepted Answer

Voici une réponse simple et rapide à Mavenizing an Ant project:

NE LE FAITES PAS !

Ce n'est pas une chape anti-Maven. J'utilise Maven et j'aime Maven. Cela oblige les développeurs à ne pas faire de bêtises. Les développeurs sont terribles à écrire des scripts de construction. Ils veulent faire les choses de cette façon et non pas comme tout le monde. Maven oblige les développeurs à configurer leurs projets d'une manière que tout le monde peut comprendre.

Le problème est que Ant permet aux développeurs de faire des choses folles et folles que vous devez refaire complètement dans Maven. C'est plus que la structure du répertoire. Ant permet plusieurs artefacts de construction. Maven n'en autorise qu'un par pom.xml¹. Que faire si votre projet Ant produit une demi-douzaine de fichiers jar différents - et que ces fichiers jar contiennent un grand nombre des mêmes classes? Vous devrez créer une demi-douzaine de projets Maven uniquement pour les jars, puis une autre demi-douzaine pour les fichiers communs aux jars.

Je le sais parce que j'ai fait exactement ça. Le chef de l'architecture du système a décidé que Maven est nouveau et bon alors que Ant doit être mauvais et mauvais. Peu importait que les versions fonctionnent et soient bien structurées. Non, Ant doit partir, et Maven est le chemin.

Les développeurs ne voulaient pas faire ça, donc c'est à moi, le CM. J'ai passé six mois à tout réécrire dans Maven. Nous avions WSLD, nous avions Hibernate, nous avions différents cadres et, d'une manière ou d'une autre, j'ai dû tout restructurer pour qu'il fonctionne à Maven. J'ai dû engendrer de nouveaux projets. J'ai dû déplacer des répertoires. J'ai dû trouver de nouvelles façons de faire les choses, le tout sans empêcher les développeurs de faire d'énormes quantités de développement.

C'était le cercle intérieur le plus enfer.

L'une des raisons pour lesquelles vos projets Ant sont si complexes est probablement liée à la gestion des dépendances. Si vous êtes comme notre boutique actuelle, un développeur a décidé de ~~pirater ensemble~~ développer leur propre système de gestion des dépendances. Après avoir vu ce système de gestion des dépendances, je sais maintenant deux choses que les développeurs ne devraient jamais écrire: leurs propres fichiers de construction et les systèmes de gestion des dépendances.

Heureusement, il existe déjà un système de gestion des dépendances pour Ant appelé Ivy . Ce qui est bien avec Ivy, c'est qu'il fonctionne avec l'architecture Maven actuelle. Vous pouvez utiliser le référentiel Maven centralisé de votre site et Ivy peut déployer des fichiers JAR dans ce référentiel en tant qu'artefacts Maven.

J'ai créé un projet Ivy qui configure automatiquement tout pour les développeurs. Il contenait l'installation et la configuration nécessaires, ainsi que quelques macros qui pourraient remplacer quelques tâches Ant standard. J'ai utilisé svn:externals pour attacher ce projet Ivy au projet principal.

L'ajout du projet dans le système de construction actuel n'a pas été trop difficile:

J'ai dû ajouter quelques lignes dans le build.xml pour intégrer notre ivy.dir projet dans le projet en cours.
Je devais définir un ivy.xml fichier pour ce projet.
J'ai changé n'importe quelle instance de <jar et </jar> à <jar.macro et </jar.macro>. Cette macro a fait tout le standard <jar/> la tâche l'a fait, mais elle a également incorporé le pom.xml dans le bocal comme le font les builds Maven. (Ivy a pour tâche de convertir le ivy.xml fichier dans un pom.xml).
J'ai arraché toutes les vieilles conneries de gestion des dépendances que l'autre développeur a ajoutées. Cela pourrait réduire un build.xml fichier d'une centaine de lignes. J'ai également arraché tous les trucs qui faisaient des vérifications et des commits, ou des trucs ftp'd ou scp'd. Tout cela était pour leur système de construction Jenkins, mais Jenkins peut gérer cela sans aucune aide des fichiers de construction, merci.
Ajoutez quelques lignes pour intégrer Ivy. Le moyen le plus simple était de supprimer les fichiers jars dans le répertoire lib, puis de les télécharger via ivy.xml. Au total, cela peut prendre une douzaine de lignes de code à ajouter ou à modifier dans le build.xml pour faire ça.

J'en suis arrivé au point où je pouvais intégrer Ivy dans un projet en quelques heures - si le processus de construction lui-même n'était pas trop gâché. Si je devais réécrire le build.xml à partir de zéro, cela pourrait me prendre deux ou trois jours.

L'utilisation d'Ivy a nettoyé notre processus de construction de fourmis et nous a permis de bénéficier de nombreux avantages que nous aurions à Maven sans avoir à effectuer une restructuration complète.

Soit dit en passant, l'outil le plus utile pour ce processus est Beyond Compare . Cela m'a permis de vérifier rapidement que le nouveau processus de construction était compatible avec l'ancien.

Passer à Maven quand même ...

Le plus drôle, c'est qu'une fois que vous avez intégré vos projets Ant avec Ivy, les transformer en projets Maven n'est pas si difficile:

Nettoyez la logique de votre build.xml. Vous devrez peut-être le réécrire à partir de zéro, mais sans la plupart des ordures de gestion des dépendances, ce n'est pas si difficile.
Une fois la build.xml est nettoyé, commencez à déplacer les répertoires jusqu'à ce qu'ils correspondent à la structure de Maven.
Changez la source pour correspondre à la nouvelle structure de répertoires. Vous pouvez avoir un fichier WAR contenant des fichiers * css dans un emplacement non standard, et le code est câblé pour attendre ces fichiers dans ce répertoire. Vous devrez peut-être modifier votre code Java pour correspondre à la nouvelle structure de répertoires.
Divisez les projets Ant qui génèrent plusieurs projets en projets Ant distincts qui génèrent chacun un artefact unique.
Ajouter un pom.xml et supprimez le build.xml.

¹ Oui, je sais que ce n'est pas entièrement vrai. Il existe des projets Maven avec des sous-projets et super poms. Mais, vous n'aurez jamais de projet Maven qui construit quatre pots différents non liés alors que c'est assez courant dans Ant.

Raibaz · Answer

J'ai fait une migration similaire dans le passé et j'avais les mêmes doutes que vous. cependant, j'ai opté pour la méthode "garder la structure des dossiers intacte et spécifier les chemins dans les fichiers POM" et j'ai remarqué que ce n'était pas aussi mauvais que je le pensais.

Ce que je devais réellement faire était de régler correctement le <sourceDirectory> et le <outputDirectory>et peut-être ajouter des filtres d'inclusion et d'exclusion, mais à la fin, je dirais que même si la méthode de Maven est vraiment conventionnelle sur la configuration-ish et vous facilite la vie si vous suivez ses directives sur l'endroit où placer les fichiers, il ne le fait pas pas vraiment le rendre beaucoup plus difficile si vous ne le faites pas.

En outre, quelque chose qui m'a vraiment aidé lors de la migration était la possibilité de diviser le projet Maven en modules, que j'ai d'abord utilisé pour répliquer la structure Ant (c'est-à-dire que j'avais un module Maven pour chaque fichier build.xml) faisant la première étape de la migration plus simple, puis j'ai changé l'agrégation du module pour le rendre plus significatif et plus semblable à Maven.

Je ne sais pas si cela a un sens pour vous, car je n'ai pas généré de fichiers Ant que je reconnais être le plus gros problème pour vous, mais je suivrais certainement cette route à nouveau au lieu de refactoriser et de déplacer des fichiers partout dans Mavenize ma structure de projet.