Dependency on other module's jar file with a classifier - how?


(Wujek Srujek) #1

I have a project that produces 2 jars: core-1.0.jar and core-1.0-testUtils.jar. The latter one is created from a custom sourceSet (testUtils) and it used by the core module’s tests - this works fine. However, I have another module that depends on an ‘api’ module for compilation, and on the ‘core’ module for testing. I do it like this:

test project(’:core’)

The problem is that I don’t know how to address the core-1.0-testUtils.jar so that it is available during compilation of the tests. I tried:

test project(path: ‘:core’, classifier: ‘testUtils’)

but this doesn’t work (yes, the jar task does use this classifier, but this attribute seems unsupported for project dependencies). Is this at all possible? Or is classifier available only for external dependencies?


So I introduced a ‘testUtils’ configuration and added:

artifacts {

testUtils testUtilsJar }

in the ‘core’ module’s build.gradle. Now I can address this jar like this in other modules:

test project(path: ‘:core’, configuration: ‘testUtils’)

and they compile. What is missing, though, is jar is not built when I build the ‘core’ module, it is only built on demand when other modules are built when this jar is required. I would like the jar to be built when the main, default, jar is built - in the assemble phase. Is this possible?

wujek


(Peter Niederwieser) #2

Can’t you just add a task dependency? For example ‘assemble.dependsOn(…)’.


(Wujek Srujek) #3

I can, true. But as this is a module artifact, I would assume this would be picked up automatically (found such a claim somewhere in the net -http://mrhaki.blogspot.de/2010/11/gradle-goodness-create-jar-artifact.html) but it isn’t, so I thought there were some other mechanism.

How about the first question?


(Peter Niederwieser) #4

By default, the ‘assemble’ task only builds artifacts that belong to the ‘archives’ configuration. Hence, it is expected that the test Jar will not be picked up automatically.

How about the first question?

A ‘testUtils’ configuration is certainly the way to go here. A project dependency is always a dependency on a particular configuration, not on some artifact.


(Wujek Srujek) #5

Thank you.