You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Paul King (Jira)" <ji...@apache.org> on 2022/04/19 11:27:00 UTC

[jira] [Assigned] (GROOVY-10543) Problem with groovy-all Gradle module metadata

     [ https://issues.apache.org/jira/browse/GROOVY-10543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul King reassigned GROOVY-10543:
----------------------------------

    Assignee: Paul King

> Problem with groovy-all Gradle module metadata
> ----------------------------------------------
>
>                 Key: GROOVY-10543
>                 URL: https://issues.apache.org/jira/browse/GROOVY-10543
>             Project: Groovy
>          Issue Type: Bug
>    Affects Versions: 4.0.0, 4.0.1
>            Reporter: Louis Jacomet
>            Assignee: Paul King
>            Priority: Major
>          Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> 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|https://docs.gradle.org/7.4.1/userguide/java_platform_plugin.html#sec:java_platform_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|https://lists.apache.org/thread/lrofbk9qt66sopzfcmsbn8ph7wn866zj] 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



--
This message was sent by Atlassian Jira
(v8.20.1#820001)