Hi Paul,
I think this thread is very close to this one:
http://www.nabble.com/How-to-use-central-repo-into-an-Eclipse-project--td16676423s177.html
Cheers,
Vincent
2008/4/15, Paul Gier <[EMAIL PROTECTED]>:
> Hi everyone,
>
> I'd like to make a small change to the artifact version parsing. We
>
g of one type of non-standard format. But I
> >>> understand your concern, that's why I brought it up for
> >>> discussion ;)
> >>>
> >>> Brian E. Fox wrote:
> >>>> These kinds of changes in the 2.0.x branch concern me. There'
On Fri, 18 Apr 2008 04:11:19 Christian Edward Gruber wrote:
> Having said that, a simpler option would be to have - or . parsed as
> equivalent punctuation tokens, and have numerical ordering if it's
> convertable to a number or lexical ordering if not, on each item
> between the punctuations. so:
I know that maven2 is convention over anything else... a more general but
consistent versioning scheme will help people transition, and help maven
packages artifacts stay consistent with upstream sources.
You could even have the release plugin map the version to the maven2 way with
beta, alpha,
With two caveats...
1)
A leading zero turns a number into a string (not a zero by itself)
2)
How to you apply the -! rule that I use all the time which stops a match
against -SNAPSHOT e.g. [2,3-!) will not match 3-SNAPSHOT.
Perhaps say ! means !"" and which means so that it can only match the
If we were to split the version string into components on - and . and _ and
also split on transitions from number to letters then use the ordering rules
at each component as defined here...
Examples of version to components split
1.0 ==> 1, 0
1.0-beta1 ==> 1, 0, beta, 1
1-SNAPSHOT ==> 1, SNAPSHO
t doesn't change the parsing of the standard maven version
> > > > string, I think the risk is pretty low. I see it as basically better
> > > > handling of one type of non-standard format. But I understand your
> > > > concern,
> > > > that&#
-
From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday,
April 17, 2008 5:23 AM
To: Maven Developers List
Subject: Re: Change to artifact version handling.
I haven't yet applied it, but at first thought it seems a
reasonable change.
- Brett
On 16/04/2008, at 6:37 AM, Paul Gier wrote:
Hi ev
There's no way to
predict what impact this will have out there.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, April
17, 2008 5:23 AM
To: Maven Developers List
Subject: Re: Change to artifact version handling.
I haven't yet applied it, but at firs
n ;)
Brian E. Fox wrote:
These kinds of changes in the 2.0.x branch concern me. There's no
way to
predict what impact this will have out there.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, April
17, 2008 5:23 AM
To: Maven Developers List
S
al Message-
From: Paul Gier [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 11:12 AM
To: Maven Developers List
Subject: Re: Change to artifact version handling.
Yes, this would be ideal for me too :)
How difficult would it be to allow the version parsing to be loaded as a
build
extens
AM
To: Maven Developers List
Subject: Re: Change to artifact version handling.
Yes, this would be ideal for me too :)
How difficult would it be to allow the version parsing to be loaded as a
build
extension? That seems like the best solution.
Could this be implemented in 2.0.x?
Brian E. Fox wrote
: Maven Developers List
Subject: Re: Change to artifact version handling.
The mechanism for Artifact version checking should really be pluggable.
It looks like it was originally intended to be (why else would it be
named DefaultArtifactVersion and implement an interface), but the code
just does new
Brett Porter wrote:
On 17/04/2008, at 9:39 PM, Brian E. Fox wrote:
These kinds of changes in the 2.0.x branch concern me. There's no way to
predict what impact this will have out there.
Yes, I thought it'd just be for trunk?
There were two things that occurred to me:
- anything relying on
[mailto:[EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 10:25 AM
To: Maven Developers List
Subject: Re: Change to artifact version handling.
The mechanism for Artifact version checking should really be pluggable.
It looks like it was originally intended to be (why else would it be
named
9:51 AM
To: Maven Developers List
Subject: Re: Change to artifact version handling.
On 17/04/2008, at 9:39 PM, Brian E. Fox wrote:
These kinds of changes in the 2.0.x branch concern me. There's no
way to
predict what impact this will have out there.
Yes, I thought it'd just
ailto:[EMAIL PROTECTED] On Behalf Of Brett Porter
Sent: Thursday, April 17, 2008 9:51 AM
To: Maven Developers List
Subject: Re: Change to artifact version handling.
On 17/04/2008, at 9:39 PM, Brian E. Fox wrote:
> These kinds of changes in the 2.0.x branch concern me. There's no
> way t
hese kinds of changes in the 2.0.x branch concern me. There's no way to
predict what impact this will have out there.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 5:23 AM
To: Maven Developers List
Subject: Re: Change to artifact versi
ore "you could probably get
away with it", not "that'll be fine" - it would be better to support
alternate syntax's such as we'd discussed before.
- Brett
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 17, 200
These kinds of changes in the 2.0.x branch concern me. There's no way to
predict what impact this will have out there.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 5:23 AM
To: Maven Developers List
Subject: Re: Change to artifact ve
I haven't yet applied it, but at first thought it seems a reasonable
change.
- Brett
On 16/04/2008, at 6:37 AM, Paul Gier wrote:
Hi everyone,
I'd like to make a small change to the artifact version parsing. We
currently have several released projects that use a non-standard
version sch
21 matches
Mail list logo
