Our assumption thus far has been that for a given build, including within a
reactor, that the dependencies would boil down to a graph so by definition one
instance. I think what you're seeing is the transformation of the tree to a
graph and having leftovers. So for right now, for all the use
I can't see any reason they'd need to be separate, though my inclination would
be to move away from sharing that information via the 'file' property and
resolving it from the correct place when needed. I'm not up to date on how
trunk is handling these objects though.
On 14/02/2010, at 7:34 AM,
I am not 100% sure, but I think this may break MavenMetadataCache, which
caches Artifact instances and assumes they do not change. In m2e, for
example, we do not flash the cache before each build, only when project
pom.xml changes. So if one of mojos changes cached Artifact instance,
next build
On Mon, Feb 15, 2010 at 6:14 AM, Igor Fedorenko i...@ifedorenko.com wrote:
I am not 100% sure, but I think this may break MavenMetadataCache, which
caches Artifact instances and assumes they do not change. In m2e, for
example, we do not flash the cache before each build, only when project
It seems like an artifact with coordinates X has one separate instance
of DefaultArtifact in each project it appears. So project P0 has
instance X1 and P1 has instance X2. When the jar plugin in P0 calls
setFile on X1, X2 does not get updated.
Is there a well-defined business case for this
