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]
