While #3 might have the best performance in terms of speed, I really
wonder about memory performance. Leaving all those old antrun plugin
instances laying around but still reachable means that in very large
projects that use antrun, we'll have some pretty significant memory
problems. If you determine that the plugin+dependencies doesn't fit
the current requirement, then what's the point in keeping it around?
Maybe I'm missing a key point here, but I'd say do a check, and if
the current plugin doesn't handle the required set of dependencies
(exactly, not minimally), then scrap it and start over. In fact, it
might be cleanest to always start over, to get away from preserved
state in plugins between mojo invocations...just an idea there, but
preserved state within a plugin could be a problem that happens
sometimes and not others, if we go to the model of reloading (or
loading new) plugin containers...
-john
On Jul 12, 2007, at 1:43 AM, Piotr Tabor wrote:
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]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
