Hello,
This is with Maven 2.2.1.
I have an aggregate POM file that contains 2 child projects, say
project A and project B.
Each of these child projects uses a custom build plugin. Project A
calls it like
<build>
<plugins>
<plugin>
<groupId>myGrupId</groupId>
<artifactId>myArtifactId</artifactId>
<version>1.0</version>
<dependencies>
<dependency>
<groupId>my-dep-1-group</groupId>
<artifactId>my-dep-1-artifactId</artifactId>
<version>my-dep-1-version</version>
<classifier>data</classifier>
<scope>compile</scope>
</dependency>
</dependencies>
<configuration>
<myParam1>param</myParam1>
</configuration>
<executions>
<execution>
<id>EXEC1</id>
<phase>generate-sources</phase>
<goals>
<goal>generate-code</goal>
</goals>
<configuration>
<p2>param2<//p2>
</configuration>
</execution>
</executions>
<plugin>
</plugins>
</build>
Basically it invokes a custom MOJO in the generate-sources phase. The
plugin uses information on the classpath (among other things) to
determine what code to generate.
Child project 2 has the exact same setup "however" it changes the
dependency defined in the plugin to be dependent on a different project.
When I build each project individually, they build perfectly fine.
However, when I build the aggregate project, child project 2 fails
because it is using the dependencies of the first project. I have
verified this with various dumps of the class path, etc. I have tried
inheriting the plugin information, separate plugin definitions in the
child project, many configurations. It always seems that the first time
a plugin is loaded that is the classpath used for that plugin whenever
it is executed.
Is this a bug? I would have expected the inline dependencies to work
just like the configuration section of a plugin, basically it is for
that invocation only.
If this is not a bug, how should I be invoking the same plugin twice,
with different class paths, within the same build.
Thank
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
