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
>> <[email protected]> wrote:
>> > +1 for checking when uploading to Central.
>> 
>> Regards
>> Mirko
>> -- 
>> Sent from my mobile
>> 
>> On Sep 20, 2014 4:22 AM, "Jason van Zyl" <[email protected]> 
>> wrote:
>> 
>>> 
>>>  On Sep 19, 2014, at 9:35 PM, William Ferguson <
>>>  [email protected]> 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: [email protected]
> For additional commands, e-mail: [email protected]
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to