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

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

<modelVersion>4.0.0</modelVersion>

<groupId>mygroup</groupId>
<artifactId>mymodule</artifactId>
<version>1.0-SNAPSHOT</version>

<packaging>jar</packaging>

<dependencies>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.3.2</version>
</dependency>
</dependencies>

<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.5</version>
<executions>
<execution>
<id>default-jar</id>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>${platform}</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>

</project>

Build MyModule using:

mvn install -Dplatform=glassfish4

build.gradle of MyProject looks like this:

apply plugin: 'java'

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

repositories

dependencies

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.

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

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

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

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

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.

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!

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.