On 10-Feb-09, at 8:37 AM, Stephen Connolly wrote:
Which is why I think that the rules need to be defined at the
repository, and per groupId
That's just a nightmare. What's wrong with just settling on something
that works for everyone. I really and truly can't honestly see how the
OSGi versioning scheme can't work for folks.
Every organization and their uncle will come with some reason why
their BigCo must have 5 digits and 2 qualifiers. It's just fodder for
disaster. The interoperability issues like when someone takes an
existing project in open source and renames it to their scheme, then
you have two repositories that have the similar artifacts with
different versioning schemes and I just don't think it's worth it.
Then people start having to make bridges between these different
systems.
Why don't we just use a scheme that has been around for years and
seems to be accommodating and working for organizations like Eclipse?
They have spend a lot of time thinking about and do we really want to
get into a debate about why 4 digits are better then 3, or why we
should sort qualifiers this way or that?
My opinion is that we gravitate toward the OSGi version scheme and be
done with it. We could make the scheme pluggable but I would basically
say if you want to deviate you can support the additional tooling
required to deal with it.
2009/2/10 Brian E. Fox <[email protected]>:
Once multiple resolution strategies start appearing, life will be
infinitely more complicated. 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.
-----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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
We all have problems. How we deal with them is a measure of our worth.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
