Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-Id: <0E581DDE-28A8-443C-9307-E4C231749E25@maven.org>
From: Jason van Zyl <jason@maven.org>
To: "Maven Developers List" <dev@maven.apache.org>
In-Reply-To: 
 <BABD22D888C2324882332D027F51BB950217D6B5@ATLANTIS-EVS.oz.hubbub.com.au>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: Comments on MNG-2123 (version specification issues)
Date: Mon, 3 Mar 2008 15:20:10 -0800
References: <2BABBE7D2A66E04DB8A66A527D29927E35E06E@intrepid.infinity.nu>
 <381C12C7-DF6A-44F2-8C50-5BBDA7205118@apache.org>
 <BABD22D888C2324882332D027F51BB950217D6B5@ATLANTIS-EVS.oz.hubbub.com.au>

It should throw a message with a range that would allow the build to =20
work. So the user can cut and paste that and try that. Picking the =20
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 =20=

>> 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@apache.org]
>> 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@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> 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=92t affect the way you think about programming is =20=

not worth knowing.

-=97 Alan Perlis


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