Discussion :

[Frederik]

Bonjour...

J'ai un pom parent dont découlent plusieurs pom enfants.
J'essaye de faire passer la propriété ${basedir} du pom parent aux pom enfants et c'est le ${basedir} du pom parent qui est pris en considération.

Quelqu'un a t'il une idées.

Ceci éviterait que je mette des "../../../../../" entre les balises <sourcedirectory/>.

D'avance Merci à tous

[romaintaz]

Une idée :

Dans le pom.xml parent :

Code :

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

1
2
3
4
 
<properties>
    <basedir.parent>${basedir}</basedir.parent>
</properties>

Ensuite, dans les enfants, il te suffira d'utiliser ${basedir.parent} pour obtenir le basedir du parent

[youpla]

Ta solution ne marche pas. Je l'ai tentée (je suis un collègue de Frédérick). En fait les properties Maven ne sont pas static mais d'instance. Par conséquent chaque POM enfant va faire la résolution de la propriété parent.basedir qui vaudra alors ${basedir} du POM enfant (pour en avoir le coeur net, exécuter la commande mvn help:effective-pom). Par contre je suis arrivé à contourner le problème. Comme on exécute que le Pom Parent, via la commande mvn compile par exemple et à partir du dossier ou il se trouve, le parent.basedir = user.dir java (System.getProperty("user.dir).
Il manque à Maven la notion de propriété statiques (ce qui est super important à mon sens). Par contre j'ai une autre petite question, est il possible d'utiliser des propriétés définies dans un fichier porperties directement comme propriétés dans les POMs ou sont elles exclusivement réservées dans le cadre du filtrage des ressources ?

[romaintaz]

Hélas tu rejoins là un de mes problèmes que j'ai eu un temps :

Je voulais définir toutes les versions de mes pom (projet parent + projet enfants) dans un fichier properties.
Cela est possible avec Maven 1, mais visiblement pas avec Maven 2...

Je n'ai jamais trouvé le moyen de définir une information telle que le numéro de version à l'extérieur du pom...
Donc si quelqu'un a une idée, je serais super prenneur aussi !

[youpla]

Je suis prenneur également, je trouve qu'il est dommage qu'ils aient restreint l'utilisation des fichiers properties au filtrage

[romaintaz]

D'autant que cela marchait avec Maven 1...
C'est ce que j'appelle une régression moi

[rseM2]

Bonjour,

Concernant la propriété ${basedir}, avez-vous essayé la propriété ${project.parent.basedir} ?
cf. post http://markmail.org/message/4sioanbligdkfljg

Rémy

[youpla]

Non je n'y avais pas pensé, je vais essayé ce soir et je te tiens au courant. Merci de ta proposition de solution qui est bien plus élégante que la mienne

[DanielW33]

Concernant la propriété ${basedir}, avez-vous essayé la propriété ${project.parent.basedir} ?

Cette declaration fonctionne tres bien mais on ne peut l'utilisé sur le pom parent ( et pour cause il ne possede pas de parent )

et si la profondeur des modules est superieure a 2,il y a probleme : on revient au meme probleme qu'avec ${basedir}.

[rseM2]

Cette declaration fonctionne tres bien mais on ne peut l'utilisé sur le pom parent ( et pour cause il ne possede pas de parent )

Oui mais dans ce cas ${basedir} suffit.

et si la profondeur des modules est superieure a 2,il y a probleme : on revient au meme probleme qu'avec ${basedir}.

Oui j'avais oublié de mentionner cette limitation.
Néanmoins, une grande partie des projets n'ont qu'un niveau et si on a deux ou plus niveaux on n'a pas toujours besoin de remonter de plus d'un niveau. Donc ca peut au moins servir dans ces cas-là.

Mais tu as tout à fait raison d'indiquer que cela ne règle pas le problème dans sa globalité.

Rémy

[youpla]

J'ai essayé d'utiliser la methode ${project.parent.basedir} dans mes POMs enfant. Sauf erreur de ma part cela ne marche pas. Pour ce qui est de la profondeur de l'arbre d'héritage il n'est que d'un ce qui devrait en principe marchait correctement.
Je referais un tests demain pour être sur que cela ne marche pas.

[rseM2]

Normalement, ca devrait fonctionner à part s'il y a eu une régression avec la v2.0.8 (ca fait longtemps que je n'ai pas testé).

Essaye de regarder si le problème ne vient pas d'ailleurs. Utilise l'option -X pour debugger et essaye aussi avec le chemin complet dans le pom pour voir si tu as le même comportement. A tout hasard, as-tu des espaces dans le nom de ton chemin absolu ? On ne sait jamais ca pourrait poser des problèmes.

Rémy

[romaintaz]

Une question m'interroge :

basedir, c'est bien le répertoire racine où se trouve le projet Maven actuel ? En gros le répertoire où se trouve le fichier pom.xml...

Par exemple, si mon projet se trouve sur C:\Dev\MonProjet (donc j'ai C:\Dev\MonProjet\pom.xml), alors ${basedir} = C:\Dev\MonProjet.
J'ai bon ?

Maintenant, si on considère que mon projet à un parent, ce parent va être retrouvé par Maven sur mon repository local (ou à défaut le repository global). Du coup, quelle est la signification du ${project.parent.basedir} ?

J'exclue de ma réflexion le cas où on définit la localisation physique du parent, c'est-à-dire :

Code :

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

1
2
3
4
<parent>
    ...
    <relativePath>...</relativePath>
</parent>

[youpla]

Même avec l'élément relativePath, ${project.parent.basedir} ne marche pas.

[evenisse]

Question idiote: pourquoi utilisez-vous basedir, ou plus exactement, pourquoi avez-vous besoin d'accéder au répertoire du/des parents.

romaintaz: ce n'est pas une régression. maven 1 et maven 2 fonctionne différemment. avec maven 1 le parent était accessible par un path alors que maven 2 utilise une dépendance. Par définition, avec maven2, le pom enfant est totalement indépendant du pom parent au niveau du filesystem.

[Frederik]

Les projets sont découpés en couches.

CoucheX
FichierParamétrage
configuration.xml
BlocFonctionnel
---API
pom.xml
impl
---IMPLEMENTATIONS
pom.xml
pom.xml

CoucheY
FichierParamétrage
configuration.xml
BlocFonctionnel
---API
pom.xml
impl
---IMPLEMENTATIONS
pom.xml
pom.xml

CoucheZ
FichierParamétrage
configuration.xml
BlocFonctionnel
---API
pom.xml
impl
---IMPLEMENTATIONS
pom.xml

pom.xml

le pom.xml à la racine d'un projet permet est de type pom. Il permet à l'aide des balises <modules/> d'accéder aux pom.xml enfants.

Néanmoins mes pom.xml enfants doivent accéder aux fichiers de configuration.xml.

C'est donc pour cette raison que je me sers de plusieurs "../../../../" pour préciser l'emplacement de la ressource dans le plugin <resources>

[rseM2]

Question idiote: pourquoi utilisez-vous basedir, ou plus exactement, pourquoi avez-vous besoin d'accéder au répertoire du/des parents.

Quand on avait eu besoin de cela, c'était pour une question de génération de rapport pour le site web. On voulait mettre les fichiers de règles pour pmd... et autres pages pour le site web au niveau du parent. Certains modules devaient donc pouvoir accéder à ces fichiers de règles. Il fallait pouvoir gérer le fait qu'on puisse lancer la commande maven, à la fois de la racine du projet que des modules eux-mêmes.

Il y a peut-être une meilleure facon de faire (je pense éventuellement au dependency:unpack qui n'était pas disponible/connu à l'époque). Si tu as une idée la dessus, je suis preneur car j'ai du mal à bien comprendre les bonnes pratiques pour la gestion de sites web avec des projets multi-modules (et même multi-projets).

Rémy

[evenisse]

Effectivement, dependency:unpack ou équivalent est une bonne pratique.
Pour PMD, il faut accéder au fichier de ruleset avec une URL au lieu d'un path relatif vers un fichier.

[abaill]

Hélas tu rejoins là un de mes problèmes que j'ai eu un temps :

Je voulais définir toutes les versions de mes pom (projet parent + projet enfants) dans un fichier properties.
Cela est possible avec Maven 1, mais visiblement pas avec Maven 2...

Je n'ai jamais trouvé le moyen de définir une information telle que le numéro de version à l'extérieur du pom...
Donc si quelqu'un a une idée, je serais super prenneur aussi !

Bonjour, je me permets de remonter cet ancien message pour savoir si quelqu'un avait trouvé une solution à ce problème ou pas encore ?

Merci d'avance !