Gradle › gradle-dev

Breaking change for POM packaging in Gradle 1.12 builds

classic Classic list List threaded Threaded
♦
♦
 8 messages Options
johnrengelman
Reply | Threaded
Open this post in threaded view
♦
♦
|

Breaking change for POM packaging in Gradle 1.12 builds

johnrengelman
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

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

-- John Engelman
Adam Murdoch
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Breaking change for POM packaging in Gradle 1.12 builds

Adam Murdoch

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
johnrengelman
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Breaking change for POM packaging in Gradle 1.12 builds

johnrengelman
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?

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

Adam Murdoch
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Breaking change for POM packaging in Gradle 1.12 builds

Adam Murdoch

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
johnrengelman
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Breaking change for POM packaging in Gradle 1.12 builds

johnrengelman
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]> 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

Adam Murdoch
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Breaking change for POM packaging in Gradle 1.12 builds

Adam Murdoch

On 7 Feb 2014, at 11:19 am, johnrengelman <[hidden email]> 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 <<a href="x-msg://59/user/SendEmail.jtp?type=node&amp;node=5712249&amp;i=0" target="_top" rel="nofollow" link="external">[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="<a href="x-msg://57/user/SendEmail.jtp?type=node&amp;amp;node=5712247&amp;amp;i=0">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="<a href="x-msg://57/user/SendEmail.jtp?type=node&amp;amp;node=5712248&amp;amp;i=0">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 <a href="x-msg://59/user/SendEmail.jtp?type=node&amp;node=5712250&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
Adam Murdoch
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Breaking change for POM packaging in Gradle 1.12 builds

Adam Murdoch

On 7 Feb 2014, at 2:13 pm, Adam Murdoch <[hidden email]> wrote:


On 7 Feb 2014, at 11:19 am, johnrengelman <[hidden email]> 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.

Which means, of course, that I misread your question. I parsed "dependency type is a POM” as “the pom has a packaging of type ‘pom’”. Sorry about the confusion.


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 <<a href="x-msg://59/user/SendEmail.jtp?type=node&amp;node=5712249&amp;i=0" target="_top" rel="nofollow" link="external">[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="<a href="x-msg://57/user/SendEmail.jtp?type=node&amp;amp;node=5712247&amp;amp;i=0">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="<a href="x-msg://57/user/SendEmail.jtp?type=node&amp;amp;node=5712248&amp;amp;i=0">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 <a href="x-msg://59/user/SendEmail.jtp?type=node&amp;node=5712250&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


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
johnrengelman
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Breaking change for POM packaging in Gradle 1.12 builds

johnrengelman
Ah.....there's the piece I was missing. Thank you for walking me through this. The change makes perfect sense then because it's dealing with the default behavior when you are not declaring a type. 

Keep up the great work!!
—
Sent from Mailbox for iPhone


On Thu, Feb 6, 2014 at 9:16 PM, Adam Murdoch [via Gradle] <[hidden email]> wrote:


On 7 Feb 2014, at 2:13 pm, Adam Murdoch <[hidden email]> wrote:


On 7 Feb 2014, at 11:19 am, johnrengelman <[hidden email]> 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.

Which means, of course, that I misread your question. I parsed "dependency type is a POM” as “the pom has a packaging of type ‘pom’”. Sorry about the confusion.


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 <<a href="x-msg://59/user/SendEmail.jtp?type=node&amp;node=5712249&amp;i=0" target="_top" rel="nofollow" link="external">[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="<a href="x-msg://57/user/SendEmail.jtp?type=node&amp;amp;node=5712247&amp;amp;i=0">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="<a href="x-msg://57/user/SendEmail.jtp?type=node&amp;amp;node=5712248&amp;amp;i=0">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 <a href="x-msg://59/user/SendEmail.jtp?type=node&amp;node=5712250&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


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

Free forum by Nabble Edit this page