You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mark Struberg <st...@yahoo.de> on 2014/11/28 10:54:15 UTC
Re: Ivy style versions propagating in Maven central
+1 if they like to use Mavens infrastructure then they also need to play according to those rules.
Anyone likes to talk with the Ivy guys? They have to fix this.
Another question is what we do with those existing poms in maven.central? Do we convert them? What about sha1, md5 and asc in that case? Rewriting existing poms would lead to breaking them.
LieGrue,
strub
> On Saturday, 20 September 2014, 7:44, Mirko Friedenhagen <mf...@gmail.com> wrote:
> > +1 for checking when uploading to Central.
>
> Regards
> Mirko
> --
> Sent from my mobile
>
> On Sep 20, 2014 4:22 AM, "Jason van Zyl" <ja...@takari.io>
> wrote:
>
>>
>> On Sep 19, 2014, at 9:35 PM, William Ferguson <
>> william.ferguson@xandar.com.au> wrote:
>>
>> > Because of the rise of Gradle usage to its inclusion as the build tool
> in
>> > Android Studio, there are more and more artifacts making their way
> into
>> > Maven Central whose POMs contain elements that do not conform to Maven
>> > expectations.
>> >
>> > A good example is this POM:
>> >
>>
> http://search.maven.org/#artifactdetails%7Ccom.squareup%7Cfest-android%7C1.0.8%7Cjar
>> >
>> > It has a dependency that uses the Gradle/Ivy version syntax of 19.1+
> to
>> > indicate a range.
>> > Maven does not parse this version string and dies.
>> >
>> > So the question is what should be done about it.
>> >
>> > Some ideas:
>> >
>> > 1. Maven central starts verifying and rejecting malformed POMs with
> a
>> > reason for rejection.
>>
>> +1
>>
>> This is just terrible syntax and doesn't follow any normal set notation
>> established by any existing systems. Normal set notation works perfectly
>> fine and using something else is not really a boon for anyone.
>>
>> > 2. Maven starts handling the Gradle/Ivy version syntax either as
>> > 1. an optional extra
>> > 2. a permanent move forward (configurable to support backward
>> > compatibility)
>> >
>> > William
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> ---------------------------------------------------------
>>
>> I never make the mistake of arguing with people for whose opinions I have
>> no respect.
>>
>> -- Edward Gibbon
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Ivy style versions propagating in Maven central
Posted by Manfred Moser <ma...@mosabuam.com>.
This rule is now live on OSSRH so no new deployments will be able with that issue. I posted a little update notification yesterday and we also notified via twitter and other means earlier.
http://central.sonatype.org/articles/2014/Nov/27/dependency-version-range-enforcement-live-on-ossrh/
In terms of changing old artifacts it has been a long standing rule for Central NOT to do any modifications. As such if you run into trouble with an artifact that uses the syntax I would urge you all to notify the offenders and ask them to fix it and release a new version.
Manfred
Mark Struberg wrote on 28.11.2014 01:54:
> +1 if they like to use Mavens infrastructure then they also need to play
> according to those rules.
>
> Anyone likes to talk with the Ivy guys? They have to fix this.
>
>
> Another question is what we do with those existing poms in maven.central? Do we
> convert them? What about sha1, md5 and asc in that case? Rewriting existing
> poms would lead to breaking them.
>
>
>
> LieGrue,
> strub
>
>
>
>
>
>> On Saturday, 20 September 2014, 7:44, Mirko Friedenhagen
>> <mf...@gmail.com> wrote:
>> > +1 for checking when uploading to Central.
>>
>> Regards
>> Mirko
>> --
>> Sent from my mobile
>>
>> On Sep 20, 2014 4:22 AM, "Jason van Zyl" <ja...@takari.io>
>> wrote:
>>
>>>
>>> On Sep 19, 2014, at 9:35 PM, William Ferguson <
>>> william.ferguson@xandar.com.au> wrote:
>>>
>>> > Because of the rise of Gradle usage to its inclusion as the build tool
>> in
>>> > Android Studio, there are more and more artifacts making their way
>> into
>>> > Maven Central whose POMs contain elements that do not conform to Maven
>>> > expectations.
>>> >
>>> > A good example is this POM:
>>> >
>>>
>> http://search.maven.org/#artifactdetails%7Ccom.squareup%7Cfest-android%7C1.0.8%7Cjar
>>> >
>>> > It has a dependency that uses the Gradle/Ivy version syntax of 19.1+
>> to
>>> > indicate a range.
>>> > Maven does not parse this version string and dies.
>>> >
>>> > So the question is what should be done about it.
>>> >
>>> > Some ideas:
>>> >
>>> > 1. Maven central starts verifying and rejecting malformed POMs with
>> a
>>> > reason for rejection.
>>>
>>> +1
>>>
>>> This is just terrible syntax and doesn't follow any normal set notation
>>> established by any existing systems. Normal set notation works perfectly
>>> fine and using something else is not really a boon for anyone.
>>>
>>> > 2. Maven starts handling the Gradle/Ivy version syntax either as
>>> > 1. an optional extra
>>> > 2. a permanent move forward (configurable to support backward
>>> > compatibility)
>>> >
>>> > William
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> http://twitter.com/takari_io
>>> ---------------------------------------------------------
>>>
>>> I never make the mistake of arguing with people for whose opinions I have
>>> no respect.
>>>
>>> -- Edward Gibbon
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> 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