Ok, I understand. So I guess I'll try to work on this for 2.1?
Brian E. Fox wrote:
I honestly don't think such changes can or should be made in 2.0.x. We
are nine releases into this branch, the focus needs to be on stabilizing
it not adding more dangerous changes.
-----Original 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
extension? That seems like the best solution.
Could this be implemented in 2.0.x?
Brian E. Fox wrote:
I agree with that sentiment. I think the pluggable nature of the
handler
needs to be able to handle multiple definitions in the same pom. Ie
just
because you want the osgi behavior on one dependency may not mean you
want to switch your entire build.
-----Original Message-----
From: Ralph Goers [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 DefaultArtifactVersion and implement an interface), but the code
just does new DefaultArtifactVersion. I would prefer to have this
fixed
before doing anything about the patch below. I know there are other
use
cases where people have wanted to do other things such as include a
fourth digit, but these can't be done as things stand.
Ralph
Brian E. Fox wrote:
We still have to provide a migration path to 2.1 even if we make the
changes there...it just delays the problem. But I'm exactly concerned
about this reversing the current range behavior. It seems like we
need
ways to specify the format.
-----Original Message-----
From: Brett Porter [mailto:[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 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 the Maven format won't work with this one and
will need to add additional handling.
- anyone relying on the string parsing might have behavioural changes
(though it would be very unusual - you'd be expecting
1.0.11.something
< 1.0.2.something)
I have to admit my thought with this was more "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, 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 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 scheme. So instead of something like:
1.0.1-beta-1
we have
1.0.1.beta1
This was originally done to conform to the OSGi standard which
requires a "." instead of a "-" for the qualifier. If you ask me,
the maven standard is better ;)
I created a jira issue with the attached fix here:
http://jira.codehaus.org/browse/MNG-3526
Since this change could potentially (although I think unlikely)
break some dependency management I wanted to bring it up here to
discuss.
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
