Configuration des plugins dans le parent-POM

Version imprimable

(re)Bonjour à tous,

Afin d'économiser des lignes les POM, j'ai préconfiguré le plugin webstart à partir des infos répétées dans les projets fils qui l'utilisent :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
 
<pluginManagement>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-compiler-plugin</artifactId>
			<version>2.0.2</version>
 
			<configuration>
				<source>1.5</source>
				<target>1.5</target>
				<encoding>UTF-8</encoding>
			</configuration>
		</plugin>
...
		<plugin>
			<groupId>org.codehaus.mojo.webstart</groupId>
			<artifactId>webstart-maven-plugin</artifactId>
			<version>1.0-alpha-2</version>
			<executions>
				<execution>
					<phase>process-resources</phase>
					<goals>
						<goal>jnlp-download-servlet</goal>
					</goals>
				</execution>
			</executions>
 
			<configuration>
				<outputDirectoryName>webstart</outputDirectoryName>
 
				<sign>
					<keystore>/home/toto/security/toto.jks</keystore>
					<keypass>toto</keypass>
					<storepass>toto</storepass>
					<alias>webstart</alias>
 
					<verify>true</verify>
				</sign>
				<unsign>true</unsign>
				<verifyjar>false</verifyjar>
			</configuration>
		</plugin>
	</plugins>
</pluginManagement>

Or, sous Eclipse avec le plugin m2, je remarque que les infos <sign> semblent se balader une fois remontées dans les POM enfants (Effective POM) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
 
<plugin>
        <groupId>org.codehaus.mojo.webstart</groupId>
        <artifactId>webstart-maven-plugin</artifactId>
        <version>1.0-alpha-2</version>
        <executions>
          <execution>
            <phase>process-resources</phase>
            <goals>
              <goal>jnlp-download-servlet</goal>
            </goals>
            <configuration>
              <jnlpFiles>
                <jnlpFile>
                  <templateFilename>jnlp-servlet-template.vm</templateFilename>
                  <outputFilename>redaction.jnlp</outputFilename>
                  <jarResources>
                    <jarResource>
                      <groupId>fr.toto.redaction</groupId>
                      <artifactId>editeur-redaction</artifactId>
                      <version>1.0.0-SNAPSHOT</version>
                      <mainClass>fr.toto.redaction.Redaction</mainClass>
                    </jarResource>
                  </jarResources>
                </jnlpFile>
              </jnlpFiles>
              <outputDirectoryName>webstart</outputDirectoryName>
              <sign>
                <keystore>/home/toto/security/toto.jks</keystore>
                <keypass>toto</keypass>
                <storepass>toto</storepass>
                <alias>webstart</alias>
                <verify>true</verify>
              </sign>
              <unsign>true</unsign>
              <verifyjar>false</verifyjar>
            </configuration>
          </execution>
        </executions>
        <configuration>
          <jnlpFiles>
            <jnlpFile>
              <templateFilename>jnlp-servlet-template.vm</templateFilename>
              <outputFilename>redaction.jnlp</outputFilename>
              <jarResources>
                <jarResource>
                  <groupId>fr.toto.redaction</groupId>
                  <artifactId>editeur-redaction</artifactId>
                  <version>1.0.0-SNAPSHOT</version>
                  <mainClass>fr.toto.redaction.Redaction</mainClass>
                </jarResource>
              </jarResources>
            </jnlpFile>
          </jnlpFiles>
          <outputDirectoryName>webstart</outputDirectoryName>
          <sign>
            <keystore>/home/toto/security/toto.jks</keystore>
            <keypass>toto</keypass>
            <storepass>toto</storepass>
            <alias>webstart</alias>
            <verify>true</verify>
          </sign>
          <unsign>true</unsign>
          <verifyjar>false</verifyjar>
        </configuration>
      </plugin>

Alors que j'ai simplement écrit :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
<plugin>
	<groupId>org.codehaus.mojo.webstart</groupId>
	<artifactId>webstart-maven-plugin</artifactId>
 
	<configuration>
		<jnlpFiles>
			<jnlpFile>
				<templateFilename>jnlp-servlet-template.vm</templateFilename>
				<outputFilename>redaction.jnlp</outputFilename>
				<jarResources>
					<jarResource>
						<groupId>${project.groupId}</groupId>
						<artifactId>editeur-redaction</artifactId>
						<version>${project.version}</version>
						<mainClass>fr.toto.redaction.Redaction</mainClass>
					</jarResource>
				</jarResources>
			</jnlpFile>
		</jnlpFiles>
	</configuration>
</plugin>

Quelque chose doit encore m'échapper... les sections sont-elles systématiquement considérées comme de la configuration ? Est-ce que c'est grave, docteur ?

Merci d'avance.

09/09/2011, 09h40
tchize_

Je comprend pas, tu met ces informations dans le parent en plugin management, et tu t'étonne que les enfants l'utilisent? C'est un peu normal, c'est justement pour ça qu'on les met dans le parent :roll:
09/09/2011, 15h52
ThomasEscolan

C'est-à-dire que je pars du principe que pluginManagement, comme dependencyManagement, est une une balise de configuration, pas de déclaration... Mais je dois me tromper... C'est l'objet de la question.
Tu comprends, là ?
09/09/2011, 16h27
tchize_

Oui, tu configure ce plugin dans le parent, tu déclare l'utiliser dans l'enfant, normale que l'effective pom obtienne la fusion des deux. Si c'était pas le cas (deux déclarations, avec une étant inheritable), tu aurais 2 balise plugin pour webstart et pas une seule.
13/09/2011, 09h26
ThomasEscolan

:cry: j'cooomprends rieeeeeennnnn...
Au final, c'est grave, ou pas ? Est-ce que c'est la bonne façon de procéder ?
Je voudrais configurer le plugin de manière centralisée mais ne l'utiliser que là où c'est nécessaire.
13/09/2011, 10h01
Malatok

Bonjour si je ne me trompe pas l'élément <pluginManagement> comme pour la gestion des dépendances ne permet que de centraliser les versions des plugins utilisés par chaque module du projet.

Il permet aussi de centraliser la configuration des plugins exemple la version du jdk utiliser ect..

Donc normale que tous les modules de ton projet soit configurer pareille vu que la configuration a étais mise dans ton parent.

Si tu veux une configuration type tu redéfini le plugin pour un module.

Par défaut si tu défini tout les plugins utilisées de ton projet dans ton pom parent alors forcément tout tes enfants auront ces plugins.

Si il n'y a que 1 module qui utilise un plugin pourquoi le mettre dans le parent?

En gros : Conserve dans un module donné que ce qui lui est totalement spécifique.
Si ton plugin a plusieur déclaration pour différent modules pourquoi le remonté dans le parent ?

Cdlt.
13/09/2011, 11h02
tchize_

Citation:

Envoyé par tooms4444

:cry: j'cooomprends rieeeeeennnnn...
Au final, c'est grave, ou pas ? Est-ce que c'est la bonne façon de procéder ?
Je voudrais configurer le plugin de manière centralisée mais ne l'utiliser que là où c'est nécessaire.

Ben si t'en a pas besoin dans le pom enfant, ne mentionne pas ce plugin dans le pom enfant, simplement, je vois pas ce qu'il y a de dur à comprendre.
15/09/2011, 17h08
ThomasEscolan

Si je comprends bien ; il y a une balise <configuration> dans <plugin> (parce qu'elle remonte du POM parent) et une balise <configuration> dans <execution> (parce que je déclare le plugin dans le POM enfant). Et c'est normal, donc.
J'ai bon ?
16/09/2011, 09h18
romaintaz

Citation:

Envoyé par tooms4444

Si je comprends bien ; il y a une balise <configuration> dans <plugin> (parce qu'elle remonte du POM parent) et une balise <configuration> dans <execution> (parce que je déclare le plugin dans le POM enfant). Et c'est normal, donc.
J'ai bon ?

Bonjour,

Pour information : il est effectivement possible de placer une balise <configuration>au niveau du noeud <plugin>, mais également au niveau <execution>.
Dans le premier cas, on donne une configuration globale du plugin, qui est donc valable pour chaque exécutions. Dans le second cas, on définit une configuration spécifique à une exécution donnée, et qui ne sera donc applicable que pour cette exécution-là.