Maven 2.x Antrun Plugin

Plugin classpath problem in multi module maven project

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Duplicate
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    WindowsXP Pro
    jdk1.5.0_11
    MAVEN 2.0.9
  • Testcase included:
    yes
  • Number of attachments :
    1

Description

We have a pom.xml with <modules> :
<modules>
<module>./Module1</module>
<module>./Module2</module>
</modules>

In Module1 we use the define <dependencies>.
In Module2 we also define <dependencies> for maven-antrun-plugin with other <dependency>.

Problem when we display <echo message="plugin classpath: ${plugin_classpath}" />, in Module2 we have the classpath of the Module1.

The only workaround is to add specific <dependency> of Module2, in Module1 (for the maven-antrun-plugin plugin).

It looks like the plugin classpath is not updated for each Module.

Issue Links

This issue duplicates:
MANTRUN-51 Problems with multiple antrun declarations in multiproject Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Hannes Schmidt added a comment -

I can confirm this issue. The advertised workaround also works for me.

Show
Hannes Schmidt added a comment - I can confirm this issue. The advertised workaround also works for me.
Hide
Permalink
Ceki Gulcu added a comment -

It seems that if a antrun-plugin is declared in say module M0, then the dependency declaration
within the antrun-plugin are ignored nut only if building from the top-level directory. Building
from the module itself, that is from TOP_LEVEL/M0/ folder works fine.

I have tested this with Maven 2.0.8., 2.0.9 and 2.1.0-M1 as well as antrun-plugin and 1.1 and 1.2.

Show
Ceki Gulcu added a comment - It seems that if a antrun-plugin is declared in say module M0, then the dependency declaration within the antrun-plugin are ignored nut only if building from the top-level directory. Building from the module itself, that is from TOP_LEVEL/M0/ folder works fine. I have tested this with Maven 2.0.8., 2.0.9 and 2.1.0-M1 as well as antrun-plugin and 1.1 and 1.2.
Hide
Permalink
Jean-Marc Borer added a comment -

Same annoying issue for me.

There is another workaround than the one proposed by Alexandre.

Declare a root POM that modules 1 and 2 inherit and in the the pluginManagement section add the dependencies required by each of the plug-ins:
...
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<dependencies>
<dependency>
<groupId>com.example</groupId>
<artifactId>first</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>com.another</groupId>
<artifactId>second</artifactId>
<version>2.0</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</pluginManagement>
...
Well OK all antrun will inherit those dependencies. So if it is not a problem (version conflicts for example) I find this solution better as it avoids M1 to have a dependency on M2 or that you must count on the build order for your dependencies.

I hope this will be fixed soon. Is it the reactor or the ant plugin that causes this problem?

Show
Jean-Marc Borer added a comment - Same annoying issue for me. There is another workaround than the one proposed by Alexandre. Declare a root POM that modules 1 and 2 inherit and in the the pluginManagement section add the dependencies required by each of the plug-ins: ... <pluginManagement> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-antrun-plugin</artifactId> <dependencies> <dependency> <groupId>com.example</groupId> <artifactId>first</artifactId> <version>1.0</version> </dependency> <dependency> <groupId>com.another</groupId> <artifactId>second</artifactId> <version>2.0</version> </dependency> </dependencies> </plugin> </plugins> </pluginManagement> ... Well OK all antrun will inherit those dependencies. So if it is not a problem (version conflicts for example) I find this solution better as it avoids M1 to have a dependency on M2 or that you must count on the build order for your dependencies. I hope this will be fixed soon. Is it the reactor or the ant plugin that causes this problem?
Hide
Permalink
Jean-Marc Borer added a comment -

Duplicate

Show
Jean-Marc Borer added a comment - Duplicate
Hide
Permalink
Thorsten Möller added a comment -

Please, fix this bug.

It took me more than three hours to spot this bug and another two hours to integrate a nasty tweak in our builds since the suggested workarounds were not directly applicable for us.

Show
Thorsten Möller added a comment - Please, fix this bug. It took me more than three hours to spot this bug and another two hours to integrate a nasty tweak in our builds since the suggested workarounds were not directly applicable for us.
Hide
Permalink
Paul Gier added a comment -

This is a duplicate of MANTRUN-51

Show
Paul Gier added a comment - This is a duplicate of MANTRUN-51
Hide
Permalink
Anders Hammar added a comment -

I believe this issue is caused by a bug in Maven 2.x core, which is very unlikely to be fixed (bad code that can't be fixed). It should not be an issue with Maven 3.0.

Show
Anders Hammar added a comment - I believe this issue is caused by a bug in Maven 2.x core, which is very unlikely to be fixed (bad code that can't be fixed). It should not be an issue with Maven 3.0.

People

Vote (5)
Watch (6)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.