My comments are inline, and I've added another idea to the bottom.
Please, read on! :)
Thanks,
--john
On Jul 12, 2007, at 9:46 PM, Piotr Tabor wrote:
* medium_real_project: (153,151,150,151 seconds) - YES - THREE
TIME LONGER - I am also in shock
So I am sure - we cannot just comment cache.
Okay, so that's pretty hard evidence...simply avoiding caching is not
an option.
I there are still 3 possibilities:
a) (new one) Cache only plugins without additional (from user's
project pom.xml) dependencies. Most of plugins (and the most often
called) are without additional "dependencies".
This only works if you can distinguish a plugin+dependencies key from
a plugin (no deps) key. If you have already cached a plugin because
it didn't have dependencies, then another module tries to use that
plugin _with_ some dependencies, there could still be a problem of
retrieving the incorrect plugin configuration, if there is no
difference between plugin+deps keys and plugins-by-themselves keys...
b) Check each received answer from cache if dependencies matches
(and if not) change the cached entry.
This will depend on having a concrete idea of a dependency's
identity, right? ...which leads me to think that we'll either have to
derive a set of id strings using something like
ArtifactUtils.versionlessKey(..), or switch to a newer version of
modello that allows the specification of identity fields in a class
(Maven's model doesn't include this yet, I don't think, because it
wasn't supported by modello at the time). Then, we could use
Set.removeAll(..) to subtract the new plugin's dep set from the old
one's, I guess...though that still requires resolving the plugin's
pom each time, right, so we can determine what its deps are?
c) Enlarge plugin's id for cache (by adding dependencies's
hashcode) ...
this involves creating a hashing algorithm for dependencies, and
mashing it all up into some unique plugin id, right? I guess we'd
just have to make sure the algorithm's execution doesn't impose too
much of a performance penalty...it also would require resolving the
plugin's pom over and over again, for the same reason as #2 above,
right?
(John Casey: The amount of plugins is generally
"constant" and
low (15) - so I don't see the "memory" problem).
My concern was having too many instances of a given plugin existing
in the cache side-by-side with one another, in the case of #3 above.
Imagine, antrun (no deps), antrun+ant-optional, antrun+something-from-
sourceforge, antrun+my-custom-dep, etc.
Another option would be to establish the notion of a stronger per-
project session that would contain cached instances of plugins and
extensions. When the project is completed, the session is garbage-
collected. There could be a little more overhead when all projects
use the same plugin configurations, but since projects are built
serially inside a reactor, the impact should be fairly small, I would
think. This approach has two other big attractions for me:
1. it allows the use of different plugin _versions_ in different
projects within the reactor
2. it gives a common method for dealing with these same problems in
the realm of build extensions (esp. relating to differing versions)
Since many projects use a single, unadorned plugin version, I'm not
sure what the added overhead might be here...it could make even more
sense to allow project sessions to inherit from one another, along
the same lines as POMs. This way, plugin versions (which probably
should have been inherited through POM inheritance) are available
from the parent session...
Ideally, I'd like to keep an eye on MNG-1024 and MNG-1949 as we work
on solving this. Does any of this make sense?
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
