Transitive dependencies with non-Java code


(Pinter Lorant) #1

I’d like to get the dependency mechanism to work in Gradle with a non-Java programming platform. The platform is called Haxe, but it could as well be Python or Perl.

I publish each of my modules as a ZIP file accompanied by a pom.xml that lists the module’s metadata (group, name, version) and its dependencies (other similar modules packages as ZIP+pom.xml). The artifacts are stored in a Maven repository (Sonatype Nexus):

The pom.xml looks like this:

<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <!-- ... -->
  <packaging>zip</packaging>
  <dependencies>
    <dependency>
      <groupId>haxelib</groupId>
      <artifactId>mcover</artifactId>
      <version>1.4.0</version>
      <type>zip</type>
    </dependency>
    <!-- ... -->
  </dependencies>
</project>

This works fine for non-transitive dependencies that I can use like this:

configurations {
 haxelibs
}
  dependencies {
    haxelibs module(group: "haxelib", name: "munit", version: "0.9.5.2", ext: "zip")
    haxelibs module(group: "haxelib", name: "hamcrest", version: "1.0.1", ext: "zip")
}

However, this approach does not seem to handle transitive dependencies. How can I get Gradle to fetch the transitive dependencies as well?


(Peter Niederwieser) #2

You are using client module dependencies, whose very purpose is to ignore the POM and control transitive dependencies from within the build script. Also, specifying an extension means you are referring to a single file rather than a module (which may include transitive dependencies). Try this instead:

dependencies {
  haxelibs "haxelib:munit:0.9.5.2"
}

(Pinter Lorant) #3

Thanks, this solved one half of the problem.

The other half is that I still have to add { transitive = true } to each dependency, because by default they are intransitive. The haxelibs configuration itself is defined (by default) as transitive, so I wonder: why are the dependencies added to it become intransitive by default?

Now I can work around this by adding this to my build:

configure(configurations.haxelibs.dependencies) {
    transitive = true
}

…but it would be a lot more convenient if this was the default. Can I do that somehow?


(Peter Niederwieser) #4

This shouldn’t be necessary. There must be something else going on in your build (script) that’s causing this.


(Pinter Lorant) #5

I did this just now:

group = "test"
version = "1.0-SNAPSHOT"
  repositories {
    maven {
        credentials {
            username "$nexusUser"
            password "$nexusPassword"
        }
        url "$nexusRepositoriesUrl/thirdparty"
    }
    maven {
        credentials {
            username "$nexusUser"
            password "$nexusPassword"
        }
        url "$nexusRepositoriesUrl/releases"
    }
    mavenCentral()
    mavenLocal()
}
  configurations {
    haxelibs { println "Haxelibs transitive: " + transitive }
    compile { println "Compile transitive: " + transitive }
}
  dependencies {
    haxelibs ("haxelib:munit:0.9.5.2@zip") { println "MUnit transitive: " + transitive }
    compile ("haxelib:munit:0.9.5.2@zip") { println "MUnit/compile transitive: " + transitive }
    compile ("org.apache.commons:commons-io:1.3.2") { println "commons-io/compile transitive: " + transitive }
}

And this is what I got back:

Haxelibs transitive: true
Compile transitive: true
MUnit transitive: false
MUnit/compile transitive: false
commons-io/compile transitive: true
:dependencies
  ------------------------------------------------------------
Root project
------------------------------------------------------------
  compile
+--- haxelib:munit:0.9.5.2
\--- org.apache.commons:commons-io:1.3.2
     \--- commons-io:commons-io:1.3.2
  haxelibs
\--- haxelib:munit:0.9.5.2
  BUILD SUCCESSFUL
  Total time: 2.356 secs

Looks like I hit this: http://issues.gradle.org/browse/GRADLE-160

Or is this caused by the fact perhaps that my dependency is a ZIP, and not, say, a JAR?


(Peter Niederwieser) #6

Why are you still specifying an extension (’@zip’)? As I’ve tried to explain, this disables transitive dependency resolution.


(Pinter Lorant) #7

Sorry, missed that one. It makes sense, and now it works. Thanks for your help!


(Peter Niederwieser) #8

Glad to hear that it works.