Build failure when 4.1.0 of is selected in place of 3.3.0 due to change in artifacts with classifiers

There appears to be a bug related to Maven classifiers. The problems occurs when one version of a pom declares an artifact with a classifier and a later version does not.

The problem is illustrated by a simple build with two dependencies:

apply plugin: 'java'
apply plugin: 'application'

repositories {

mainClassName = 'com.example.Foo'

dependencies {
	compile 'org.mariadb.jdbc:mariadb-java-client:1.1.8'
	compile ''
} has an artifact with a platform classifier in 3.3.0, but does not have this artifact in 4.1.0.

mariadb-java-client has a transitive dependency on Due to the direct dependency on 4.1.0, this dependency is dropped in favour of the 4.1.0 dependency:

compile - Compile classpath for source set 'main'.
+--- org.mariadb.jdbc:mariadb-java-client:1.1.8
|    +--- -> 4.1.0
|    \--- commons-dbcp:commons-dbcp:1.4
|         \--- commons-pool:commons-pool:1.5.4

When the application plugin resolves the runtime configuration as part of the startScripts task, it fails as it’s looking for jna-4.1.0-platform.jar which does not exist:

Could not resolve all dependencies for configuration ':runtime'.
> Could not find jna-platform.jar (
  Searched in the following locations:

It looks like the classifier-related metadata from the 3.3.0 pom is being applied to the 4.1.0 artifacts.

Edit: I neglected to mention that the above was tested with Gradle 2.3

I’m taking a look into this

Here’s a workaround:

dependencies {
    compile ('org.mariadb.jdbc:mariadb-java-client:1.1.8') {
        exclude group: ''
    compile ''
    compile ''

The issue is that the mariadb-java-client POM has two dependencies. One is for with the classifier and one is for without. And since 4.0, publishes the ‘platform’ artifact under a different name (

I don’t believe we have a way of substituting a dependency with a classifier for a completely different dependency yet.

Thanks for the workaround, Sterling.

FWIW, Maven is tripped up by this combination of dependencies as well. It doesn’t cause a build failure, but it does result in a mix of versions on the classpath. It leaves jna:3.3.0-platform on the classpath but evicts jna:3.3.0 in favour of jna:4.1.0