[GRADLE-3188] Gradle ignores transitive dependencies when specifying a classifier Created: 29/Oct/14  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 4


I am working on a multi platform Java EE product/framework project. We need to support different ApplicationServer platforms, like JBoss, WebSphere, Glassfish,...
We are currently working with a Maven build and use classifiers to distinguish the different platforms. Now I'd like to evaluate Gradle to check whether we could do the same build using Gradle, but I run into the following problem:

When specifying a dependency with classifier, e.g.

compile 'mygroup:mymodule:1.0-SNAPSHOT:glassfish4'

Gradle ignores transitive dependencies - in contrast to Maven.

If I rename the JAR of the artifact in my local Maven cache from mymodule-1.0-SNAPSHOT-glassfish4.jar to mymodule-1.0-SNAPSHOT.jar transitive dependencies are resolved as expected.

Is this a bug or am I missing something regarding dependency management in Gradle?

Comment by Gradle Forums [ 29/Oct/14 ]

Sounds like a bug to me. Can you also reproduce this when resolving from a remote repository, rather than Maven Local?

Comment by Gradle Forums [ 29/Oct/14 ]

I don't know an open source project on maven central that uses classifiers this way.

Here is a small reproducer.

pom.xml of MyModule:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">







Build MyModule using:

mvn install -Dplatform=glassfish4

build.gradle of MyProject looks like this:

apply plugin: 'java'

group = 'mygroup'
version = '1.0-SNAPSHOT'


{ mavenLocal() mavenCentral() }


{ compile 'mygroup:mymodule:1.0-SNAPSHOT:glassfish4' }

Calling gradle dependencies only lists mygroup:mymodule:1.0-SNAPSHOT
After renaming mymodule-1.0-SNAPSHOT-glassfish4.jar to mymodule-1.0-SNAPSHOT.jar in the local maven cache commons-lang3 will be listed as transitive dependency.

Comment by Gradle Forums [ 29/Oct/14 ]

> I don't know an open source project on maven central that uses classifiers this way.

Are you saying that there is anything special about your usage of classifiers?

It would be great to know if the problem is limited to Maven Local or also applies to remote repositories (i.e. the standard case; Maven Local should only be used if artifacts need to be exchanged with a local Maven build).

Comment by Gradle Forums [ 29/Oct/14 ]

We just do not only use the common classifiers tests or sources. We also use classifiers to distinguish application server specific jars. The jars can contain platform specific classes (security, transaction management,...), platform specific deployment descriptors or generated EJB classes.
As far as I know, this is not disallowed by maven:

"The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number." ([1]http://maven.apache.org/pom.html)

Another use case would be to distinguish native libraries by os or chip architecture identifier.

I just don' t know a project on Maven Central that uses such classifiers.
[1] http://maven.apache.org/pom.html

Comment by ohad r [ 09/Feb/16 ]

can it be that gradle does not bring transitive dependencies for SNAPSHOTs?

Comment by Mohan Kornipati [ 19/Apr/16 ]

Team, We came across a need of this fix in our projects. Just to check if this is been planned for fixing?

Comment by Brill Pappin [ 14/Sep/16 ]

This is a huge issue for Android developers.
We often have debug/release classifiers for your libraries and use both.

This bug forces us to include transitive dependencies manually and has already cause problems when one library gets update and not another.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:42:18 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.