On Oct 6, 2009, at 5:56 PM, Steve Ebersole wrote:
For background, this is related to this discussion
http://in.relation.to/Bloggers/SimultaneouslySupportingJDBC3AndJDBC4WithMaven
So you said that inter-project dependencies use the jar file *by
default*. So it sounds like that is at least changeable in some
fashion. In the ideal world, I'd set this up such that my CORE
project
is *compiled* first, then the 2 JDBC modules are compiled against the
classes just compiled from CORE; and then going back to CORE I'd do
the
jar packaging including the classes from CORE as well as the 2 JDBC
projects/modules. Is something like that achievable using gradle? I
currently use maven and the trouble there is that maven performs all
"phases" on each project/module before moving on to the next
project/module.
From Adam's mail:
project 1 & 2
dependencies {
compile { project('project3').sourceSets.main.classes }
}
project 3:
jar {
from { project('project1').sourceSets.main.classes }
from { project('project2').sourceSets.main.classes }
}
This configuration would exactly lead to the behavior you want to
have. In Gradle, from a low level perspective, projects are syntactic
sugar. Everything is resolved to a single task graph. So task1 from
project1 can depend on task1 from project2, whereas task2 from
project2 may depend on task2 from project1. Usually you don't have to
care about the task level. You just declare your build like above:
Gradle autowires your task automatically. This means if you declare
something as an input value and this something needs to be build,
Gradle automatically creates the dependencies for you. If you at the
declaration (for project1/2):
dependencies {
compile { project('project3').sourceSets.main.classes }
}
When project1 is compiled, the compile task of project1 automatically
depends on the compile task of project3. And has the output as its
input value.
jar {
from { project('project1').sourceSets.main.classes }
from { project('project2').sourceSets.main.classes }
}
With this declaration the jar task of project3 automatically depends
on the compile task of project1/2. And, as this is the default jar
task, is already configured to depend on the compile task of project1.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
On Tue, 2009-10-06 at 21:22 +1100, Adam Murdoch wrote:
Steve Ebersole wrote:
I am curious whether Gradle offers a solution to the problem of
compiling against different JDKs but including the compiled
classes into
a single jar.
I assume the different JDKs would need to be isolated into different
modules, at least that's how I best see this operating with IDEs. So
then is it possible to have 2 modules that depend on a 3rd for
compilation but where classes are bundled into the artifact from
that
3rd?
Yes. Though, it is complicated a bit by the fact that inter-project
(ie
inter-module) dependencies use the jar file by default. So the 2
projects would depend on the jar from the 3rd, which would in turn
depend on the classes from the 2 projects.
This isn't a big deal, you could do something like:
project 1 & 2
dependencies {
compile { project('project3').sourceSets.main.classes }
}
project 3:
jar {
from { project('project1').sourceSets.main.classes }
from { project('project2').sourceSets.main.classes }
}
You could also do a similar thing with some custom configurations.
Some other options:
- Add a second jar file to project 3 which contains all the classes.
- Add a fourth project which aggregates the 3 other projects.
- Use a single project, and use a source set for each java version.
--
Steve Ebersole <[email protected]>
Hibernate.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
