Hi,

I'm working on http://jira.codehaus.org/browse/MNG-1323. It's issue with
24 votes and many other issues depending on it. It's fully repeatable
(has attached maven-integration-test)
and there are some ways to fix it.

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.

Thanks,
Piotr Tabor

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to