Maven 2 & 3

Plugins that require dependency resolution in early phases cause dependency resolution issue

Details

  • Number of attachments :
    1

Description

What we're seeing is that some multi-project configurations succeed on
'mvn package' but fail on 'mvn generate-sources'. They are failing when
one project in the reactor references another project in the reactor
which is not installed in the local repo. It seems that the referenced
project has not quite "made it" into the reactor this early in the phase
lifecycle. But it does work correctly if you target a later phase at the
outset which is really confusing.

The problem only occurs when a plugin binds itself to the
generate-sources phase and has @requiresDependencyResolution, presumably
because this is what triggers resolution of the referenced dependency
too early in the lifecycle, and hence the error.

We are seeing this problem when trying to run 'mvn eclipse:eclipse'
because this only executes the generate-sources phase by default and we
have other mojos which genuinely do generate source, such as java2wsdl.

A workaround we're using is to run 'mvn process-classes eclipse:eclipse'.

Attached is a really simple project that exhibits this problem.

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. MANTRUN-78 Use of AntRun during clean phase fails multiproject with intermodule dependencies

  • Major - Major loss of function.
  • Reopened - This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved.

Bug - A problem which impairs or prevents the functions of the product. MJAVADOC-116 Impossible to aggregate javadoc if snapshot never built

  • Major - Major loss of function.
  • Reopened - This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved.

Bug - A problem which impairs or prevents the functions of the product. MENFORCER-42 Maven-Enforcer-Plugin fails in multimodule project when artifacts not in repository

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is duplicated by

Improvement - An improvement or enhancement to an existing feature or task. MECLIPSE-380 dependencies in multi-module may projects require a 'mvn install' before using

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is related to

Bug - A problem which impairs or prevents the functions of the product. MDEP-409 dependency:tree fails for a multi-module project where one module depends on another and "mvn install" not run yet

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Bug - A problem which impairs or prevents the functions of the product. MDEP-410 dependency:resolve fails for a multi-module project where one module depends on another and "mvn install" not run yet

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Bug - A problem which impairs or prevents the functions of the product. MNG-2277 aggregating plugins in submodules of the reactor return all projects causing a chicken/egg issue

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

New Feature - A new feature of the product, which has yet to be developed. MNG-4331 Add new mojo annotation @requiresDependencyCollection to grab dependency tree without files

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brian Fox added a comment - - edited

I think this is the same as MNG-2277, which is fixed in 2.0.8. I will post an RC build shortly and you can try it.

Show
Brian Fox added a comment - - edited I think this is the same as MNG-2277 , which is fixed in 2.0.8. I will post an RC build shortly and you can try it.
Hide
Permalink
Daniel Uribe added a comment -

Any new developments on this issue? It doesn't seem to be same issue as MNG-2277, and it is still not working on 2.0.8.

In the comments for that issue, Brian said that this is normal behavior. I would have to agree with Alfie that if a plugin is bound to a lower phase than the one specified in the @requiresDependencyResolution, it doesn't seem to make sense that it would try to resolve dependencies for a higher phase which hasn't even been executed.

Elaborating on top of the example outlined by Alfie, if the project having the dependency uses the antrun plugin for the generate-sources phase, it specifies a @requiresDependencyResolution of test, which is definitely higher than the generate-resources used by the eclipse plugin. Since running the eclipse plugin will only execute phases below generate-resources, it will never reach the stage of creating the package (jar, war, etc) for the project that it has a dependency for, hence failing.

Wouldn't it make sense to consider that when a plug-in is explicitly bound to a phase, to use that for dependency resolution?

Show
Daniel Uribe added a comment - Any new developments on this issue? It doesn't seem to be same issue as MNG-2277 , and it is still not working on 2.0.8. In the comments for that issue, Brian said that this is normal behavior. I would have to agree with Alfie that if a plugin is bound to a lower phase than the one specified in the @requiresDependencyResolution, it doesn't seem to make sense that it would try to resolve dependencies for a higher phase which hasn't even been executed. Elaborating on top of the example outlined by Alfie, if the project having the dependency uses the antrun plugin for the generate-sources phase, it specifies a @requiresDependencyResolution of test, which is definitely higher than the generate-resources used by the eclipse plugin. Since running the eclipse plugin will only execute phases below generate-resources, it will never reach the stage of creating the package (jar, war, etc) for the project that it has a dependency for, hence failing. Wouldn't it make sense to consider that when a plug-in is explicitly bound to a phase, to use that for dependency resolution?
Hide
Permalink
Alfie Kirkpatrick added a comment -

Note that am pretty sure this issue is seen in m2eclipse which uses maven embedder from the 2.1.x version of maven. This issue may become more apparent as people start using these tools and probably harder to roll out fixes also...

Show
Alfie Kirkpatrick added a comment - Note that am pretty sure this issue is seen in m2eclipse which uses maven embedder from the 2.1.x version of maven. This issue may become more apparent as people start using these tools and probably harder to roll out fixes also...
Hide
Permalink
Brian Fox added a comment -

This kind of change will require rework that can only occur in 2.1, if at all.

Show
Brian Fox added a comment - This kind of change will require rework that can only occur in 2.1, if at all.
Hide
Permalink
JQ added a comment -

We are experiencing this issue in relation to the enforcer plugin when trying to ensure that a reactor project is being built with JDK 1.4.x. We are unable to do a mvn release:prepare, and the suggested mvn process-classes _______ workaround doesn't seem to benefit us.

Our project is arranged as:

jdk14/
pom.xml (versions inside, compiler-plugin, enforcer-plugin)
module1/
module2/
module3/
...

Trying to release:prepare from jdk14/ with the enforcer enabled gives us the unfortunate...

[WARNING] The dependency: blahblahblah:jar:1.2 can't be resolved but has been found in the reactor.
This dependency has been excluded from the plugin execution. You should rerun this mojo after executing mvn install.

...messages, when all of the dependencies are there within the reactor.

Obviously this is a large issue for Eclipse users, but it also impacts other plugins and is a fairly serious problem in general. If it's not something that can be fixed through configuration or a change of phase, it needs to be addressed (in other words, 'if at all' is mildly scary terminology to us). Has there been any progress?

Show
JQ added a comment - We are experiencing this issue in relation to the enforcer plugin when trying to ensure that a reactor project is being built with JDK 1.4.x. We are unable to do a mvn release:prepare, and the suggested mvn process-classes _______ workaround doesn't seem to benefit us. Our project is arranged as: jdk14/ pom.xml (versions inside, compiler-plugin, enforcer-plugin) module1/ module2/ module3/ ... Trying to release:prepare from jdk14/ with the enforcer enabled gives us the unfortunate... [WARNING] The dependency: blahblahblah:jar:1.2 can't be resolved but has been found in the reactor. This dependency has been excluded from the plugin execution. You should rerun this mojo after executing mvn install. ...messages, when all of the dependencies are there within the reactor. Obviously this is a large issue for Eclipse users, but it also impacts other plugins and is a fairly serious problem in general. If it's not something that can be fixed through configuration or a change of phase, it needs to be addressed (in other words, 'if at all' is mildly scary terminology to us). Has there been any progress?
Hide
Permalink
Jason van Zyl added a comment -

Appears to be fixed, but not closed during the 2.0.8. Reopen if desired.

Show
Jason van Zyl added a comment - Appears to be fixed, but not closed during the 2.0.8. Reopen if desired.
Hide
Permalink
Alfie Kirkpatrick added a comment -

Am pretty sure this is not fixed. In fact it seems to be worse in 2.1.0.

I downloaded my repro project (attached) and ran 'mvn generate-sources' using mvn 2.1.0. This gives the error. Whereas before 'mvn process-classes' would succeed this fails now too, which makes this workaround no longer viable. The earliest phase that works is 'mvn package'...

Thanks, Alfie.

Show
Alfie Kirkpatrick added a comment - Am pretty sure this is not fixed. In fact it seems to be worse in 2.1.0. I downloaded my repro project (attached) and ran 'mvn generate-sources' using mvn 2.1.0. This gives the error. Whereas before 'mvn process-classes' would succeed this fails now too, which makes this workaround no longer viable. The earliest phase that works is 'mvn package'... Thanks, Alfie.
Hide
Permalink
Alfie Kirkpatrick added a comment -

Another comment... The only other workaround is to run 'mvn install' on your project. However, I have found working with teams that people can get in a real muddle when working with a mixture of 'dynamic' and local repository references. Therefore I try to encourage people to NEVER run mvn install on their project(s). This issue makes this nearly impossible.

Show
Alfie Kirkpatrick added a comment - Another comment... The only other workaround is to run 'mvn install' on your project. However, I have found working with teams that people can get in a real muddle when working with a mixture of 'dynamic' and local repository references. Therefore I try to encourage people to NEVER run mvn install on their project(s). This issue makes this nearly impossible.
Hide
Permalink
Jason van Zyl added a comment -

Can you try this with the 3.0-alpha-5? If it's broken we'll schedule for alpha-6 or alpha-7. Won't be fixed in 2.x.x. The reactor was pretty much rewritten in 3.x.

Show
Jason van Zyl added a comment - Can you try this with the 3.0-alpha-5? If it's broken we'll schedule for alpha-6 or alpha-7. Won't be fixed in 2.x.x. The reactor was pretty much rewritten in 3.x.
Hide
Permalink
Alfie Kirkpatrick added a comment -

Same result in alpha-5. Both generate-sources and process-classes fail but package works. Sorry.

Show
Alfie Kirkpatrick added a comment - Same result in alpha-5. Both generate-sources and process-classes fail but package works. Sorry.
Hide
Permalink
Arnaud Heritier added a comment -

Same issue with 3.0-alpha-6. I'll try to create a simple testcase but the issue is that maven, at the beginning of the build, downloads from my remote repo an update of each snapshot it will build.
My project is a multiproject which extends this pom : http://svn.exoplatform.org/projects/parent/tags/7/pom.xml (you'll see we are using the enforcer plugin)

Show
Arnaud Heritier added a comment - Same issue with 3.0-alpha-6. I'll try to create a simple testcase but the issue is that maven, at the beginning of the build, downloads from my remote repo an update of each snapshot it will build. My project is a multiproject which extends this pom : http://svn.exoplatform.org/projects/parent/tags/7/pom.xml (you'll see we are using the enforcer plugin)
Hide
Permalink
Benjamin Bentmann added a comment -

The constellation is just flawed: If a plugin has requiresDependencyResolution, i.e. asks for artifact files, and does so in phases like "validate", i.e. before even compilation occurs, how should Maven satisfies this requirement if not from the repo? The reactor is simply empty in terms of build output at this point of the build.

Plugins like the Enforcer which don't actually need the artifact files but only the dependency graph should be updated to use the new anno @requiresDependencyCollection (MNG-4331).

Show
Benjamin Bentmann added a comment - The constellation is just flawed: If a plugin has requiresDependencyResolution, i.e. asks for artifact files, and does so in phases like "validate", i.e. before even compilation occurs, how should Maven satisfies this requirement if not from the repo? The reactor is simply empty in terms of build output at this point of the build. Plugins like the Enforcer which don't actually need the artifact files but only the dependency graph should be updated to use the new anno @requiresDependencyCollection ( MNG-4331 ).
Hide
Permalink
Arnaud Heritier added a comment -

For artifacts in general, I agree, but shouldn't we have a special behavior for poms ?
In my case, I have a pom (reactor) and a module.
I cleanup my local repo to not have those artifacts.
At the beginning of the build maven downloads the snapshot of the module pom instead of using it in the module directory.
I tried to touch the module pom (in case of the nexus copy could be younger than my local copy) and I have the same result.
The new anno @requiresDependencyCollection will fix it, and i think it is the godd solution. But it will work only for maven 3. Thus as soon we'll use it our plugins will be compatible only with maven 3.

Show
Arnaud Heritier added a comment - For artifacts in general, I agree, but shouldn't we have a special behavior for poms ? In my case, I have a pom (reactor) and a module. I cleanup my local repo to not have those artifacts. At the beginning of the build maven downloads the snapshot of the module pom instead of using it in the module directory. I tried to touch the module pom (in case of the nexus copy could be younger than my local copy) and I have the same result. The new anno @requiresDependencyCollection will fix it, and i think it is the godd solution. But it will work only for maven 3. Thus as soon we'll use it our plugins will be compatible only with maven 3.
Hide
Permalink
Emmanuel Potvin added a comment -

Is there any news about this issue since january? I have this problem and I just try with Maven 3 and the @requiresDependencyCollection annotation and now instead of just crash I have warning telling me that some pom are missing and no dependency information is available. And effectively, the getArtifacts method returns me an empty collection.

What is wierd is that in my pom, I have dependencies on the other modules of my reactor and the version (in my case trunk-SNAPSHOT) is a property set inside the pom of the reactor, and it is resolved. So it is able to see my reactor's pom, but not use it to get pom inside other modules...

Show
Emmanuel Potvin added a comment - Is there any news about this issue since january? I have this problem and I just try with Maven 3 and the @requiresDependencyCollection annotation and now instead of just crash I have warning telling me that some pom are missing and no dependency information is available. And effectively, the getArtifacts method returns me an empty collection. What is wierd is that in my pom, I have dependencies on the other modules of my reactor and the version (in my case trunk-SNAPSHOT) is a property set inside the pom of the reactor, and it is resolved. So it is able to see my reactor's pom, but not use it to get pom inside other modules...
Hide
Permalink
Emmanuel Potvin added a comment -

I tried with 3.0.1 and it is still not fixed. Am I alone with this problem???

Show
Emmanuel Potvin added a comment - I tried with 3.0.1 and it is still not fixed. Am I alone with this problem???
Hide
Permalink
brundibar added a comment -

One year without progress?

Please this issue is MAJOR (if not BLOCKER), many people wait for it!

Thanks,
Regards

Show
brundibar added a comment - One year without progress? Please this issue is MAJOR (if not BLOCKER), many people wait for it! Thanks, Regards
Hide
Permalink
William Ashley added a comment - - edited

I also just ran into this issue using maven 3.0.3 with some projects I recently split into modules.

Edit: I am experiencing this with the javadoc, findbugs, and dependency plugins. Compilation, tests, packaging all work, in addition to the codehaus cobertura plugin.

Show
William Ashley added a comment - - edited I also just ran into this issue using maven 3.0.3 with some projects I recently split into modules. Edit: I am experiencing this with the javadoc, findbugs, and dependency plugins. Compilation, tests, packaging all work, in addition to the codehaus cobertura plugin.
Hide
Permalink
Carlo Sciolla added a comment -

@William Ashley same here

Show
Carlo Sciolla added a comment - @William Ashley same here
Hide
Permalink
Adrián Boimvaser added a comment -

Still no progress on this issue?

Show
Adrián Boimvaser added a comment - Still no progress on this issue?

People

  • Assignee:
    Unassigned
    Reporter:
    Alfie Kirkpatrick
Vote (27)
Watch (35)

Dates

  • Created:
    Updated: