Artifact instances in a reactor build

[Kristian Rosenvold <kr...@gmail.com>]

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 behaviour ? I suppose in
"linear" maven these instances are not concurrently in service, and it
may not matter too much. Since I feel they represent underlying
singletons, I'd like to make them so. Anyone have any good reason not
to ? (I was /thinking/ along the lines that there may be something
related to snapshot versions, but that's just a little over my head) 

(The reason I'm asking is that I find myself writing some fairly 
questionable code to transfer attributes from X1->X2)

Kristian



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Artifact instances in a reactor build

[Kristian Rosenvold <kr...@gmail.com>]

On Mon, Feb 15, 2010 at 6:14 AM, Igor Fedorenko <ig...@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
> pom.xml changes. So if one of mojos changes cached Artifact instance,
> next build may misbehave.
>

Nice tip; I checked the code and there seem to be no dependencies on the
mutable parts of
DefaultArtifact. If it were up to me I'd just make most of DefaultArtifact
final and immutable...

It seems like Brett is right; the "file/resolved" bit in DefaultArtifact
probably shouldn't have been
there, and when I think about it it's probably just used within a single
module build in linear maven. It seems
to me like the artifacts are re-resolved "properly" when proceeding to the
next module; this works
well with clear module boundaries ;)

ATM I solved this problem by re-resolving reactor artifacts when a module
transitions into
packaging, but I'll see if I can improve that once I find out why surefire
won't fire consistently ;)

Kristian

Re: Artifact instances in a reactor build

[Igor Fedorenko <ig...@ifedorenko.com>]

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 may misbehave.

--
Regards,
Igor

Kristian Rosenvold wrote:
> 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 behaviour ? I suppose in
> "linear" maven these instances are not concurrently in service, and it
> may not matter too much. Since I feel they represent underlying
> singletons, I'd like to make them so. Anyone have any good reason not
> to ? (I was /thinking/ along the lines that there may be something
> related to snapshot versions, but that's just a little over my head) 
> 
> (The reason I'm asking is that I find myself writing some fairly 
> questionable code to transfer attributes from X1->X2)
> 
> Kristian
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Artifact instances in a reactor build

[Brett Porter <br...@apache.org>]

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, Kristian Rosenvold wrote:

> 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 behaviour ? I suppose in
> "linear" maven these instances are not concurrently in service, and it
> may not matter too much. Since I feel they represent underlying
> singletons, I'd like to make them so. Anyone have any good reason not
> to ? (I was /thinking/ along the lines that there may be something
> related to snapshot versions, but that's just a little over my head) 
> 
> (The reason I'm asking is that I find myself writing some fairly 
> questionable code to transfer attributes from X1->X2)
> 
> Kristian
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Artifact instances in a reactor build

[Jason van Zyl <ja...@sonatype.com>]

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 cases that we purport to deal with assumes a graph structure in the end. For typical Java this makes sense because we're dealing a normal classloader structure where there is generally one per runtime, or at best one per application like a webapp. 

The one concrete use case that we have in Tycho right now is that because OSGi's classloaders are more sophisticated what we have there is resolution per project in a given reactor because given N bundles each may have a different of of artifact A with no adverse affects. And the transitive closure of A may be different in each case.

So I would do anything now that assumes the graph for a reactor, and eventually we'll figure out how to merge in the concepts from Tycho where we truly will have multiple graphs.

Some other things to note is that you should probably chat with Benjamin as there is a rework of the artifact resolution API on a branch that probably won't make it into 3.0 but I'd like your changes not to impede the absorption of those changes ultimately.

On Feb 13, 2010, at 3:34 PM, Kristian Rosenvold wrote:

> 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 behaviour ? I suppose in
> "linear" maven these instances are not concurrently in service, and it
> may not matter too much. Since I feel they represent underlying
> singletons, I'd like to make them so. Anyone have any good reason not
> to ? (I was /thinking/ along the lines that there may be something
> related to snapshot versions, but that's just a little over my head) 
> 
> (The reason I'm asking is that I find myself writing some fairly 
> questionable code to transfer attributes from X1->X2)
> 
> Kristian
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------