Maven
  1. Maven
  2. MNG-1323

Plugin extensions (dependencies) not resolved in reactor build

    Details

      Description

      I've added a dependency on an Ant Task in project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ and run that anttask using the antrun plugin.

      When run from the project dir itself it runs fine.
      When running from the root of the project tree (reactor build, project one level below root),
      antrun bails out because the taskdef can't be found (not on classpath).

      It looks like the dependency isn't resolved, or not added to the plugins' classrealm.

      1. MNG-1323-components-2.0.x.diff
        55 kB
        Piotr Tabor
      2. MNG-1323-core-integration-testing.diff
        13 kB
        Piotr Tabor
      3. MNG-1323-core-integration-testing-2.diff
        14 kB
        Piotr Tabor
      4. MNG-1323-core-integration-tests.diff
        13 kB
        Piotr Tabor
      5. MNG-1323-core-integration-tests-3.diff
        34 kB
        Piotr Tabor
      6. MNG1323-maven-core-2.1.diff
        29 kB
        Piotr Tabor
      7. two-antruns.zip
        6 kB
        John Casey

        Issue Links

          Activity

          Hide
          Brett Porter added a comment -

          is this because they are not inherited, rather than anything to do with the reactor?

          Show
          Brett Porter added a comment - is this because they are not inherited, rather than anything to do with the reactor?
          Hide
          Kenney Westerhof added a comment -

          I don't think so - inheritance doesn't play a role. The parent-pom is just an empty pom stating 1 module -> the pom discussed above.
          I'll find the it for it and augment it for this issue.

          Show
          Kenney Westerhof added a comment - I don't think so - inheritance doesn't play a role. The parent-pom is just an empty pom stating 1 module -> the pom discussed above. I'll find the it for it and augment it for this issue.
          Hide
          Kenney Westerhof added a comment -

          Somehow the problem has gone away!

          Show
          Kenney Westerhof added a comment - Somehow the problem has gone away!
          Hide
          Brett Porter added a comment -

          did you test it with 2.0 or 2.0.1? Maybe this should be closed as cannot reproduce?

          Show
          Brett Porter added a comment - did you test it with 2.0 or 2.0.1? Maybe this should be closed as cannot reproduce?
          Hide
          Kenney Westerhof added a comment -

          The issue is a bit different - i got it reproducible now.

          It seems, in the following situation:

          root/pom.xml, modules: a, b
          a/pom.xml: define antrun, with any tasks (like <echo/>)
          b/pom.xml: define antrun, with <dependencies> section.

          When run from 'root', dependencies are not resolved for plugin antrun in project b.
          Probably because the plugin is already 'resolved' the different <dependencies> for
          this instance are not resolved.

          Show
          Kenney Westerhof added a comment - The issue is a bit different - i got it reproducible now. It seems, in the following situation: root/pom.xml, modules: a, b a/pom.xml: define antrun, with any tasks (like <echo/>) b/pom.xml: define antrun, with <dependencies> section. When run from 'root', dependencies are not resolved for plugin antrun in project b. Probably because the plugin is already 'resolved' the different <dependencies> for this instance are not resolved.
          Hide
          John Casey added a comment -

          It looks like some of the work I did to get the ant-mojo support up and running was related to this. Kenney's 04/Nov/2005 post was related to my fix for the ant-mojo stuff...

          I added code to search the project instance for a matching Plugin instance before I used the current Plugin instance to verify the plugin. This is key here, since the one constructed by the lifecycle executor may not have any of the project's plugin-dependencies in it.

          NOW, as for the latest incarnation of the problem, this is undoubtedly caused by Maven not disposing of plugin containers between project builds. If we did this, we would have the added benefit of cleaning out plugin-extensions (though we'd have to be very careful about this last, since it means cleaning up things like the ArtifactHandlerManager, too).

          Show
          John Casey added a comment - It looks like some of the work I did to get the ant-mojo support up and running was related to this. Kenney's 04/Nov/2005 post was related to my fix for the ant-mojo stuff... I added code to search the project instance for a matching Plugin instance before I used the current Plugin instance to verify the plugin. This is key here, since the one constructed by the lifecycle executor may not have any of the project's plugin-dependencies in it. NOW, as for the latest incarnation of the problem, this is undoubtedly caused by Maven not disposing of plugin containers between project builds. If we did this, we would have the added benefit of cleaning out plugin-extensions (though we'd have to be very careful about this last, since it means cleaning up things like the ArtifactHandlerManager, too).
          Hide
          Georges Polyzois added a comment -

          Is this beeing resolved? I have exactly this problem as Kenney stated on 04/Nov/05.
          I am using Maven 2.0.1 and even changed to using antrun version 1.1-SNAPSHOT - with no sucess.

          Show
          Georges Polyzois added a comment - Is this beeing resolved? I have exactly this problem as Kenney stated on 04/Nov/05. I am using Maven 2.0.1 and even changed to using antrun version 1.1-SNAPSHOT - with no sucess.
          Hide
          Brett Porter added a comment -

          note above that this is scheduled for 2.0.3 (Feb release).

          Show
          Brett Porter added a comment - note above that this is scheduled for 2.0.3 (Feb release).
          Hide
          ruel loehr added a comment -

          Are there any suggested work arounds for this issue? Hence, if I wish to use a custom ant task in a child module (which would require a dependency upon the antrun plugin), how would I accomplish it, or is it impossible at this time?

          Show
          ruel loehr added a comment - Are there any suggested work arounds for this issue? Hence, if I wish to use a custom ant task in a child module (which would require a dependency upon the antrun plugin), how would I accomplish it, or is it impossible at this time?
          Hide
          Brett Porter added a comment -

          workaround is to include the dependency in the first antrun plugin instance encountered. one way to guarantee would be to include this in the root project.

          Show
          Brett Porter added a comment - workaround is to include the dependency in the first antrun plugin instance encountered. one way to guarantee would be to include this in the root project.
          Hide
          Kenney Westerhof added a comment -

          Hm.. this problem is really annoying and there is no workaround. Now I even get a weirder error:

          java.lang.NoSuchMethodError: java_cup.runtime.lr_parser.parse()V
          at org.jacorb.idl.JacIDL.execute(JacIDL.java:356)
          at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)

          The org.jacorb.idl stuff AND the java_cup.runtime are both in the same jar file! This might be a bug
          in Jacorb, but when run from the projects themselves, everything goes OK.
          It doesn't matter if I specify the dependencies in a dependencyManagement in the root pom,
          or in the project's declaring the plugin themselves.

          I even tried the idlj-maven-plugin in mojo's sandbox. It's used twice in the entire reactor tree.
          The plugin itself does not define the jacorb dependency, so I had to define it. I tried <build><extensions>,
          root pom's pluginManagement, and both pom's. Since this is the exact same plugin with the exact same
          deps and configuration, it should work. Unfortunately it doesn't.

          Now, about a solution.

          M2 currently disposes the PlexusRealm for the plugin after each execution. However,
          the classloader is set to the mojoDescriptor.getPluginDescriptor().getClassRealm().getClassLoader().
          This classloader/classRealm is NOT disposed of. I'm not sure why the PlexusRealm isn't equal to the
          pluginDescriptor's classRealm. There should be one access point to manage a plugin's execution environment.

          If this were fixed, John Casey's comment above about the ArtifactHandlerManager comes into play.

          A suggestion: We could leave the plugin's declared dependencies in the same classloader as the plugin's artifact.
          We could add a NEW classloader containing the project's <dependencies> for that plugin, and hook that into
          the plugin's classloader as a child. After execution, we unhook it (perhaps a child PlexusRealm?)

          I would really like to get this fixed in 2.0.5. My previous workaround (specifying the filename of the dependency
          in an ant script's TaskDef tag) doesn't work anymore since 2.0.4.

          Show
          Kenney Westerhof added a comment - Hm.. this problem is really annoying and there is no workaround. Now I even get a weirder error: java.lang.NoSuchMethodError: java_cup.runtime.lr_parser.parse()V at org.jacorb.idl.JacIDL.execute(JacIDL.java:356) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) The org.jacorb.idl stuff AND the java_cup.runtime are both in the same jar file! This might be a bug in Jacorb, but when run from the projects themselves, everything goes OK. It doesn't matter if I specify the dependencies in a dependencyManagement in the root pom, or in the project's declaring the plugin themselves. I even tried the idlj-maven-plugin in mojo's sandbox. It's used twice in the entire reactor tree. The plugin itself does not define the jacorb dependency, so I had to define it. I tried <build><extensions>, root pom's pluginManagement, and both pom's. Since this is the exact same plugin with the exact same deps and configuration, it should work. Unfortunately it doesn't. Now, about a solution. M2 currently disposes the PlexusRealm for the plugin after each execution. However, the classloader is set to the mojoDescriptor.getPluginDescriptor().getClassRealm().getClassLoader(). This classloader/classRealm is NOT disposed of. I'm not sure why the PlexusRealm isn't equal to the pluginDescriptor's classRealm. There should be one access point to manage a plugin's execution environment. If this were fixed, John Casey's comment above about the ArtifactHandlerManager comes into play. A suggestion: We could leave the plugin's declared dependencies in the same classloader as the plugin's artifact. We could add a NEW classloader containing the project's <dependencies> for that plugin, and hook that into the plugin's classloader as a child. After execution, we unhook it (perhaps a child PlexusRealm?) I would really like to get this fixed in 2.0.5. My previous workaround (specifying the filename of the dependency in an ant script's TaskDef tag) doesn't work anymore since 2.0.4.
          Hide
          Piotr Tabor added a comment -

          Attached integration test to the issue - ready to commit.

          The test fails if run from parent directory and works
          if run from children directories.

          Show
          Piotr Tabor added a comment - Attached integration test to the issue - ready to commit. The test fails if run from parent directory and works if run from children directories.
          Hide
          Brian Topping added a comment -

          John's comment in http://jira.codehaus.org/browse/MNG-1323#action_50268 is correct, that "this is undoubtedly caused by Maven not disposing of plugin containers between project builds". DefaultPluginManager.ensurePluginContainerIsComplete() specifically skips plugin instantiation on the first line if it's already been initialized.

          This is a huge problem in a build that I am working on. Using a setup like:

          root/pom.xml, modules: a, b
          a/pom.xml: define antrun, with antrun target that generates an ant Task
          b/pom.xml: define antrun, with <dependencies> section that includes the task built with a

          There's no way to use the Task built in a if the container that built a is not disposed and reloaded with the new dependencies of b (which includes a).

          This whole thing of using antrun is suboptimal, but it needs to be supported. The project that I'm currently porting uses XDoclet 1 very heavily, along with a forked version of Castor and some Texen tasks for a forked version of Torque. The only way to reliably bring this across is to clean it up after things are stabilized, with 60+ projects at last count, there's just too much risk to try to create plugins before the build is operational.

          JOHN: have you tried to solve this before and run into problems? This issue is coming up on two years old and has over 20 watchers. I'd like to help, but from previous experience, I'd like to get as much information as I can about what the solution is up against. It's an obvious performance violation to blindly dispose the container with every execution (there should probably be some kind of dependency signature comparison before disposing the container), but since this happens per-build rather than within a build, the impact should be minimal.

          Discuss!

          Show
          Brian Topping added a comment - John's comment in http://jira.codehaus.org/browse/MNG-1323#action_50268 is correct, that "this is undoubtedly caused by Maven not disposing of plugin containers between project builds". DefaultPluginManager.ensurePluginContainerIsComplete() specifically skips plugin instantiation on the first line if it's already been initialized. This is a huge problem in a build that I am working on. Using a setup like: root/pom.xml, modules: a, b a/pom.xml: define antrun, with antrun target that generates an ant Task b/pom.xml: define antrun, with <dependencies> section that includes the task built with a There's no way to use the Task built in a if the container that built a is not disposed and reloaded with the new dependencies of b (which includes a). This whole thing of using antrun is suboptimal, but it needs to be supported. The project that I'm currently porting uses XDoclet 1 very heavily, along with a forked version of Castor and some Texen tasks for a forked version of Torque. The only way to reliably bring this across is to clean it up after things are stabilized, with 60+ projects at last count, there's just too much risk to try to create plugins before the build is operational. JOHN: have you tried to solve this before and run into problems? This issue is coming up on two years old and has over 20 watchers. I'd like to help, but from previous experience, I'd like to get as much information as I can about what the solution is up against. It's an obvious performance violation to blindly dispose the container with every execution (there should probably be some kind of dependency signature comparison before disposing the container), but since this happens per-build rather than within a build, the impact should be minimal. Discuss!
          Hide
          Piotr Tabor added a comment - - edited

          I am trying to work on the issue too.

          The simplest solution is in DefaultPluginManager change the code to:

          private PluginDescriptor verifyVersionedPlugin( Plugin plugin,
          MavenProject project,
          ArtifactRepository localRepository )

          File pluginFile = pluginArtifact.getFile();

          • if /( !pluginCollector.isPluginInstalled( plugin ) ||/ ( pluginContainer == null ) * { addPlugin( plugin, pluginArtifact, project, localRepository ); }
          • else /*if ( pluginFile.lastModified() > pluginContainer.getCreationDate().getTime() )/ * * { getLogger().info( "Reloading plugin container for: " + plugin.getKey() + ". The plugin artifact has changed." ); pluginContainer.dispose(); pluginCollector.flushPluginDescriptor( plugin ); addPlugin( plugin, pluginArtifact, project, localRepository ); }

          But it slows Maven to much... I will trying to prepare know a little bit better solution that checks if getted descriptor matches and if
          not - to replace it.

          The best solution is to build plugin's identifiers that contains hashcode of dependencies.

          Any comments from Commiters ?

          Show
          Piotr Tabor added a comment - - edited I am trying to work on the issue too. The simplest solution is in DefaultPluginManager change the code to: private PluginDescriptor verifyVersionedPlugin( Plugin plugin, MavenProject project, ArtifactRepository localRepository ) File pluginFile = pluginArtifact.getFile(); if / ( !pluginCollector.isPluginInstalled( plugin ) || / ( pluginContainer == null ) * { addPlugin( plugin, pluginArtifact, project, localRepository ); } else /*if ( pluginFile.lastModified() > pluginContainer.getCreationDate().getTime() )/ * * { getLogger().info( "Reloading plugin container for: " + plugin.getKey() + ". The plugin artifact has changed." ); pluginContainer.dispose(); pluginCollector.flushPluginDescriptor( plugin ); addPlugin( plugin, pluginArtifact, project, localRepository ); } But it slows Maven to much... I will trying to prepare know a little bit better solution that checks if getted descriptor matches and if not - to replace it. The best solution is to build plugin's identifiers that contains hashcode of dependencies. Any comments from Commiters ?
          Hide
          Piotr Tabor added a comment -

          Sent to dev@maven.apache.org:

          Business (user's) problem:

          The problem is that maven only once resolve dependencies for every plugin's KEY (plugin's groupId:artifactId) - not for
          every mavan USAGE. But the pom's <plugin><dependencies></dependencies></plugin> tag allows for specifying plugin's dependencies per
          every USAGE. In current maven's version (2.0.8-SNAPSHOT, 2.1-SNAPSHOT) the all plugin's USAGES are using the same dependencies as the first USAGE.
          It is especially annoying with maven-antrun-plugin (that is often used with diffrent "tags" dependencies).

          Implementation situation:

          Facts:

          • PluginDescriptors class constain's resolved plugin's dependencies
          • MavenPluginCollector constains cache - map (pluginKey (groupId:artifactId) into PluginDescriptors)
          • DefaultPluginManager.verifyVersionedPlugin (is responsible for transferring Plugin object into PluginDescriptor)
            uses MavenPluginCollector to check if the right entry exists.

          There are possible such a fixes:

          1) The worst: Remove caching (every plugin's environment (including) child plexusContainer has to be recalculated for each maven usage) - simplest to implement (and working patch is in JIRA comments))

          2) Better: Check after getting PluginDescriptor from MavenPluginCollector:
          if(comutativeEquals(!pluginCollector.getPluginDescriptor(plugin).getIntroducedDependencyArtifacts(), plugin.getDependencies()))

          { recalculateTheEntry(); }

          adventages: simple to implement (change in single place)

          disadventages: If there are two (or more) usage of the same plugin (interlaced) the one will be cashed and the other will be recalculated
          with each use.
          3 ) to change the plugin identificator for this cashing from: groupId:artifactId to groupId:artifactId:comutativeHashCode(getDependencies())

          adventages: the best for performance
          disadventages:
          a) many changes in many places
          b) I am a little bit afraid about resolving plugin's transitive dependencies (they seems to be resolved "lazily", so the dependencies list so the cache key too)...
          (but I'm sure it is to be worked out)

          Am I right? Please comment... At least to motivate me to work on this issue further.

          Show
          Piotr Tabor added a comment - Sent to dev@maven.apache.org: Business (user's) problem: The problem is that maven only once resolve dependencies for every plugin's KEY (plugin's groupId:artifactId) - not for every mavan USAGE. But the pom's <plugin><dependencies></dependencies></plugin> tag allows for specifying plugin's dependencies per every USAGE. In current maven's version (2.0.8-SNAPSHOT, 2.1-SNAPSHOT) the all plugin's USAGES are using the same dependencies as the first USAGE. It is especially annoying with maven-antrun-plugin (that is often used with diffrent "tags" dependencies). Implementation situation: Facts: PluginDescriptors class constain's resolved plugin's dependencies MavenPluginCollector constains cache - map (pluginKey (groupId:artifactId) into PluginDescriptors) DefaultPluginManager.verifyVersionedPlugin (is responsible for transferring Plugin object into PluginDescriptor) uses MavenPluginCollector to check if the right entry exists. There are possible such a fixes: 1) The worst: Remove caching (every plugin's environment (including) child plexusContainer has to be recalculated for each maven usage) - simplest to implement (and working patch is in JIRA comments)) 2) Better: Check after getting PluginDescriptor from MavenPluginCollector: if(comutativeEquals(!pluginCollector.getPluginDescriptor(plugin).getIntroducedDependencyArtifacts(), plugin.getDependencies())) { recalculateTheEntry(); } adventages: simple to implement (change in single place) disadventages: If there are two (or more) usage of the same plugin (interlaced) the one will be cashed and the other will be recalculated with each use. 3 ) to change the plugin identificator for this cashing from: groupId:artifactId to groupId:artifactId:comutativeHashCode(getDependencies()) adventages: the best for performance disadventages: a) many changes in many places b) I am a little bit afraid about resolving plugin's transitive dependencies (they seems to be resolved "lazily", so the dependencies list so the cache key too)... (but I'm sure it is to be worked out) Am I right? Please comment... At least to motivate me to work on this issue further.
          Hide
          mtkopone added a comment -

          Sounds to me like plugin dependencies should be execution-specific?

          Show
          mtkopone added a comment - Sounds to me like plugin dependencies should be execution-specific?
          Hide
          mtkopone added a comment -

          Ugliest workaround yet:
          Since we are mostly running into this when using the maven-antrun-plugin, I redeployed the version we are using into our company-wide maven repo with a different groupId/artifactId, and am now issueing such groupIds/artifactIds to developers that require differing dependencies in their antruns. When this bug gets fixed, I'll relocate all those plugins back to the real version.

          Show
          mtkopone added a comment - Ugliest workaround yet: Since we are mostly running into this when using the maven-antrun-plugin, I redeployed the version we are using into our company-wide maven repo with a different groupId/artifactId, and am now issueing such groupIds/artifactIds to developers that require differing dependencies in their antruns. When this bug gets fixed, I'll relocate all those plugins back to the real version.
          Hide
          Piotr Tabor added a comment -

          Patch for this issue for 2.0.x.
          All it's passed.

          Show
          Piotr Tabor added a comment - Patch for this issue for 2.0.x. All it's passed.
          Hide
          Piotr Tabor added a comment -

          It test for this issue. Actualized to current tests numeration (127)

          Show
          Piotr Tabor added a comment - It test for this issue. Actualized to current tests numeration (127)
          Hide
          Piotr Tabor added a comment - - edited

          Corrected one thing in Integration Test.

          Show
          Piotr Tabor added a comment - - edited Corrected one thing in Integration Test.
          Hide
          Piotr Tabor added a comment -

          Integration test was committed by Jason van Zyl.

          Show
          Piotr Tabor added a comment - Integration test was committed by Jason van Zyl.
          Hide
          Piotr Tabor added a comment -

          Patch for trunk (2.1) - (rev. 575973.)

          All integration tests pass.

          Show
          Piotr Tabor added a comment - Patch for trunk (2.1) - (rev. 575973.) All integration tests pass.
          Hide
          Piotr Tabor added a comment -

          Patch for trunk(2.1) was commited by Jason van Zyl.

          Patch for 2.0.x is waiting to be commited (http://jira.codehaus.org/secure/attachment/29268/MNG-1323-components-2.0.x.diff).

          I hope the issue is likely to be marked as : Fix version: 2.1-alpha-1, 2.0.8

          Show
          Piotr Tabor added a comment - Patch for trunk(2.1) was commited by Jason van Zyl. Patch for 2.0.x is waiting to be commited ( http://jira.codehaus.org/secure/attachment/29268/MNG-1323-components-2.0.x.diff ). I hope the issue is likely to be marked as : Fix version: 2.1-alpha-1, 2.0.8
          Hide
          Piotr Tabor added a comment - - edited

          MNG-1323-core-integration-tests-3.diff

          IT0127 rewritten to not use Ant run plugin - as Jason wished.
          It uses enforcer plugin instead (with new rule) to check if right dependencies
          are available from the plugin.

          Show
          Piotr Tabor added a comment - - edited MNG-1323 -core-integration-tests-3.diff IT0127 rewritten to not use Ant run plugin - as Jason wished. It uses enforcer plugin instead (with new rule) to check if right dependencies are available from the plugin.
          Hide
          Jason van Zyl added a comment -

          I have reverted this change:

          svn merge -r575987:575986 https://svn.apache.org/repos/asf/maven/components/trunk .

          As it was breaking trunk horribly. My theory is that I had everything locally required to make it work. Piotr, you'll have to look at you get a PluginDescriptor not found error for tons of plugins which isn't right.

          Show
          Jason van Zyl added a comment - I have reverted this change: svn merge -r575987:575986 https://svn.apache.org/repos/asf/maven/components/trunk . As it was breaking trunk horribly. My theory is that I had everything locally required to make it work. Piotr, you'll have to look at you get a PluginDescriptor not found error for tons of plugins which isn't right.
          Hide
          Piotr Tabor added a comment -

          I wasn't able to repeat Jason's problems. I asked the dev group for help with repeating the issue and got no answer.
          Is any commiter able to promise that he will help me with checking/commiting this patch if I refactor it to work with
          current revisions (2.1 and 2.0.x) ?

          Show
          Piotr Tabor added a comment - I wasn't able to repeat Jason's problems. I asked the dev group for help with repeating the issue and got no answer. Is any commiter able to promise that he will help me with checking/commiting this patch if I refactor it to work with current revisions (2.1 and 2.0.x) ?
          Hide
          Brian E. Fox added a comment -

          Piotr, yes, I've scheduled it for 2.0.10 so we will be looking at it soon.

          Show
          Brian E. Fox added a comment - Piotr, yes, I've scheduled it for 2.0.10 so we will be looking at it soon.
          Hide
          John Casey added a comment -

          To run, use `mvn initialize`

          The second project uses the telnet task, but since the first project is executed first by default from the modules ordering, the telnet task hasn't been loaded.

          Show
          John Casey added a comment - To run, use `mvn initialize` The second project uses the telnet task, but since the first project is executed first by default from the modules ordering, the telnet task hasn't been loaded.
          Hide
          John Casey added a comment -

          This, along with different plugin versions used in different POMs within a single multimodule build, is something I addressed for trunk (2.1). To make it work, I had to setup a realm manager to track plugins using a key that's based on groupId:artifactId:version, PLUS a hash of the dependency-id's it uses. This allows naming of the plugin realm accordingly, and helps to retrieve the correct realm for use when a plugin is executed.

          The problem is, it requires use of the new lookupRealm(..) functionality of later plexus-container-default releases (> ~1.0-alpha-16, IIRC), and upgrading Maven 2.0.x to a compatible plexus version may well break other things.

          It may be that this issue cannot be resolved in a satisfactory manner until 2.1 is released. The good news is, it should work in the first alpha of 2.1.

          Show
          John Casey added a comment - This, along with different plugin versions used in different POMs within a single multimodule build, is something I addressed for trunk (2.1). To make it work, I had to setup a realm manager to track plugins using a key that's based on groupId:artifactId:version, PLUS a hash of the dependency-id's it uses. This allows naming of the plugin realm accordingly, and helps to retrieve the correct realm for use when a plugin is executed. The problem is, it requires use of the new lookupRealm(..) functionality of later plexus-container-default releases (> ~1.0-alpha-16, IIRC), and upgrading Maven 2.0.x to a compatible plexus version may well break other things. It may be that this issue cannot be resolved in a satisfactory manner until 2.1 is released. The good news is, it should work in the first alpha of 2.1.
          Hide
          John Casey added a comment -

          I'm moving this off to 2.1-alpha-1, since that's the closest release we can reasonably expect a solution at present. Fixing this in 2.0.x will require some very large changes that will certainly have rippling effects on other features.

          Show
          John Casey added a comment - I'm moving this off to 2.1-alpha-1, since that's the closest release we can reasonably expect a solution at present. Fixing this in 2.0.x will require some very large changes that will certainly have rippling effects on other features.
          Hide
          Benjamin Bentmann added a comment -

          IT shows this working on 3.x trunk, leaving issue open in case we want to backport to 2.1.

          Show
          Benjamin Bentmann added a comment - IT shows this working on 3.x trunk, leaving issue open in case we want to backport to 2.1.
          Hide
          Jason van Zyl added a comment -

          I think we'll honestly be out with 3.0-alpha-1 before 2.1-alpha-1 so I'm going to close this.

          Show
          Jason van Zyl added a comment - I think we'll honestly be out with 3.0-alpha-1 before 2.1-alpha-1 so I'm going to close this.
          Hide
          Jason van Zyl added a comment -

          Working on trunk.

          Show
          Jason van Zyl added a comment - Working on trunk.
          Hide
          marcin dzierzak added a comment -

          Hi, any chance to have it fixed in 2.2.x stream ?

          Show
          marcin dzierzak added a comment - Hi, any chance to have it fixed in 2.2.x stream ?
          Hide
          Hannes Schmidt added a comment -

          Can this please be backported to 2.2.x. I've been using Maven since 2005 and this thing has been bugging me once every so often with enough time in between for my brain to garbage collect my awareness of this bug. So I basically spend a few hours every year hunting plugin dependency problems with reactor builds and ultimately land on this page.

          BTW, my workaround is to collect all plugin dependencies in the pluginManagement section of a parent pom that's common to all modules.

          Show
          Hannes Schmidt added a comment - Can this please be backported to 2.2.x. I've been using Maven since 2005 and this thing has been bugging me once every so often with enough time in between for my brain to garbage collect my awareness of this bug. So I basically spend a few hours every year hunting plugin dependency problems with reactor builds and ultimately land on this page. BTW, my workaround is to collect all plugin dependencies in the pluginManagement section of a parent pom that's common to all modules.

            People

            • Assignee:
              Unassigned
              Reporter:
              Kenney Westerhof
            • Votes:
              60 Vote for this issue
              Watchers:
              37 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development