On 7 Feb 2014, at 11:19 am, johnrengelman <john.r.engel...@gmail.com> wrote:

> 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.

A dependency with type ‘pom’ isn’t quite the case that we’re talking about 
here. The dependency you’ve declared above is equivalent to a dependency on 
‘org.grails:grails-dependencies:2.3.5@pom’ in Gradle, which does work fine and 
isn’t affected by the change.

We’re talking here about when the dependency does not declare a type. So, take 
the <type> element out and this will fail with Maven, and the equivalent 
‘org.gradle:grails-dependencies:2.3.5’ will fail in Gradle.


> 
> 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]> 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&amp;node=5712247&amp;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
>>>> 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 <a 
>>>> href="x-msg://57/user/SendEmail.jtp?type=node&amp;node=5712248&amp;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
>>> 
>>> 
>>> 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
>> 
>> 
>> 
>> 
>> 
>> 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 [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



Reply via email to