maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Gusakov <>
Subject Re: Virtual versions
Date Tue, 17 Mar 2009 23:23:45 GMT
� wrote:
> Timothy Reilly wrote:
>> Hi Oleg,
>> I just worked with a company converting 130+ projects from Ant to Maven.
>> LATEST and RELEASE were invaluable.
>> I do think there needs to be more thought around when they're allowed. No
>> artifact's "release" pom should contain SNAPSHOT, LATEST or RELEASE
>> anywhere. The later 2 should be extrapolated during the release build. 
QA and Production releases are completely different from dev builds. If 
QA or Prod build contains any virtual version, the company owning them 
is not in a good shape. Timestamps are OK in this regard.
>> But
>> otherwise they're really important to me during development. Why wouldn't
>> I want to point to parent pom version = RELEASE in my development poms?
Reasonable for dev, but see below - remark about attribute-based resolution
>>  Or
>> use the LATEST plugin until it breaks something in a non backward
>> compatible way? 
How do you know what breaks - an incompatible plugin or your unit test? 
This is even bigger question if you use virtual versions for expressing 
regular dependencies, not just plugins.
>> Re-creating past releases and dependency trees it's a
>> different story though.
>> It's a lot to ask a build and deploy team to update 130+ projects whenever
>> they release a new enterprise pom. What they'll do in practice is just
>> change it and force it over the current version or worse avoid making
>> changes that really should be done b/c it's too much hassle.
This is what I mean by "lack of version manipulation tools". Virtual 
versions is a poor man's replacement for tools required for a good 
process. It's very hard to create the right tool, especially to address 
the wild range of possible workflows.
> Therefore we always set the enterprise POM to SNAPSHOT (which manages not only 
> 3rd party deps in the depMgmt, but also the versions of our own artifacts). 
> If somebody changes a project, he will have to set the project's parent also 
> to SNAPSHOT (= inherit the latest enterprise POM) and set the version of the 
> project's artifact in the enterprise POM to <version>-SNAPSHOT. This means, 
> if somebody (i.e. another artifact) depends on the changes, the parent of 
> this artifact must be set simply to SNAPSHOT (and its version in the 
> enterprise POM also). That way you get also a good idea about what you have 
> to release. The only caveat is, that everyone must update, build and install 
> the enterprise POM regularily on his own. But that's fine for us.
> - J�rg
If we look at overall picture, the greatest benefits come from using 
virtual versions for the parent POM. To me it clearly indicates that we 
are using wrong mechanism for this kind of dependency. I don't propose 
"the right" solution right away, but we can think about it. Ralph did 
something in this area, but that solution did not cover all kinds of 
builds, if I remember correctly.

I think that solution lies in the area of attribute-based conflict 
resolution - I started exploring that in regards to Mercury resolver.

> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message