Discussion :

[waflyx]

Bonjour,

j'aurai besoin de conseils pour la migration de projet vers maven et de l'organisation au niveau de SVN.

Aucun outil de construction de projet est utilisé : la construction de arborescence de l'application est "gérée" par un checkout SVN grâce et à son système d'externals.


Application_X
--folderA
--folderB
--modules => possède 2 externals pour générer Module1 et Module2
----Module1
----Module2

Au niveau SVN, 3 projets:

Application_X
--trunk|branches|tags

Module1
--trunk|branches|tags

Module2
--trunk|branches|tags


Module1 et Module2 sont aussi utilisés par Application_Y dont le cycle de vie est différent de Application_X
=> les différents cycles de vie sont donc gérés par des branches SVN : pour préparer la sortie de version de Application_X, 3 branches sont alors crées, respectivement pour X, Module1 et Module2

On souhaite simplifier toute cette gestion, diminuer le nombre de branches (ou les créer uniquement en cas de besoin), éviter l'utilisation des externals et tout gérer avec maven (on serait tenté par gradle, mais maven semble nous donner un meilleur cadre pour débuter).

Donc à priori il faudrait organiser les choses ainsi :

Application_X
--pom.xml
--Module1
----pom.xml
--Module2
----pom.xml

Corrigez moi si je me trompe, mais au niveau de SVN je serai obligé de faire ceci:

Application_X
--trunk => 2 externals pointant respectivement vers Module1/trunk et Module2/trunk

=> est ce la bonne approche?
=> si oui, si je dois créer une branche pour Application_X, existe t-il un process maven qui va créer les branches pour les sous modules et mettra à jour les externals?

Au niveau d'eclipse, je souhaite que le résultat de la construction du projet soit ceci :

Application_X
--folderA
--folderB
--modules
----Module1
----Module2

A priori l'artéfact pour Application_X devrait être un POM. De ce fait, quel est ou dans quel POM dois je indiquer la façon dont se construit la globalité du projet afin de pouvoir le tester?


Merci d'avance de votre aide

[Cafeinoman]

Si j'ai bien compris, tu as deux applications, X et Y, qui dépendent toute les deux de deux modules, 1 et 2. Pour moi, il te faut

--pom.xml (le pom parent qui gère toute les dépendance dont les versions sont commune)
|
|--module 1
--|--contenu du module (le trunk)
--|--pom.xml (avec comme parent le pom du dessus)
|--module 2
--|--contenu du module (le trunk)
--|-pom.xml (avec comme parent le pom du dessus)
|--application X
--|--contenu de l'application (le trunk)
--|--pom.xml (avec comme parent le pom du dessus et comme dépendance les modules)
|--application Y
--|--contenu de l'application (le trunk)
--|--pom.xml (avec comme parent le pom du dessus et comme dépendance les modules)

Par contre je n'ai jamais essayer avec des modules ayant des versions différentes, mais logiquement, en lançant la compilation du pom parent, il devrait compiler les dernières version des enfants, dans l'ordre nécessaire aux dépendances, et si besoin aller chercher des versions plus anciennes dans le dépôt local, dans maven central ou dans tout dépôt que tu aura specifié.

ÉDIT : typo

[Logan Mauzaize]

Bon, je ne suis pas sûr d'avoir tout saisi mais voici mon point de vue.
Pour commencer, j'approuve la démarche de poser la gestion de configuration car c'est un réel problème dans beaucoup de projets. Et que peu traite alors que pour moi cela fait partie des bases comme l'architecture.
Donc !


Un premier grand principe tout simple : 1 cycle de vie 1 gestion de conf. Crois moi cela te sauvera de nombreux cheveux.
Autant Maven que les SCM (ie SVN) nécessite 1 branche => 1 version.

Ensuite oublie les externals. La gestion de configuration concerne autant les sources (SVN) que les binaires (Maven) mais il ne faut JAMAIS confondre les deux. Et Maven aide énormément la gestion de configuration des binaires en utilisant un dépôt dédié et relativement flexible.
En alertnative à Maven (ou autre système dedié), il aurait fallu mettre un place un dépôt de COTS (un simple filer bien organisé) ou un SVN dédié (là les externals auraient été justifiés).

[waflyx]

Bonjour merci pour vos réponse

@Logan Mauzaize
A l'heure actuelle, nos projets sont sous contrôle SVN et l'assemble est fait par des externals : c'est pas du tout pratique, c'est une des raisons pour laquelle nous avons besoin d'un outil de construction de projet...
Une des difficultés : comme bien gérer la gestion de configuration par maven et la gestion des sources par SVN pour ne pas utiliser les externals dans un contexte où plusieurs applications avec des cycles de vie différents partagent des modules communs (un module dans notre situation ne peut pas fonctionner de manière autonome, il a obligatoirement besoin de l'application)
Exemple concret
SuperApplication1
--moduleAgenda

HyperApplication2
--ModuleAgenda

@Cafeinoman
J'ai effectivement 2 applications X et Y (plus concrètement 2 produits totalement différents) qui dépendent des modules X et Y.
Le cycle de vie des deux produits ne sont pas identiques. Avec la structure proposée, j'ai alors l'impression de devoir releaser l'ensemble en même temps : module, application X et Y.
Le but est donc d'obtenir la meilleure configuration afin de pouvoir gérer deux applications différentes aux cycles de vie différent mais avec des modules en commun.
Pour complexifier l'ensemble, il faut garder le versionning SVN et limiter l'utilisation d'externals, or j'ai l'impression que je serai obligé de les garder, au moins pour définir la structure globale des projets parents (respectivement mes 2 applications X et Y).

[Logan Mauzaize]

Je me répète mais il faut traiter différemment les dépendances sources et binaires. Ce que tu veux traiter ce sont les dépendances binaires. Donc pas d'externals (sauf à utiliser SVN comme un dépôt de COTS).

application X, application Y, module 1 et module 2 ont chacun leurs cycles de vie. Chacun doit disposer de son dépôt SVN (ou de branches, mais ce n'est pas recommandé) pour gérer ses sources. Lorsque tu déploies une nouvelle version d'un produit (application X, application Y, module 1 ou module 2), tu vas pour simplifier les compiler et déposer les binaires dans un dépôt Maven.

Maven se chargera alors de récupérer les versions des binaires dont chaque produit a besoin pour compiler, tester et/ou s'exécuter.

Voici un exemple de vie :

1. ajout : module-1@1.0
2. ajout : module-2@1.0
3. ajout : application-X@1.0 => module-1@1.0, module-2@1.0
4. ajout : module-1@1.1
5. ajout : module-2@1.1
6. ajout : application-X@1.1 =>module-1@1.1, module-2@1.0
7. ajout : application-Y@1.0 => module-1@1.0, module-2@1.1
8. ajout : module-2@2.0
9. ajout : application-X@2.0 => module-1@1.0, module-2@2.0

[waflyx]

Nous sommes bien d'accord sur le fait que les binaires seront gérés par un dépôt Maven.

Comment résoudre cette problématique : je souhaite travailler sur les sources de l'application et des modules à la fois. En effet, l'application et les modules ne sont pas des modèles de conception, de ce fait, lorsque je dois faire une maintenance sur les modules, je suis obligé d'avoir l'application pour pouvoir tester (c'est pourquoi à l'heure actuelle, les sources des modules et de l'applications sont confondues et que cela est géré par des externals de SVN).

Si je reprends l'exemple du cycle de vie :

Voici un exemple de vie :

1. ajout : module-1@1.0
2. ajout : module-2@1.0
3. ajout : application-X@1.0 => module-1@1.0, module-2@1.0
4. ajout : module-1@1.1
5. ajout : module-2@1.1
6. ajout : application-X@1.1 =>module-1@1.1, module-2@1.0
7. ajout : application-Y@1.0 => module-1@1.0, module-2@1.1
8. ajout : module-2@2.0
9. ajout : application-X@2.0 => module-1@1.0, module-2@2.0

Concrètement, lorsque je dois développer pour produire module-1@1.1, si je me trompe pas, ceci m'obligerait à obtenir ces 2 projets sous mon IDE :

• avoir le projet "Application_X"
• avoir un autre projet "module-1"

Quelle est alors la meilleure pratique?
=> obliger le développeur de faire autant de checkout de projets que de modules sur lesquels il va travailler dessus
=> OU faire en sorte que lorsqu'il récupère le projet Application_X, le code source de tous les sous-modules s'y retrouvent à l'intérieur?

Pourquoi ce genre de question ? en fait, jusqu'à maintenant, on a toujours travaillé avec un projet Application_X et des externals pour ramener toutes les sources des modules dans l'application. Ceci implique alors beaucoup de problème de conception, car on induisait des couplages forts et bi-directionnels entre l'application et ses modules : le travail sous eclipse était par contre fluide car tout était sous le même projet (le checkout du projet était long, mais on pouvait travailler sur n'importe quelle module à tout moment...)

Je pense que c'était de toute façon une mauvaise pratique et qu'il vaudrait sûrement mieux faire plusieurs projets sous l'IDE pour l'application et chaque sous modules

[Logan Mauzaize]

Rien ne t'empêche de checkouter tous les projets pour travailler sur tous à la fois. L'external ici ne sert qu'à faciliter la vie du développeur, si c'est pour économiser trois "checkout", je vois pas bien l'intérêt ... surtout face au danger !
D'autant que tu devras répéter la gestion de configuration entre la valeur des liens externals et les déclarations dans le POM Maven. De plus, tu lies complétement les cycles de vie.


"application-X@?.?" n'est pas nécessaire au développement de "module-1@1.1". D'ailleurs, dans cette phase "module-1@1.1" n'existe pas, donc tu peux pas avoir de produit qui en dépend. C'est bien se raisonnement qui permet à "application-X@1.0" de continuer à exister quelque soit la vie que mène "module-1", tant que "module-1@1.0" n'est pas impacté.
Et c'est bien là le principe de la gestion de configuration. Tu peux indépendamment faire évoluer "application-X" et "module-1" sans impacter l'un ou l'autre. Éventuellement, un jour tu pourras "migrer" de la dépendance "module-1@1.0" vers "module-1@1.1".

En revanche, tu pourras au choix (c'est selon le niveau d'indépendance des équipes et APIs) avoir soit le projet "module-1" sous Eclipse lorsque tu développes "application-X", soit te contenter des sources attachées sous le dépôt Maven. Là c'est plus un problème de dépendance conceptuelle. J'ai bien peur que vous ayez eu tendance à faire de vos applications les cas de tests de vos modules.
Commencer à les spécifier, à les concevoir et à les tester de manière indépendantes de vos applications, au même titre que les autres dépendances de vos projets (ex: Java, JUnit, Spring, etc.)

Travailler avec Maven et sans externals, vous forcera à traiter vos modules comme de vrai produit à part entière. Et finira par améliorer la conception de vos produits de manière générale. En fonction de vos activités et/ou business, ce sera peut-être également l'occasion de créer de nouvelles opportunités pour ces produits.


Maven t'empêchera de faire des dépendances bi-directionnels, car tu ne dépendras pas d'un autre projet Eclipse mais d'un projet Maven. Et Maven n'autorise pas les dépendances cycliques.

[waflyx]

Rien ne t'empêche de checkouter tous les projets pour travailler sur tous à la fois. L'external ici ne sert qu'à faciliter la vie du développeur, si c'est pour économiser trois "checkout", je vois pas bien l'intérêt ... surtout face au danger !
D'autant que tu devras répéter la gestion de configuration entre la valeur des liens externals et les déclarations dans le POM Maven. De plus, tu lies complétement les cycles de vie.

=> ceci me confirme donc mon intérêt à supprimer cette gestion d'externals et à privilégier le checkout de modules uniquement lorsqu'on en a besoin : de toute manière, il est extrêmement rare qu'on ait besoin de faire la maintenance sur tous les modules à la fois.

En revanche, tu pourras au choix (c'est selon le niveau d'indépendance des équipes et APIs) avoir soit le projet "module-1" sous Eclipse lorsque tu développes "application-X", soit te contenter des sources attachées sous le dépôt Maven. Là c'est plus un problème de dépendance conceptuelle. J'ai bien peur que vous ayez eu tendance à faire de vos applications les cas de tests de vos modules
Commencer à les spécifier, à les concevoir et à les tester de manière indépendantes de vos applications, au même titre que les autres dépendances de vos projets (ex: Java, JUnit, Spring, etc.)

=> bonne analyse de ta part : nous débutons dans les tests unitaires et effectivement, et les applications étaient (et sont encore pour le moment) les seuls moyens de tester les modules... nous avons effectivement mis en évidence que nos modules sont trop couplés aux applications et qu'il faudra améliorer le code pour mieux gérer les dépendances...



En tout cas merci de ton aide : ceci m'a permis de bien clarifier la situation