Maven 2 & 3

Plugins' dependencies are not always checked

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 2.0.2
  • Fix Version/s: 2.0.9, 3.0-alpha-1
  • Component/s: Dependencies
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    5

Description

I want to run two ant task, one on the phase 'generate-sources' which contains a dependency and another on the phase 'package'.
When I want to compile with the project like that, maven don't check the dependency.
But when I comment the plugin on the phase 'package', maven check it.

PS: In the pom.xml in attachement, maven must check the library junit:junit:jar:30.80.10 (which don't exsist)

Issue Links

This issue relates to:
MNG-3719 [regression] plugin execution ordering no longer POM ordered in 2.0.9 Critical Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Yann Le Du added a comment -

Things get indeed weird if you use several <plugin>s with the same <artifactId> : attached pom-echo.xml echoes 2 times "Hello world, I'm in generate-resources"
A better way to achieve your goal is to merge these 2 <execution>s as in attached pom-merge.xml (you must use <id>s to avoid duplicate "default" id)

Show
Yann Le Du added a comment - Things get indeed weird if you use several <plugin>s with the same <artifactId> : attached pom-echo.xml echoes 2 times "Hello world, I'm in generate-resources" A better way to achieve your goal is to merge these 2 <execution>s as in attached pom-merge.xml (you must use <id>s to avoid duplicate "default" id)
Hide
Permalink
Daiyam added a comment -

Thanks Yann, I didn't know about id or default id of the execution tag.

I have the same problem with the pom-profile.xml, I have several <plugin>s with the same <artifactId> but one in the build tag and another in build tage of a profile.
When I run "mvn -P compile-schemas package", it's don't check the dependency of the profile's plugin.

Show
Daiyam added a comment - Thanks Yann, I didn't know about id or default id of the execution tag. I have the same problem with the pom-profile.xml, I have several <plugin>s with the same <artifactId> but one in the build tag and another in build tage of a profile. When I run "mvn -P compile-schemas package", it's don't check the dependency of the profile's plugin.
Hide
Permalink
Yann Le Du added a comment -

OK, I've made a small test suite, and here is a clumsy guess about the process. Let's assume that main <build> is assimilated to a <profile> (in first position).

  1. In an <execution>, if no <id> is defined, then <id>default</id> is added
  2. If an <execution> is defined in several activated <profile> with the same <id>, the <execution> in the last <profile> overwrites the <execution> in the first <profile>
  3. If several <execution> with different <id> are defined in several activated <profile> for the same <artifactId>, they are merged in the first <profile>
  4. If several <dependency> are defined in several activated <profile> for the same <artifactId>, they are NOT merged in the first <profile>
  5. If several <plugin> are defined in the same <profile> with the same <artifactId>, I don't know what happens
  6. If no <plugin> is defined in main <build> for a given <artifactId>, the one in the first <profile> is copied into main <build>

I think that :

  • because of points 1. and 2. , <id> should be mandatoty
  • point 4. should be corrected
  • situation in point 5. should not be allowed
Show
Yann Le Du added a comment - OK, I've made a small test suite, and here is a clumsy guess about the process. Let's assume that main <build> is assimilated to a <profile> (in first position).
  1. In an <execution>, if no <id> is defined, then <id>default</id> is added
  2. If an <execution> is defined in several activated <profile> with the same <id>, the <execution> in the last <profile> overwrites the <execution> in the first <profile>
  3. If several <execution> with different <id> are defined in several activated <profile> for the same <artifactId>, they are merged in the first <profile>
  4. If several <dependency> are defined in several activated <profile> for the same <artifactId>, they are NOT merged in the first <profile>
  5. If several <plugin> are defined in the same <profile> with the same <artifactId>, I don't know what happens
  6. If no <plugin> is defined in main <build> for a given <artifactId>, the one in the first <profile> is copied into main <build>
I think that :
  • because of points 1. and 2. , <id> should be mandatoty
  • point 4. should be corrected
  • situation in point 5. should not be allowed
Hide
Permalink
John Casey added a comment -

this has to do with plugins not being reconfigured inside a multmodule project, I think. It's a lifecycle/plugin management issue.

Show
John Casey added a comment - this has to do with plugins not being reconfigured inside a multmodule project, I think. It's a lifecycle/plugin management issue.
Hide
Permalink
Sei Syvalta added a comment -

Does that reconfiguration issue have a separate report, or should this be renamed?

Show
Sei Syvalta added a comment - Does that reconfiguration issue have a separate report, or should this be renamed?
Hide
Permalink
John Casey added a comment -

Integrated some of the tests from the test-suite.zip into plain junit tests at a lower level, to guard against these problems in the future. Thanks, those were very helpful.

Show
John Casey added a comment - Integrated some of the tests from the test-suite.zip into plain junit tests at a lower level, to guard against these problems in the future. Thanks, those were very helpful.

People

Vote (5)
Watch (5)

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.