I just created and ran this POM file with Maven 3.0.3: https://gist.github.com/johnrengelman/8855175
It simply declares 1 dependency to org.grails:grails-dependencies with a type of pom. <dependencies> <dependency> <groupId>org.grails</groupId> <artifactId>grails-dependencies</artifactId> <version>2.3.5</version> <type>pom</type> </dependency> </dependencies> I than ran 'mvn site' which generates a dependency report. No errors were thrown and the dependency report includes the transitive dependencies from the grails-dependencies POM. So, I'm failing to see how this isn't supported in Maven, but maybe I'm missing a key detail here. -- John Engelman On Thursday, February 6, 2014 at 5:43 PM, Adam Murdoch [via Gradle] wrote: > > On 7 Feb 2014, at 10:34 am, johnrengelman <[hidden email] > (/user/SendEmail.jtp?type=node&node=5712249&i=0)> wrote: > > Hmm, > > I'm not sure I follow completely, so I'll just pose an example to see what > > the answer is. > > > > The Grails-Gradle plugin automatically adds a dependency to > > 'org.grails:grails-dependencies' and the dependency type is a POM. This POM > > simply declares a number of transitive dependencies to other Grails core > > component libraries and supporting framework libraries for that version of > > Grails. From your answer below, this is a direct POM packaging dependency > > and not a parent of a Jar dependency. In this situation, won't the new code > > throw an exception because there isn't a Jar file associated with the > > dependency? > > Yes it will. That’s the breaking change. It also won’t work with Maven. > > The Grails-Gradle plugin might instead generate a pom that imports > org.grails:grails-dependencies instead of including it as a dependency. > > > > > > -- > > John Engelman > > > > > > On Thursday, February 6, 2014 at 5:25 PM, Adam Murdoch [via Gradle] wrote: > > > > > > > > On 7 Feb 2014, at 8:31 am, johnrengelman <<a > > > href="x-msg://57/user/SendEmail.jtp?type=node&node=5712247&i=0" > > > target="_top" rel="nofollow" link="external">[hidden email]> wrote: > > > > Hi all - > > > > I just saw this commit in the master branch which would put it on track > > > > from > > > > Gradle 1.12 - > > > > https://github.com/gradle/gradle/commit/97fb925848249251129f7ea0d70f12bdf112f2d0 > > > > <https://github.com/gradle/gradle/commit/97fb925848249251129f7ea0d70f12bdf112f2d0> > > > > > > > > > > > > This introduces a breaking change (as noted in the release notes) > > > > regarding > > > > dependencies that have a 'pom' packing type. Basically, it forces > > > > Gradle to > > > > assume that a dependency also as an associated Jar regardless of the > > > > packing > > > > and if it doesn't it fails. > > > > > > > > I'm curious why this change is being made? I couldn't find a forum > > > > topic or > > > > recent JIRA ticket related to it. These was the behavior of Gradle <1.9 > > > > and > > > > prevented Gradle from being used on the same systems being used for > > > > Maven > > > > build (i.e. a CI server). This is because Maven installs a number of > > > > artifacts like this into the local .m2 cache. For every dependency it > > > > downloads the pom file into the local .m2 and then only downloads the > > > > Jar > > > > for the conflict resolved version. This leaves orphaned POM files in > > > > the .m2 > > > > and if a Gradle build comes along and wants that version, it would error > > > > because the Jar file isn't available. > > > > > > > > It seems this commit is simply re-instating the previous behavior which > > > > will > > > > again make Gradle builds fail on systems that are also building Maven > > > > projects (or even Grails projects using Aether since they utilizing the > > > > .m2 > > > > cache in the same manner). > > > > > > Don’t worry, the maven local behaviour hasn’t changed. It would be a bit > > > unfortunate to add it in 1.9 only to take it out a couple of releases > > > later. > > > > > > The change is to treat modules with packaging ‘pom’ the same way as every > > > other kind of module when the module is used as a dependency (but not > > > when it is used as a parent). > > > > > > There’re two reasons for this: > > > > > > 1. It’s what maven does. Packaging doesn’t have any effect at resolution > > > time. > > > 2. It removes the HEAD request to probe for the module jar. This, for > > > example, has a performance impact for poms that are used as an imported > > > pom or a parent pom (these graphs can get quite deep). > > > > > > > > > > > > -- > > > Adam Murdoch > > > Gradle Co-founder > > > http://www.gradle.org (http://www.gradle.org/) > > > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > > > http://www.gradleware.com (http://www.gradleware.com/) > > > > > > > > > > > > > > > > > > If you reply to this email, your message will be added to the discussion > > > below: > > > http://gradle.1045684.n5.nabble.com/Breaking-change-for-POM-packaging-in-Gradle-1-12-builds-tp5712246p5712247.html > > > > > > To start a new topic under gradle-dev, email <a > > > href="x-msg://57/user/SendEmail.jtp?type=node&node=5712248&i=0" > > > target="_top" rel="nofollow" link="external">[hidden email] > > > To unsubscribe from Breaking change for POM packaging in Gradle 1.12 > > > builds, click here. > > > NAML > > > (http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml) > > > > > > > > > View this message in context: Re: Breaking change for POM packaging in > > Gradle 1.12 builds > > (http://gradle.1045684.n5.nabble.com/Breaking-change-for-POM-packaging-in-Gradle-1-12-builds-tp5712246p5712248.html) > > Sent from the gradle-dev mailing list archive > > (http://gradle.1045684.n5.nabble.com/gradle-dev-f1436218.html) at > > Nabble.com (http://Nabble.com). > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > > > > > If you reply to this email, your message will be added to the discussion > below: > http://gradle.1045684.n5.nabble.com/Breaking-change-for-POM-packaging-in-Gradle-1-12-builds-tp5712246p5712249.html > > To start a new topic under gradle-dev, email > ml-node+s1045684n1436218...@n5.nabble.com > (mailto:ml-node+s1045684n1436218...@n5.nabble.com) > To unsubscribe from Breaking change for POM packaging in Gradle 1.12 builds, > click here > (http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5712246&code=am9obi5yLmVuZ2VsbWFuQGdtYWlsLmNvbXw1NzEyMjQ2fDIyMTUyNjEzNQ==). > NAML > (http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml) > -- View this message in context: http://gradle.1045684.n5.nabble.com/Breaking-change-for-POM-packaging-in-Gradle-1-12-builds-tp5712246p5712250.html Sent from the gradle-dev mailing list archive at Nabble.com.
