Discussion :

[djeanprost]

Bonjour,

J'ai un certain nombre de questions/réflexions sur l'utilisation de la balise scm dans le pom, et les conséquences que cela peut avoir sur les plugins release et continuum.

Cela fait ~2 ans que nous avons mis en place maven dans ma société, et tout fonctionne à peu près bien.

J'ai opté pour l'approche d'avoir 1 parent-pom.xml dans lequel j'ai centralisé tout un tas de config maven. Chaque composant que nous développons (jar, war, ...) est indépendant des autres (au sens module du terme), mais s'utilisent quand même entre eux via des dépendances.
Chaque module fait référence au parent-pom pour obtenir les numéros de versions des artifacts communs (commons-collection, ...), la config du compilo, la config surefire, la config pour la géénration des sites, ...
Jusqu'à présent, mon parent-pom contient la balise scm comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
<scm>
		<connection>scm:svn:svn://vsrigel/trunk</connection>
		<developerConnection>
			scm:svn:svn://vsrigel/trunk
		</developerConnection>
	</scm>

Comme vous pouvez le voir, les urls de connexions mentionnent la racine de mon subversion, c'est à dire que le nom de l'artifact n'est pas présent dans l'url. Les modules utilisant ce parent-pom (tous en fait), ne mentionne pas du tout la balise <scm>. Il semble donc que la config par défaut fasse que le nom de l'artifact est rajouté automatiquement lorsque l'on fait des accès svn via le plugin release par exemple.
Cette config marche bien pour le quotidien de maven, c'est à dire que j'arrive à utiliser le plugin release.
J'utilise par ailleurs continuum (1.0.3), et je rencontre un problème non bloquant avec l'accès à scm.
Pour ajouter un projet, j'uploade le pom du projet. Je force ensuite un premier build, et tout va bien. Par contre, si je vais voir ensuite l'url scm du projet dasn continuum, l'url est fausse. Elle est de la forme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

scm:svn:svn://vsrigel/trunk/parent-pom-numéroversion/nomdelartifact

, c'est à dire qu'il a rajouté dans le chemin le nom de l'artifact du parent-pom. Bien que l'url affichée soit fausse, les futurs archivages de source par le développeur déclenchent bien l'update des sources, et continuum continue bien à fonctionner.

Dernièrement, nous avons du créer une branche pour un composant, et je n'arrivais pas à trouver comment faire une release avec le plugin release sur la branche.
En y réfléchissant, j'ai compris que l'url du scm devrait pointer sur la branche, et que par voie de conséquence, la config que j'utilisais jusqu'à présent était sans doute mauvaise.

Ma question est donc aujourd'hui : devrais-je changer mon fusil d'épaule et donc :

1. supprimer la balise <scm> de mon parent-pom
2. rajouter cette balise <scm> dans chacun des composants, en mentionnant l'url complète c'est à dire svn://vsrigel/trunk/nomartifact

Est-ce que mon raisonnement se tient ? Est-ce que le problème que je rencontre avec continuum est lié à cette mauvaise configuration, ou bien alors à un bug de la version que j'utilise ?
Que me conseillez-vous ?

Merci d'avance
Dom

[romaintaz]

Je suis un peu étranger à tout cela dans le sens où je n'utilise pas les plugins release (il faudrait pour celui-là) et continuum...
Toutefois, une idée comme ça :

Tu peux spécifier une propriété dans ton pom parent, du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<properties>
    <scm-root>scm:svn:svn://vsrigel/trunk</scm-root>
</properties>

Dans chaque sous projet, tu définis alors le SCM de la façon suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
<scm>${scm-root}/xxx</scm>

où xxx indique le positionnement du projet courant sur le SCM...

[djeanprost]

Je suis un peu étranger à tout cela dans le sens où je n'utilise pas les plugins release (il faudrait pour celui-là) et continuum...
Toutefois, une idée comme ça :

Tu peux spécifier une propriété dans ton pom parent, du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<properties>
    <scm-root>scm:svn:svn://vsrigel/trunk</scm-root>
</properties>

Dans chaque sous projet, tu définis alors le SCM de la façon suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
<scm>${scm-root}/xxx</scm>

où xxx indique le positionnement du projet courant sur le SCM...

bonjour,

Merci pour cette réponse. Ma question n'est pas tellement sur comment factoriser de la config sur les urls de connexions (pour laquelle ta réponse me semble pertinente), mais plutôt si je devrais ou pas mentionner dans chaque composant l'url de connexion, ou bien continuer comme je le fais actuellement, c'est à dire en ne précisant pas pour chaque composant l'url de connexion, tout en s'appuyant sur un comportement par défaut autour de la gestion de la balise <scm>.

dom

[rseM2]

Bonjour,

De notre côté, on a opté pour mettre le moins de choses possible dans le pom corporate. Une des raisons est que ce pom étant utilisé par tous les projets, la moindre modification a des impacts importants. De plus, on a trouvé que c'était assez difficile d'avoir une configuration générique pour tous les projets.

On s'était posé la question du scm aussi. On a finalement préféré l'enlever pour éviter tout problème. De même pour la génération des sites web.

On s'oriente plutôt sur un pom corporate très simple et l'utilisation d'archetypes pour configurer un projet type d'entreprise. On attend bien attendu la prochaine release du plugin archetype qui ne devrait plus tarder (enfin on espère...) d'après les dernières infos sur la mailing liste maven-dev.

Néanmoins, ce serait intéressant d'avoir d'autres retours/stratégies.

Rémy

[djeanprost]

Bonjour,

De notre côté, on a opté pour mettre le moins de choses possible dans le pom corporate. Une des raisons est que ce pom étant utilisé par tous les projets, la moindre modification a des impacts importants. De plus, on a trouvé que c'était assez difficile d'avoir une configuration générique pour tous les projets.

On s'était posé la question du scm aussi. On a finalement préféré l'enlever pour éviter tout problème. De même pour la génération des sites web.

On s'oriente plutôt sur un pom corporate très simple et l'utilisation d'archetypes pour configurer un projet type d'entreprise. On attend bien attendu la prochaine release du plugin archetype qui ne devrait plus tarder (enfin on espère...) d'après les dernières infos sur la mailing liste maven-dev.

Néanmoins, ce serait intéressant d'avoir d'autres retours/stratégies.

Rémy

Ce que je comprends de ce que tu dis est que vous avez mis la balise <scm> avec l'url complète (y compris nom de l'artifact) dans le pom de chacun des composants ?

Peux-tu préciser ?
dom

[rseM2]

Ce que je comprends de ce que tu dis est que vous avez mis la balise <scm> avec l'url complète (y compris nom de l'artifact) dans le pom de chacun des composants ?

Peux-tu préciser ?
dom

Non pas tout à fait. Nous mettons la balise scm avec l'url complète dans le pom du projet. Dans le cas des projets multi-modules, il suffit de le mettre dans le pom parent. Il n'y a pas besoin de le mettre dans le pom des modules (si on suit la convention que le nom des modules et le nom des répertoires correspondants sont identiques).

Rémy