Maven 2 & 3

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

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.

Somehow the problem has gone away!

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

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.

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).

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.

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

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?

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.

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.

Attached integration test to the issue - ready to commit.

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

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!

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 ?

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()))

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.

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

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.

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

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

Corrected one thing in Integration Test.

Integration test was committed by Jason van Zyl.

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

All integration tests pass.

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

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.

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.

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) ?

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

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.

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.

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.

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

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

Working on trunk.

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

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.