[GROOVY-10543] Problem with groovy-all Gradle module metadata

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 4.0.0, 4.0.1
• Fix Version/s: 4.0.2
• Assignee: Paul King
• Reporter: Louis Jacomet
• Created: 24/Mar/22 13:13
• Updated: 27/Apr/22 08:33
• Resolved: 19/Apr/22 11:27

Description

Groovy 4 started publishing Gradle module metadata (GMM) for its artifacts which is great.

 

However there is a problem with the choice made for groovy-all.

The Maven POM for groovy-all is of type pom and lists dependencies but has no dependencyManagement entries, indicating it is to be used as a <type>pom</type> dependency in Maven in order to get the different dependencies on a classpath.

On the other side, the Gradle module metadata matches the definition of a Gradle platform. Their consumption is a bit different than regular dependencies as you need to specify you want the platform variants.

 

This creates a problem when declaring the dependency on groovy-all in a Gradle build:

• If the build does not consume GMM but uses the POM file instead, the dependency must be a regular one. This will allow transitive dependencies to be available. If instead Gradle tried to consume a platform from a POM file, it would ignore all dependencies. This matches the behavior of importing a BOM in Maven when using <type>pom</type> and <scope>import</scope>.
• If the build does consume GMM, the dependency must be a platform one - using the platform helper or explicit attributes. Otherwise Gradle will not be able to resolve the variant. This is the most likely root cause of this issue from the mailing list.

Given the role of groovy-all, it does not really match the concept of a Gradle platform and so should instead be published as a regular component, although without a JAR. This would allow consumption in Gradle to be always declared as a regular dependency and the behaviour - pulling in the transitive dependencies - would be consistent between consuming the POM or the Gradle Module Metadata