On 7 Feb 2014, at 10:34 am, johnrengelman <john.r.engel...@gmail.com> 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 <[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 >> 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-tp5712246p5712247.html >> To start a new topic under gradle-dev, email [hidden email] >> To unsubscribe from Breaking change for POM packaging in Gradle 1.12 builds, >> click here. >> NAML > > > View this message in context: Re: Breaking change for POM packaging in Gradle > 1.12 builds > Sent from the gradle-dev mailing list archive at Nabble.com. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
