J'utilise Maven 2.2 avec Nexus 1.4.0
Disons que j'ai une structure pom-forme comme celle-ci (avec des versions correspondantes) enfantProj1 et enfantProj2 représentent différentes parties de l'application (par exemple, GUI et Backend) et je souhaite pouvoir séparer leurs versions afin que je puisse libérer une nouvelle version du backend sans avoir à publier une nouvelle version de l'interface graphique. < P> Maintenant, pour déployer cette structure à Nexus, il serait pratique d'aller à ParentProj et dire MVN Déployer -dperformRelease = true
qui déploierait tous les artefacts au référentiel Nexus Realease. Cela fonctionne bien la première fois que je le déploie, mais la deuxième fois que je rencontre des problèmes: disons que j'ai fait une mise à jour à ChildProj1 afin que nous ayons maintenant les versions suivantes: mais je suppose que ce que je voudrais faire, c'est pouvoir dire à Maven quelque chose comme "Déployer uniquement ces artefacts qui ont des versions qui ont des versions qui ne sont pas déjà présents dans le référentiel de libérés ". existe-t-il un moyen de le faire, ou devrais-je devoir déployer chaque projet par lui-même?
5 Réponses :
Dans mon expérience, il a été plus facile de tout déployer et utilisez souvent le même numéro de version pour tous les composants. Par exemple, si mon équipe travaille sur la version 1.0.7, tous les sous-modules ont le numéro de version de 1.0.7-Snapshot, jusqu'à ce que nous publions, même si aucun code n'a changé dans certains modules. Ensuite, lorsque nous déployons, nous déploiions toute l'application. Je pense que cela présente plusieurs avantages sur un déploiement fragmenté. Premièrement, si vous avez toutes les prises de retourner à la dernière version stable, il vous suffit de passer à 1.0.6 pour tous les modules - vous n'avez pas à vous rappeler que le backend était de 1,0,3 tandis que l'interface graphique était de 1,0,6. Deuxièmement, il garantit que tous les composants sont compilés correctement les uns contre les autres et ont été testés en tant que groupe logique.
Désolé, je sais que ce n'est pas une réponse spécifique à votre question, mais au moins dans le cas de mon équipe, il était utile de penser légèrement différemment
Merci pour vous de répondre à John, nous étudions cette approche aussi et cela pourrait très bien être celui à prendre à la fin. Je conviens que la cohérence de la version apporte beaucoup de valeur, mais je crains également que, pour un projet important, le processus de construction pourrait devenir trop ballonné et que le temps prend du temps si vous devez mettre à niveau toute la plate-forme pour tout changement.
+1 Pour suggérer l'utilisation (appropriée et correcte) du qualificatif d'instantané sur la version pour résoudre ce problème.
Je ne suis pas d'accord avec la dernière déclaration à propos d'être compilé ensemble et testé ensemble. Si vous avez des dépendances de version fixes sur les pots, Maven compilera votre projet à l'aide de ces pots afin que vous obtiendrez toujours tout ce qui est compilé avec des dépendances d'instantané ou de version fixe. En ce qui concerne les tests, avec de véritables tests unitaires, je pense que les dépendances de la classe, en particulier sur les limites des JAR, devraient être moquées. Cela signifie que votre code n'est jamais testé, sauf si vous avez des tests fonctionnels / d'intégration exécutés contre l'application déployée, puis une instantanée ou une version fixe n'aurait plus d'importance.
Je suggérerais que si vous envisagez de maintenir, de construire et de déployer les modules indépendamment, vous devez envisager de configurer des travaux distincts CI et Si vous voulez tout faire de l'agrégateur POM, comme Construire et déployez, je vous suggère de suivre la réponse de John et de garder tout le numéro de version en Sync.
Cela dépend simplement de la façon dont votre équipe souhaite examiner la base de code. Si vous souhaitez garder les choses de manière modulaire vraie, vous devez utiliser vos modules maven comme des blocs de construction, les traiter différemment, jusqu'à ce que vous soyez prêt à mettre toute l'application ensemble. Si votre application est de nature plus monolithique, traitez-la comme et gardez les choses en synchronisation. Cela ne signifie pas que vous ne pouvez toujours pas sortir des modules de Maven distincts pour maintenir la modularité de la base de code, il suffit de reconnaître qu'ils n'ont aucune valeur en dehors du contexte de votre plus grande application.
Un bon moyen de faire cette décision est de vous demander «quels autres projets / applications» devront-il faire référence à ce module comme une dépendance? ». Si tel est le cas, il est préférable de construire, de la version et de le déployer de manière indépendante. Sinon, je ne vois pas de pièges à faire correspondre les versions. MVN Déployer pour chacun. Avoir des emplois indépendants mvn déployer vous donnera le comportement que vous recherchez hors de la boîte. Cela signifie ne pas utiliser l'agrégateur POM (Parentprj) pour tenter de construire et de déployer ces modules.
Tout d'abord, je pense que vous devriez faire la distinction entre projet parent et projet d'agrégation. Les projets parents doivent être utilisés pour ces paramètres communs à plusieurs projets, par exemple. Versions des dépendances; Les projets d'agrégation doivent être utilisés afin de construire en même temps un groupe de projets, par exemple. un ensemble de pots et de la guerre qui les inclut.
Les deux types de projets sont mieux tenus séparés. Le projet parent ne change généralement pas très souvent et quand il est généralement préférable de libérer de nouvelles versions de tous les projets qui en dépendent; Le seul but du projet d'agrégation est de conduire la construction d'un tas de projets, de sorte que son numéro de libération devrait probablement changer chaque fois que l'un des projets qu'il contient doit être libéré.
Une fois que vous avez séparé le parent de l'agrégateur, vous avez une meilleure position pour choisir de suivre les conseils de John Paulett et de tout garder au même numéro de version ou d'essayer de modifier le numéro de version de chaque projet uniquement lorsque vous devez réellement publier ce. La première option est la plus simple et moindre des erreurs, mais vous permet de libérer une nouvelle version de bibliothèques qui n'ont pas changé. Cela pourrait ne pas être acceptable si, par exemple, vous devez expédier des correctifs plutôt que des versions complètes. La deuxième option est plus compliquée et plus suure d'erreur, mais amène vos numéros de version correspond à l'évolution de votre logiciel. Le plugin de sortie Maven et l'outil d'intégration continue Jenkins peuvent vous aider, je pense que vous devriez les vérifier. Voir également si vous pouvez mettre à niveau Maven vers au moins la version 2.2.1 et Nexus à une version plus récente.
+1 pour distinguer les poms d'agrégateur parent vs. Pour plus de détails sur la différence, lisez à propos de l'héritage et de l'agrégation de POM: maven.apache.org/guides/introduction/...
Il est clair que ce besoin n'est pas abordée par Maven, ni par Nexus ou archiva. Pour l'instant, il ne peut être résolu par la configuration des astuces supplémentaires par le gestionnaire de construction comme ceux suggérés dans les messages précédents.
Dans un monde idéal
la pom comprendrait
. à la fois la version et la version instantanée du module
. une définition des fichiers qui, si elle a changé, justifient l'utilisation de la version d'instantané
. le système de gestion de contrôle source de référence du module publié
modules dépendants poms ajouterait dans la section de dépendance appropriée les informations de version de la prochaine version de l'information de version snapshot afin qu'il relie à la bibliothèque de capture instantanée si elle est présente dans le dépôt et la bibliothèque de sortie autrement
le réacteur Maven aurait la possibilité de lire à la fois la hiérarchie des dépendances et le fichier change d'information (GCA diff) pour savoir si un module donné doit être utilisé dans sa version ou une version instantanée. < / li>
Je vous suggérerais d'artefact existez Maven Plugin ( https://github.com/chonton/ Existe-Maven-Plugin ). Cette chose merveilleuse nécessite seulement d'être mentionnée sur le parent.pom et sautera automatiquement la phase d'installation et de déploiement pour tous les artefacts de libération, qui existe déjà dans le référentiel (Nexus ou Artefactory). Et toujours déployer les instantanés (ceci est configurable).
Exemple: