Hans Dockter wrote:
All of this works great... with one small issue. If sub-project "bar"
depends on sub-project "foo", like dev/bar/build.gradle:
--------------------------------------
dependsOn( ":foo" )
compile {
include( "bar/**" )
}
testCompile {
include( "bar/**" )
}
--------------------------------------
(and if any of its classes refer to foo classes as they would likely)
then some of foo's classes will be compiled by javac. After all,
javac has the source directory and doesn't seem to know that the
classes already exist.
But the foo classes get compiled only once, during the build of foo, right?
The foo classes get compiled during the build of foo and placed in foo's
build/classes. Because of the way javac will try to compile any
dependencies it sees, bar also causes the foo classes to get compiled
into bar's build/classes.
However, this is not gradle's problem... just my config mistake.
For anyone else doing something like this, I have found a work-around:
dependencies {
compile project( ":foo" )
}
This is the way "classpath" project dependencies should be established.
It takes also transitive dependencies into account. You don't need to
declare a dependsOn then. dependsOn is a generic way to establish
project dependencies, mostly used by non java projects (e.g. assembly
projects).
I sort of saw the light about three hours later. For Java-based
projects, the "compile project( ":foo" )" is the more important.
I'm still trying to wrap my head around all of this but I "think" I get
it. Check my math...
dependsOn( ":foo" )
Is more or less creating a mess of bar:task->foo:task dependencies. So
it's setting up task dependencies.
On the other hand:
compile project( ":foo" )
Is setting up a _configuration_ dependency. And in my imagination,
because the "compile" task is linked to the "compile" configuration, the
task->task part just works itself out. Though I have been reluctant to
remove the dependsOn() from the top because it does sort of make the
dependency obvious to the casual reader. :)
I feel like I'm starting to "get it" though this week I feel like a
slave to my build tools. At least I feel like I'm learning something
with gradle. I die a little inside every time I have to monkey with a
pom.xml.
-Paul
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
