Brian E. Fox wrote:
Once multiple resolution strategies start appearing, life will be
infinitely more complicated.
yes :( I think Mercury has a pretty decent potential to cover majority
of the reasons to change version comparisons. For example - there is a
notion of version quality and repository only accepting a range of
qualities.
Version ranges also allow to configure quality behavior on the edges -
like: is 2.0-SNAPSHOT in the range [1.0,2.0) is configurable.
If you use a different strategy and I
consume your artifacts, I need to be able to interpret your strategy and
use it when calculating your part of the tree. (and someone else's etc).
That means the strategies need to be implemented and available in the
repository for mercury to use.
Also consider that version comparison affects behavior of dependency
resolver, and what has been tested for one set of rules, could easily
break under another rule-set. Which means - that we only hope that
everything works correctly, but not guarantee it does.
Overall - organizations start playing with these rules when they lack
other tools, and try to adopt their process to the limitations of tools
they have. I think we should leave version comparison alone, and instead
- concentrate on the tools.
For example - Nexus goes a long way here, allowing a lot of flexibility
in the usage, and thus removing the necessity to change those rules.
Using it immediately allows organization to tweak their process without
knocking build tooling off it's feet.
-----Original Message-----
From: Stephen Connolly [mailto:[email protected]]
Sent: Tuesday, February 10, 2009 3:32 AM
To: Maven Developers List
Subject: Version comparison rules
OK, here's a hairy old chestnut...
Maven has a set of version comparison rules... they don't work for
everyone... well life sucks
Mercury has a new set of version comparison rules... they're a lot
better, but probably don't work for everyone... life still sucks...
I've been thinking, the reality is that version comparison rules are
very much an organisation thing... so they really should be defined by
the organisation...
In versions-maven-plugin, I've added a third version comparator... it
won't work for everyone... life still sucks...
What I'm thinking is that if we had some metadata associated with the
groupId, it could specify what the version comparison rule is for that
groupId (and all it's child groupIds)...
OK, so I can do something similar in versions-maven-plugin to let
people define their rules for their groupIds, but this is something
that should really go into the repository... a
version-comparison-metadata.xml file...
we can start easy, by just defining the root rule as the current maven
rules...
The maven-deploy-plugin and nexus/artifactory could then use that rule
to update the latest and release tags in the metadata.xml files... ok,
so Maven 2.0.x could ignore the rules, or a small change could add
support...
What do people think...
We could even define the v-c-m.xml file to handle rule change-over, so
that we don't break existing builds...
e.g.
<rules>
<rule regex="..." priority="9999">maven</rule>
<rule regex="..." priority="1">mercury</rule>
</rules>
so that versions matching mercury's regex will have a high priority
and use mercury's rule within, while versions matching maven's regex
will always be older than those matching mercury's regex, but will be
compared with each other using maven's rules
-Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
