In a multiproject build -- JSR 166 again! -- I have a project specification (only first part given):
project ( ':extra166y' ) {
sourceSets {
main { java { srcDir '../src/extra166y' } }
test { java { srcDir '../src/test/extra166y' } }
}
compileJava.dependsOn project ( ':jsr166' ).jar
compileJava.options.bootClasspath = bootClasspath
test.bootstrapClasspath = bootClasspathCollection
// It seems that the jars are never not rebuilt -- something in the
manifest means that the jars are
// rebuilt on every run. Do not therefore depend on the jars, but
instead on the compiled classes.
dependencies {
compile files ( project ( ':jsr166y' ).sourceSets.main.classesDir )
testCompile files ( project ( ':jsr166tck'
).sourceSets.main.classesDir ) // The extra166y tests depend on classes in the
TCK.
}
. . .
No this correctly causes project :jsr166 to be compiled and the jar to
be created. However :jsr166y is not forceably built if needed. The
path is added to the compile configuration dependencies but the project
is not built. I found this unexpected as my expectation was that there
would be a forced build if needed.
If I just had project ( ':jsr166y') as the dependency then there was a
forced build and creation of the jar.
This current situation seems inconsistent to me. Is it the way it is or
is this a bug? If it is the way it is what is the idiomatically correct
way of specifying the dependency (which seems to me like saying the same
thing twice which is wet rather than DRY ;-)
Thanks.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected]
41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected]
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
