Le samedi 20 septembre 2014 11:18:50 Robert Scholte a écrit : > Op Sat, 20 Sep 2014 03:35:56 +0200 schreef William Ferguson > > <william.fergu...@xandar.com.au>: > > 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, introducing your own syntax in a recipe for disaster. Luckily the > pom-elements are already strict due to the xsd, the content is still > something which needs to be validated programmatically due to > ${}-expressions. Another reason to introduce the consumer-pom :) +1
> > Robert > > > 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
