You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2009/02/10 09:32:11 UTC
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version comparison rules
Posted by Christian Schulte <cs...@schulte.it>.
Christian Schulte schrieb:
> Stephen Connolly schrieb:
>> 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)...
>
> It would be very cool to have some general purpose grouplevel metadata!
> Various things come to mind. Public keys, extensible general purpose
> grouplevel indexing, group relocation, group depraction, access control
> etc. Lots of usecases. So when modeling, lots of requirements to
> collect. Could be as complex as the pom itself, could be as simple as
>
> <group>
> <file id="well-known-identifier"
> mime-type="text/xml"
> url="version-comparison-metadata.xml"/>
>
> <file id="well-known-identifier"
> mime-type="application/x-x509-ca-cert"
> url="ca.crt"/>
>
> <file id="well-known-identifier"
> mime-type="image/jpeg"
> url="logo.jpg"/>
>
> ...
> </group>
>
> With URLs relative to the groupid location or even absolute pointing to
> some resource outside the repository, but publicly accessible, or not.
>
There currently is no possibility for something like
'artifactGroup.getArtifacts()', is there ?
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version comparison rules
Posted by Christian Schulte <cs...@schulte.it>.
Stephen Connolly schrieb:
> 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)...
It would be very cool to have some general purpose grouplevel metadata!
Various things come to mind. Public keys, extensible general purpose
grouplevel indexing, group relocation, group depraction, access control
etc. Lots of usecases. So when modeling, lots of requirements to
collect. Could be as complex as the pom itself, could be as simple as
<group>
<file id="well-known-identifier"
mime-type="text/xml"
url="version-comparison-metadata.xml"/>
<file id="well-known-identifier"
mime-type="application/x-x509-ca-cert"
url="ca.crt"/>
<file id="well-known-identifier"
mime-type="image/jpeg"
url="logo.jpg"/>
...
</group>
With URLs relative to the groupid location or even absolute pointing to
some resource outside the repository, but publicly accessible, or not.
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version comparison rules
Posted by Oleg Gusakov <ol...@gmail.com>.
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:stephen.alan.connolly@gmail.com]
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version comparison rules
Posted by Stephen Connolly <st...@gmail.com>.
Sent from my [rhymes with myPod] ;-)
On 10 Feb 2009, at 19:05, Jason van Zyl <jv...@sonatype.com> wrote:
> On 10-Feb-09, at 1:06 PM, Stephen Connolly wrote:
>
>> 2009/2/10 Jason van Zyl <jv...@sonatype.com>:
>>>
>>> On 10-Feb-09, at 11:33 AM, Stephen Connolly wrote:
>>>
>>>> 2009/2/10 Jason van Zyl <jv...@sonatype.com>:
>>>>>
>>>>> 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.
>>>>
>>>> Because 5 digits can actually be a good thing....
>>>>
>>>> Yes, I would love to have something other than
>>>>
>>>> [Major].[Minor].[Service pack].[patch].[build]
>>>>
>>>
>>> I'm honestly not concerned with what one person wants and really
>>> more
>>> concerned what will work for thousands of users.
>>>
>>>> But given that we've had several builds of patches to a specific
>>>> service pack, it's a nightmare to get that information into 4
>>>> digits.... and yes, I know windows uses only 4 digits... but come
>>>> on.
>>>> If Maven is going to force 4 digits down our necks that's a bad
>>>> thing.
>>>>
>>>
>>> I don't think. Pretty much everyone looking at many aspects in Maven
>>> immediately say "that's not going to work for us" and then though
>>> some
>>> process people find it's adequate.
>>>
>>
>> Yet the big plus of Maven is supposed to be version ranges, and when
>> you are living in a land where corporate bosses have decreed 5 digits
>> *must* be used and no rational arguments will convince them
>> otherwise...
>
> Otherwise what? You go down the path of explaining it's not
> supported and that you can implement it yourself. Explain the costs
> associated with that and see if your boss likes it. Nothing is free.
> Us supporting it here would be marginal at best because we can't
> know what everyone is going to do is just not supportable from a
> project perspective. I am certain we can find something that works
> for 90% of the user base. For the rest of the 10% of the cases that
> are so far out there those groups are responsible for supporting them.
>
> Version ranges have never worked well so we're basically going to
> get to decide what happens and I don't think anyone is going to
> argue about taking in input. But I would really be loathe at this
> point to do something different then OSGi versioning. This doesn't
> imply terminally tying to OSGi, it's just their version scheme.
>
>>
>>
>> What I'm saying is, fine, if maven works best with 4 digits, that's
>> cool. But the current situation where a major feature just plain is
>> broken with anything other than ###.###.###-### is not the way maven
>> should work
>>
>> Mercury's current version comparison rule will handle infinite
>> depth... there are some tweaks about whether a . or a - comes first
>> or
>> is ignored and that's where i'd have some concerns... 1.2.3 vs 1.2-3
>> vs 1.2 vs 1.2.2 vs 1.2.3.1 vs 1.2.3-1 vs 1.2.4 vs 1.2-4
>>
>> in general, mercury will handle the case I have to live with, so
>> please leave that alone ;-)
>>
>
> What Mercury can handle and what will happen in Maven are two
> separate things. Mercury was designed to do everything and they were
> designed to be completely decoupled.
>
>>>> Personally, mercury's infinite number of versions is nice.... I
>>>> think
>>>> it should work for everyone, but I am not so arrogant as to assume
>>>> that it will.
>>>
>>> It's not arrogance. It's knowing in practice that when you try to
>>> get N
>>> groups using M different schemes/processes that it quickly becomes
>>> an
>>> untenable situation pretty quickly. It's a matter of supporting a
>>> large
>>> group of people well. Just look at people and the problems they
>>> have just
>>> working within a specification like J2EE or OSGi and how many
>>> problems they
>>> have. To think that we could support interoperability between
>>> whatever
>>> people want to arbitrarily define is frankly living in dream land.
>>>
>>
>> Then you need to define a version number policy for central... as
>> without one and a cleanup of central, you too are living in dream
>> land
>
> Then you can see how having many would be that many more times
> untenable.
>
> Getting N projects in the world in line will take at least a year,
> and it will not happen until we have Nexus managing everything.
> Right now central just gets contributed to and it's a convenience to
> the Maven community to populate their own. We know first hand what's
> sitting in there. It's grown organically and I think that's fine as
> it shows what people want and what people do.
>
>>
>>
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> If it's defined at the repository level per groupId, you just leave
>>>> that up to the repository manager... if you have a private repo
>>>> with
>>>> differing rules, fine, if you use those rules in somebody else's
>>>> groupId, your build will be f*cked, and it's your problem.
>>>
>>> Sorry, but that just doesn't work. People don't blame their messed
>>> up setup
>>> they always, invariably blame the tools. And in this particular
>>> case I see
>>> no advantage in not settling on a version scheme that has worked
>>> for the
>>> last 5 years.
>>>
>>
>> it has not worked with some of the crazy version numbers in central
>>
>>>>
>>>>
>>>>> 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.
>>>>
>>>> As long as the version comparison works for those people who must
>>>> use
>>>> more than 4 digits, I'm fine if Maven moves to 4 digits in general.
>>>> But *stop* assuming that, just because 4 digits is your latest
>>>> flavour
>>>> of the month, 4 digits is best
>>>
>>> Using OSGi versioning is hardly the flavor of the month. It's also
>>> not using
>>> OSGi it's just using a versioning scheme that has worked for a lot
>>> of people
>>> for a long time.
>>>
>>> The pattern that works for us is that we pick something and settle
>>> on it and
>>> that's what we use. We cannot put in place something that is
>>> infinitely
>>> flexible because that fact of the matter is we end up supporting
>>> it. All the
>>> questions from all the groups all doing totally different things
>>> falls on
>>> us. It's very easy to say "well, you screw it up that's your
>>> problem" but
>>> that's not what happens in practice. We will get groups who will
>>> religiously
>>> fight about some version scheme and I just want to stay out of it.
>>> I would
>>> opt for picking something has worked and we go with that.
>>
>> except that you are changing the version number rules from maven to
>> osgi...
>>
>
> They are a superset. Or close enough to a superset that it's not
> going to cause that many problems. There are a few things like "1.0"
> having totally different behavior but the version scheme and the
> behavior we can separate for the time being.
>
>> and there is not a 1:1 mapping from maven to osgi that will preserve
>> version ranges and it's crazy edge cases
>>
>
> Our stuff I would say doesn't work well enough to preserve. And
> aside from some "." to "_" conversions it's not really that bad.
> Maven 2.x will always support what's there and that's not going to
> change.
>
>> you'll get 95% of the cases, and we're left with enough of a gap to
>> be a pain
>
> I doubt it. It won't be any worse then what we have now.
>
>>
>>
>> and osgi is a flavour precisely because it is different from the
>> previous rule, and you're now changing the rules
>
> The set notation is almost the same, the rules are slightly
> different yes but I think our model is sufficiently broken that we
> take one that works. We have no real specification to speak of so
> it's really not that much of an advantage sticking to what we have
> because no one can ready anything about it.
>
>>
>>
>>>
>>> What is always open to you, and really what I think works best, is
>>> that you
>>> take the source code and wedge in whatever you want. Make your own
>>> version
>>> schemes, implement whatever you like because now you are truly
>>> responsible
>>> for it and it is your problem. All these organizations and
>>> individuals
>>> expect us to maintain all this stuff but when the onus falls on
>>> them they
>>> really find out how truly painful it is. Then they really think
>>> about
>>> whether it's really worth it or not. It forces them to help work on
>>> something that works for everyone.
>>>
>>
>> it must be great working for your own company and only getting pulled
>> in to others as the "mr fix it" where you can force 3 digit version
>> schemes on the company
>>
>> ;-)
>>
>> (sorry what was that, you're now forcing 4 digit schemes?)
>>
>>> So Stephen you are truly free to implement whatever you like. You
>>> can build
>>> your own version of Maven using your super flexible version
>>> mechanism and if
>>> you get adopters that's great. It's just not a long term,
>>> community wide
>>> supportable path to take. If you don't want to work within the
>>> confines of
>>> what we setup guess what? You don't have to use it.
>>
>> That is true, but I am not free to implement whatever I like.
>>
>> I have to bend over and take 5 digit version numbers... I personally
>> would prefer three digits, but valid arguments have been made and
>> that
>> war is over, or at least not one I can fight.
>>
>
> Tell them it's going to cost them 40k/year in maintenance costs
> doing something completely differently.
>
>> Add on top that we have customers taking our APIs and if they want to
>> use Maven to build them, then they too face th 5 digit madness... and
>> yes I made these arguments, and did I win? Guess? go on really give
>> it
>> a guess?
>
> Then keep adding to that number. It's going to cost you real money.
>
>>
>>
>> Maven is a great build tool, version ranges are a seriously important
>> feature of maven, and we cannot use them because version ranges only
>> work for three digit version numbers...
>
> Then you expose your own hooks to Mercury and do your own 5 digit
> thing. Or you figure out how to do three digits and use the
> qualifier to do whatever else you want.
>>
>>
>> So now you have decided that OSGi is great, let's make OSGi work...
>> well that's great, just when you're making OSGi work, don't add stuff
>> in that breaks the rest of us mear mortals who are stuck with 5 or 6
>> digit version madness
>
> I don't think we would change the way it is now, if the version
> doesn't parse you string comparisons. But I think you could probably
> do something with qualifiers.
our versions are always numbers and 5 sets of them separated by only .
the most important thing is that build 6 < build 16
osgi will map the first 4 of them fine... but if qualifiers are
compared as strings we really need to know that we will only have less
than 99 builds or we run into issues. last release we had 162 builds,
previous took only 25
>
>
>>
>>
>> And don't get me started on the fools who's version number is the
>> date
>> they made the release... and then changed to real version numbers...
>> so that 20030607 should be less than 1.0!!!
>
>
>>
>>>
>>>>
>>>>
>>>>>
>>>>>> 2009/2/10 Brian E. Fox <br...@reply.infinity.nu>:
>>>>>>>
>>>>>>> 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:stephen.alan.connolly@gmail.com]
>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ---
>>>>>>> ---
>>>>>>> ---------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---
>>>>>> ---
>>>>>> ---------------------------------------------------------------
>>>>>> 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
>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---
>>>> ------------------------------------------------------------------
>>>> 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
>>> jason at sonatype dot com
>>> ----------------------------------------------------------
>>>
>>> believe nothing, no matter where you read it,
>>> or who has said it,
>>> not even if i have said it,
>>> unless it agrees with your own reason
>>> and your own common sense.
>>>
>>> -- Buddha
>>>
>>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
> jason at sonatype dot com
> ----------------------------------------------------------
>
> A language that doesn’t affect the way you think about programming i
> s not worth knowing.
>
> -— Alan Perlis
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version comparison rules
Posted by Jason van Zyl <jv...@sonatype.com>.
On 10-Feb-09, at 1:06 PM, Stephen Connolly wrote:
> 2009/2/10 Jason van Zyl <jv...@sonatype.com>:
>>
>> On 10-Feb-09, at 11:33 AM, Stephen Connolly wrote:
>>
>>> 2009/2/10 Jason van Zyl <jv...@sonatype.com>:
>>>>
>>>> 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.
>>>
>>> Because 5 digits can actually be a good thing....
>>>
>>> Yes, I would love to have something other than
>>>
>>> [Major].[Minor].[Service pack].[patch].[build]
>>>
>>
>> I'm honestly not concerned with what one person wants and really more
>> concerned what will work for thousands of users.
>>
>>> But given that we've had several builds of patches to a specific
>>> service pack, it's a nightmare to get that information into 4
>>> digits.... and yes, I know windows uses only 4 digits... but come
>>> on.
>>> If Maven is going to force 4 digits down our necks that's a bad
>>> thing.
>>>
>>
>> I don't think. Pretty much everyone looking at many aspects in Maven
>> immediately say "that's not going to work for us" and then though
>> some
>> process people find it's adequate.
>>
>
> Yet the big plus of Maven is supposed to be version ranges, and when
> you are living in a land where corporate bosses have decreed 5 digits
> *must* be used and no rational arguments will convince them
> otherwise...
Otherwise what? You go down the path of explaining it's not supported
and that you can implement it yourself. Explain the costs associated
with that and see if your boss likes it. Nothing is free. Us
supporting it here would be marginal at best because we can't know
what everyone is going to do is just not supportable from a project
perspective. I am certain we can find something that works for 90% of
the user base. For the rest of the 10% of the cases that are so far
out there those groups are responsible for supporting them.
Version ranges have never worked well so we're basically going to get
to decide what happens and I don't think anyone is going to argue
about taking in input. But I would really be loathe at this point to
do something different then OSGi versioning. This doesn't imply
terminally tying to OSGi, it's just their version scheme.
>
>
> What I'm saying is, fine, if maven works best with 4 digits, that's
> cool. But the current situation where a major feature just plain is
> broken with anything other than ###.###.###-### is not the way maven
> should work
>
> Mercury's current version comparison rule will handle infinite
> depth... there are some tweaks about whether a . or a - comes first or
> is ignored and that's where i'd have some concerns... 1.2.3 vs 1.2-3
> vs 1.2 vs 1.2.2 vs 1.2.3.1 vs 1.2.3-1 vs 1.2.4 vs 1.2-4
>
> in general, mercury will handle the case I have to live with, so
> please leave that alone ;-)
>
What Mercury can handle and what will happen in Maven are two separate
things. Mercury was designed to do everything and they were designed
to be completely decoupled.
>>> Personally, mercury's infinite number of versions is nice.... I
>>> think
>>> it should work for everyone, but I am not so arrogant as to assume
>>> that it will.
>>
>> It's not arrogance. It's knowing in practice that when you try to
>> get N
>> groups using M different schemes/processes that it quickly becomes an
>> untenable situation pretty quickly. It's a matter of supporting a
>> large
>> group of people well. Just look at people and the problems they
>> have just
>> working within a specification like J2EE or OSGi and how many
>> problems they
>> have. To think that we could support interoperability between
>> whatever
>> people want to arbitrarily define is frankly living in dream land.
>>
>
> Then you need to define a version number policy for central... as
> without one and a cleanup of central, you too are living in dream land
Then you can see how having many would be that many more times
untenable.
Getting N projects in the world in line will take at least a year, and
it will not happen until we have Nexus managing everything. Right now
central just gets contributed to and it's a convenience to the Maven
community to populate their own. We know first hand what's sitting in
there. It's grown organically and I think that's fine as it shows what
people want and what people do.
>
>
>>>
>>>
>>>> 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.
>>>>
>>>
>>> If it's defined at the repository level per groupId, you just leave
>>> that up to the repository manager... if you have a private repo with
>>> differing rules, fine, if you use those rules in somebody else's
>>> groupId, your build will be f*cked, and it's your problem.
>>
>> Sorry, but that just doesn't work. People don't blame their messed
>> up setup
>> they always, invariably blame the tools. And in this particular
>> case I see
>> no advantage in not settling on a version scheme that has worked
>> for the
>> last 5 years.
>>
>
> it has not worked with some of the crazy version numbers in central
>
>>>
>>>
>>>> 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.
>>>
>>> As long as the version comparison works for those people who must
>>> use
>>> more than 4 digits, I'm fine if Maven moves to 4 digits in general.
>>> But *stop* assuming that, just because 4 digits is your latest
>>> flavour
>>> of the month, 4 digits is best
>>
>> Using OSGi versioning is hardly the flavor of the month. It's also
>> not using
>> OSGi it's just using a versioning scheme that has worked for a lot
>> of people
>> for a long time.
>>
>> The pattern that works for us is that we pick something and settle
>> on it and
>> that's what we use. We cannot put in place something that is
>> infinitely
>> flexible because that fact of the matter is we end up supporting
>> it. All the
>> questions from all the groups all doing totally different things
>> falls on
>> us. It's very easy to say "well, you screw it up that's your
>> problem" but
>> that's not what happens in practice. We will get groups who will
>> religiously
>> fight about some version scheme and I just want to stay out of it.
>> I would
>> opt for picking something has worked and we go with that.
>
> except that you are changing the version number rules from maven to
> osgi...
>
They are a superset. Or close enough to a superset that it's not going
to cause that many problems. There are a few things like "1.0" having
totally different behavior but the version scheme and the behavior we
can separate for the time being.
> and there is not a 1:1 mapping from maven to osgi that will preserve
> version ranges and it's crazy edge cases
>
Our stuff I would say doesn't work well enough to preserve. And aside
from some "." to "_" conversions it's not really that bad. Maven 2.x
will always support what's there and that's not going to change.
> you'll get 95% of the cases, and we're left with enough of a gap to
> be a pain
I doubt it. It won't be any worse then what we have now.
>
>
> and osgi is a flavour precisely because it is different from the
> previous rule, and you're now changing the rules
The set notation is almost the same, the rules are slightly different
yes but I think our model is sufficiently broken that we take one that
works. We have no real specification to speak of so it's really not
that much of an advantage sticking to what we have because no one can
ready anything about it.
>
>
>>
>> What is always open to you, and really what I think works best, is
>> that you
>> take the source code and wedge in whatever you want. Make your own
>> version
>> schemes, implement whatever you like because now you are truly
>> responsible
>> for it and it is your problem. All these organizations and
>> individuals
>> expect us to maintain all this stuff but when the onus falls on
>> them they
>> really find out how truly painful it is. Then they really think about
>> whether it's really worth it or not. It forces them to help work on
>> something that works for everyone.
>>
>
> it must be great working for your own company and only getting pulled
> in to others as the "mr fix it" where you can force 3 digit version
> schemes on the company
>
> ;-)
>
> (sorry what was that, you're now forcing 4 digit schemes?)
>
>> So Stephen you are truly free to implement whatever you like. You
>> can build
>> your own version of Maven using your super flexible version
>> mechanism and if
>> you get adopters that's great. It's just not a long term, community
>> wide
>> supportable path to take. If you don't want to work within the
>> confines of
>> what we setup guess what? You don't have to use it.
>
> That is true, but I am not free to implement whatever I like.
>
> I have to bend over and take 5 digit version numbers... I personally
> would prefer three digits, but valid arguments have been made and that
> war is over, or at least not one I can fight.
>
Tell them it's going to cost them 40k/year in maintenance costs doing
something completely differently.
> Add on top that we have customers taking our APIs and if they want to
> use Maven to build them, then they too face th 5 digit madness... and
> yes I made these arguments, and did I win? Guess? go on really give it
> a guess?
Then keep adding to that number. It's going to cost you real money.
>
>
> Maven is a great build tool, version ranges are a seriously important
> feature of maven, and we cannot use them because version ranges only
> work for three digit version numbers...
Then you expose your own hooks to Mercury and do your own 5 digit
thing. Or you figure out how to do three digits and use the qualifier
to do whatever else you want.
>
>
> So now you have decided that OSGi is great, let's make OSGi work...
> well that's great, just when you're making OSGi work, don't add stuff
> in that breaks the rest of us mear mortals who are stuck with 5 or 6
> digit version madness
I don't think we would change the way it is now, if the version
doesn't parse you string comparisons. But I think you could probably
do something with qualifiers.
>
>
> And don't get me started on the fools who's version number is the date
> they made the release... and then changed to real version numbers...
> so that 20030607 should be less than 1.0!!!
>
>>
>>>
>>>
>>>>
>>>>> 2009/2/10 Brian E. Fox <br...@reply.infinity.nu>:
>>>>>>
>>>>>> 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:stephen.alan.connolly@gmail.com]
>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>> believe nothing, no matter where you read it,
>> or who has said it,
>> not even if i have said it,
>> unless it agrees with your own reason
>> and your own common sense.
>>
>> -- Buddha
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> 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
jason at sonatype dot com
----------------------------------------------------------
A language that doesn’t affect the way you think about programming is
not worth knowing.
-— Alan Perlis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version comparison rules
Posted by Stephen Connolly <st...@gmail.com>.
2009/2/10 Jason van Zyl <jv...@sonatype.com>:
>
> On 10-Feb-09, at 11:33 AM, Stephen Connolly wrote:
>
>> 2009/2/10 Jason van Zyl <jv...@sonatype.com>:
>>>
>>> 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.
>>
>> Because 5 digits can actually be a good thing....
>>
>> Yes, I would love to have something other than
>>
>> [Major].[Minor].[Service pack].[patch].[build]
>>
>
> I'm honestly not concerned with what one person wants and really more
> concerned what will work for thousands of users.
>
>> But given that we've had several builds of patches to a specific
>> service pack, it's a nightmare to get that information into 4
>> digits.... and yes, I know windows uses only 4 digits... but come on.
>> If Maven is going to force 4 digits down our necks that's a bad thing.
>>
>
> I don't think. Pretty much everyone looking at many aspects in Maven
> immediately say "that's not going to work for us" and then though some
> process people find it's adequate.
>
Yet the big plus of Maven is supposed to be version ranges, and when
you are living in a land where corporate bosses have decreed 5 digits
*must* be used and no rational arguments will convince them
otherwise...
What I'm saying is, fine, if maven works best with 4 digits, that's
cool. But the current situation where a major feature just plain is
broken with anything other than ###.###.###-### is not the way maven
should work
Mercury's current version comparison rule will handle infinite
depth... there are some tweaks about whether a . or a - comes first or
is ignored and that's where i'd have some concerns... 1.2.3 vs 1.2-3
vs 1.2 vs 1.2.2 vs 1.2.3.1 vs 1.2.3-1 vs 1.2.4 vs 1.2-4
in general, mercury will handle the case I have to live with, so
please leave that alone ;-)
>> Personally, mercury's infinite number of versions is nice.... I think
>> it should work for everyone, but I am not so arrogant as to assume
>> that it will.
>
> It's not arrogance. It's knowing in practice that when you try to get N
> groups using M different schemes/processes that it quickly becomes an
> untenable situation pretty quickly. It's a matter of supporting a large
> group of people well. Just look at people and the problems they have just
> working within a specification like J2EE or OSGi and how many problems they
> have. To think that we could support interoperability between whatever
> people want to arbitrarily define is frankly living in dream land.
>
Then you need to define a version number policy for central... as
without one and a cleanup of central, you too are living in dream land
>>
>>
>>> 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.
>>>
>>
>> If it's defined at the repository level per groupId, you just leave
>> that up to the repository manager... if you have a private repo with
>> differing rules, fine, if you use those rules in somebody else's
>> groupId, your build will be f*cked, and it's your problem.
>
> Sorry, but that just doesn't work. People don't blame their messed up setup
> they always, invariably blame the tools. And in this particular case I see
> no advantage in not settling on a version scheme that has worked for the
> last 5 years.
>
it has not worked with some of the crazy version numbers in central
>>
>>
>>> 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.
>>
>> As long as the version comparison works for those people who must use
>> more than 4 digits, I'm fine if Maven moves to 4 digits in general.
>> But *stop* assuming that, just because 4 digits is your latest flavour
>> of the month, 4 digits is best
>
> Using OSGi versioning is hardly the flavor of the month. It's also not using
> OSGi it's just using a versioning scheme that has worked for a lot of people
> for a long time.
>
> The pattern that works for us is that we pick something and settle on it and
> that's what we use. We cannot put in place something that is infinitely
> flexible because that fact of the matter is we end up supporting it. All the
> questions from all the groups all doing totally different things falls on
> us. It's very easy to say "well, you screw it up that's your problem" but
> that's not what happens in practice. We will get groups who will religiously
> fight about some version scheme and I just want to stay out of it. I would
> opt for picking something has worked and we go with that.
except that you are changing the version number rules from maven to osgi...
and there is not a 1:1 mapping from maven to osgi that will preserve
version ranges and it's crazy edge cases
you'll get 95% of the cases, and we're left with enough of a gap to be a pain
and osgi is a flavour precisely because it is different from the
previous rule, and you're now changing the rules
>
> What is always open to you, and really what I think works best, is that you
> take the source code and wedge in whatever you want. Make your own version
> schemes, implement whatever you like because now you are truly responsible
> for it and it is your problem. All these organizations and individuals
> expect us to maintain all this stuff but when the onus falls on them they
> really find out how truly painful it is. Then they really think about
> whether it's really worth it or not. It forces them to help work on
> something that works for everyone.
>
it must be great working for your own company and only getting pulled
in to others as the "mr fix it" where you can force 3 digit version
schemes on the company
;-)
(sorry what was that, you're now forcing 4 digit schemes?)
> So Stephen you are truly free to implement whatever you like. You can build
> your own version of Maven using your super flexible version mechanism and if
> you get adopters that's great. It's just not a long term, community wide
> supportable path to take. If you don't want to work within the confines of
> what we setup guess what? You don't have to use it.
That is true, but I am not free to implement whatever I like.
I have to bend over and take 5 digit version numbers... I personally
would prefer three digits, but valid arguments have been made and that
war is over, or at least not one I can fight.
Add on top that we have customers taking our APIs and if they want to
use Maven to build them, then they too face th 5 digit madness... and
yes I made these arguments, and did I win? Guess? go on really give it
a guess?
Maven is a great build tool, version ranges are a seriously important
feature of maven, and we cannot use them because version ranges only
work for three digit version numbers...
So now you have decided that OSGi is great, let's make OSGi work...
well that's great, just when you're making OSGi work, don't add stuff
in that breaks the rest of us mear mortals who are stuck with 5 or 6
digit version madness
And don't get me started on the fools who's version number is the date
they made the release... and then changed to real version numbers...
so that 20030607 should be less than 1.0!!!
>
>>
>>
>>>
>>>> 2009/2/10 Brian E. Fox <br...@reply.infinity.nu>:
>>>>>
>>>>> 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:stephen.alan.connolly@gmail.com]
>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
> jason at sonatype dot com
> ----------------------------------------------------------
>
> believe nothing, no matter where you read it,
> or who has said it,
> not even if i have said it,
> unless it agrees with your own reason
> and your own common sense.
>
> -- Buddha
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version comparison rules
Posted by Jason van Zyl <jv...@sonatype.com>.
On 10-Feb-09, at 11:33 AM, Stephen Connolly wrote:
> 2009/2/10 Jason van Zyl <jv...@sonatype.com>:
>> 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.
>
> Because 5 digits can actually be a good thing....
>
> Yes, I would love to have something other than
>
> [Major].[Minor].[Service pack].[patch].[build]
>
I'm honestly not concerned with what one person wants and really more
concerned what will work for thousands of users.
> But given that we've had several builds of patches to a specific
> service pack, it's a nightmare to get that information into 4
> digits.... and yes, I know windows uses only 4 digits... but come on.
> If Maven is going to force 4 digits down our necks that's a bad thing.
>
I don't think. Pretty much everyone looking at many aspects in Maven
immediately say "that's not going to work for us" and then though some
process people find it's adequate.
> Personally, mercury's infinite number of versions is nice.... I think
> it should work for everyone, but I am not so arrogant as to assume
> that it will.
It's not arrogance. It's knowing in practice that when you try to get
N groups using M different schemes/processes that it quickly becomes
an untenable situation pretty quickly. It's a matter of supporting a
large group of people well. Just look at people and the problems they
have just working within a specification like J2EE or OSGi and how
many problems they have. To think that we could support
interoperability between whatever people want to arbitrarily define is
frankly living in dream land.
>
>
>> 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.
>>
>
> If it's defined at the repository level per groupId, you just leave
> that up to the repository manager... if you have a private repo with
> differing rules, fine, if you use those rules in somebody else's
> groupId, your build will be f*cked, and it's your problem.
Sorry, but that just doesn't work. People don't blame their messed up
setup they always, invariably blame the tools. And in this particular
case I see no advantage in not settling on a version scheme that has
worked for the last 5 years.
>
>
>> 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.
>
> As long as the version comparison works for those people who must use
> more than 4 digits, I'm fine if Maven moves to 4 digits in general.
> But *stop* assuming that, just because 4 digits is your latest flavour
> of the month, 4 digits is best
Using OSGi versioning is hardly the flavor of the month. It's also not
using OSGi it's just using a versioning scheme that has worked for a
lot of people for a long time.
The pattern that works for us is that we pick something and settle on
it and that's what we use. We cannot put in place something that is
infinitely flexible because that fact of the matter is we end up
supporting it. All the questions from all the groups all doing totally
different things falls on us. It's very easy to say "well, you screw
it up that's your problem" but that's not what happens in practice. We
will get groups who will religiously fight about some version scheme
and I just want to stay out of it. I would opt for picking something
has worked and we go with that.
What is always open to you, and really what I think works best, is
that you take the source code and wedge in whatever you want. Make
your own version schemes, implement whatever you like because now you
are truly responsible for it and it is your problem. All these
organizations and individuals expect us to maintain all this stuff but
when the onus falls on them they really find out how truly painful it
is. Then they really think about whether it's really worth it or not.
It forces them to help work on something that works for everyone.
So Stephen you are truly free to implement whatever you like. You can
build your own version of Maven using your super flexible version
mechanism and if you get adopters that's great. It's just not a long
term, community wide supportable path to take. If you don't want to
work within the confines of what we setup guess what? You don't have
to use it.
>
>
>>
>>> 2009/2/10 Brian E. Fox <br...@reply.infinity.nu>:
>>>>
>>>> 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:stephen.alan.connolly@gmail.com]
>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> 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
jason at sonatype dot com
----------------------------------------------------------
believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.
-- Buddha
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version comparison rules
Posted by Stephen Connolly <st...@gmail.com>.
2009/2/10 Jason van Zyl <jv...@sonatype.com>:
> 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.
Because 5 digits can actually be a good thing....
Yes, I would love to have something other than
[Major].[Minor].[Service pack].[patch].[build]
But given that we've had several builds of patches to a specific
service pack, it's a nightmare to get that information into 4
digits.... and yes, I know windows uses only 4 digits... but come on.
If Maven is going to force 4 digits down our necks that's a bad thing.
Personally, mercury's infinite number of versions is nice.... I think
it should work for everyone, but I am not so arrogant as to assume
that it will.
> 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.
>
If it's defined at the repository level per groupId, you just leave
that up to the repository manager... if you have a private repo with
differing rules, fine, if you use those rules in somebody else's
groupId, your build will be f*cked, and it's your problem.
> 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.
As long as the version comparison works for those people who must use
more than 4 digits, I'm fine if Maven moves to 4 digits in general.
But *stop* assuming that, just because 4 digits is your latest flavour
of the month, 4 digits is best
>
>> 2009/2/10 Brian E. Fox <br...@reply.infinity.nu>:
>>>
>>> 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:stephen.alan.connolly@gmail.com]
>>> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version comparison rules
Posted by Jason van Zyl <jv...@sonatype.com>.
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 <br...@reply.infinity.nu>:
>> 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:stephen.alan.connolly@gmail.com]
>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> 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
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version comparison rules
Posted by Stephen Connolly <st...@gmail.com>.
Which is why I think that the rules need to be defined at the
repository, and per groupId
2009/2/10 Brian E. Fox <br...@reply.infinity.nu>:
> 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:stephen.alan.connolly@gmail.com]
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Version comparison rules
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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:stephen.alan.connolly@gmail.com]
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org