Comments on MNG-2123 (version specification issues)

[Brian E Fox]

http://jira.codehaus.org/browse/MNG-2123

 

The proposed fix is to return RELEASE as the version if two dependencies
at the same level specify incompatible versions (ie 3.2 and
(2.0,3.1.99]). Clearly we shouldn't throw an NPE, but returning the
RELEASE version feels wrong. First that totally breaks repeatability of
a build and second, shouldn't we notify the user with a useful exception
instead of guessing anything?

 

--Brian

[brettporter]

The test case provided at the end seems like a different issue to the  
one Carlos originally described. I would suggest cloning the issue for  
that and it looks like the original report is either already fixed or  
easy to come up with a test case. Carlos?

For the example given below, I believe 3.2 is equivalent to 3.2.0 in  
the system, so is certainly > 3.1.99. Since (at present), 3.2  
represents a suggestion and not a requirement, the original range  
should be returned, and later the latest release within that range  
should be selected. If 3.2 where expressed as a hard requirement, it  
should throw an exception.

Cheers,
Brett

On 04/03/2008, at 5:05 AM, Brian E. Fox wrote:

> http://jira.codehaus.org/browse/MNG-2123
>
>
>
> The proposed fix is to return RELEASE as the version if two  
> dependencies
> at the same level specify incompatible versions (ie 3.2 and
> (2.0,3.1.99]). Clearly we shouldn't throw an NPE, but returning the
> RELEASE version feels wrong. First that totally breaks repeatability  
> of
> a build and second, shouldn't we notify the user with a useful  
> exception
> instead of guessing anything?
>
>
>
> --Brian
>

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[William Ferguson]

> If 3.2 where (sic) expressed as a hard requirement, it should throw an
exception.

Yes, but not a NullPointer.
The reason for the failure needs to be clear and unambiguous.

William

> -----Original Message-----
> From: Brett Porter [mailto:brett@...]
> Sent: Tuesday, 4 March 2008 7:52 AM
> To: Maven Developers List
> Subject: Re: Comments on MNG-2123 (version specification issues)
>
> The test case provided at the end seems like a different
> issue to the one Carlos originally described. I would suggest
> cloning the issue for that and it looks like the original
> report is either already fixed or easy to come up with a test
> case. Carlos?
>
> For the example given below, I believe 3.2 is equivalent to
> 3.2.0 in the system, so is certainly > 3.1.99. Since (at
> present), 3.2 represents a suggestion and not a requirement,
> the original range should be returned, and later the latest
> release within that range should be selected. If 3.2 where
> expressed as a hard requirement, it should throw an exception.
>
> Cheers,
> Brett
>
> On 04/03/2008, at 5:05 AM, Brian E. Fox wrote:
>
> > http://jira.codehaus.org/browse/MNG-2123
> >
> >
> >
> > The proposed fix is to return RELEASE as the version if two
> > dependencies at the same level specify incompatible
> versions (ie 3.2
> > and (2.0,3.1.99]). Clearly we shouldn't throw an NPE, but returning
> > the RELEASE version feels wrong. First that totally breaks
> > repeatability of a build and second, shouldn't we notify
> the user with
> > a useful exception instead of guessing anything?
> >
> >
> >
> > --Brian
> >
>
> --
> Brett Porter
> brett@...
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@... For
> additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jason van Zyl-2]

It should throw a message with a range that would allow the build to  
work. So the user can cut and paste that and try that. Picking the  
RELEASE in the case of a conflict just doesn't make any sense.

On 3-Mar-08, at 3:05 PM, William Ferguson wrote:

>> If 3.2 where (sic) expressed as a hard requirement, it should throw  
>> an
> exception.
>
> Yes, but not a NullPointer.
> The reason for the failure needs to be clear and unambiguous.
>
> William
>
>
>> -----Original Message-----
>> From: Brett Porter [mailto:brett@...]
>> Sent: Tuesday, 4 March 2008 7:52 AM
>> To: Maven Developers List
>> Subject: Re: Comments on MNG-2123 (version specification issues)
>>
>> The test case provided at the end seems like a different
>> issue to the one Carlos originally described. I would suggest
>> cloning the issue for that and it looks like the original
>> report is either already fixed or easy to come up with a test
>> case. Carlos?
>>
>> For the example given below, I believe 3.2 is equivalent to
>> 3.2.0 in the system, so is certainly > 3.1.99. Since (at
>> present), 3.2 represents a suggestion and not a requirement,
>> the original range should be returned, and later the latest
>> release within that range should be selected. If 3.2 where
>> expressed as a hard requirement, it should throw an exception.
>>
>> Cheers,
>> Brett
>>
>> On 04/03/2008, at 5:05 AM, Brian E. Fox wrote:
>>
>>> http://jira.codehaus.org/browse/MNG-2123
>>>
>>>
>>>
>>> The proposed fix is to return RELEASE as the version if two
>>> dependencies at the same level specify incompatible
>> versions (ie 3.2
>>> and (2.0,3.1.99]). Clearly we shouldn't throw an NPE, but returning
>>> the RELEASE version feels wrong. First that totally breaks
>>> repeatability of a build and second, shouldn't we notify
>> the user with
>>> a useful exception instead of guessing anything?
>>>
>>>
>>>
>>> --Brian
>>>
>>
>> --
>> Brett Porter
>> brett@...
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@... For
>> additional commands, e-mail: dev-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

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@...
For additional commands, e-mail: dev-help@...