That easy and flexible? Wow, just wow ;) thanks for showing me. -- Sent from my Palm Prē [email protected] http://hibernate.orgAdam Murdoch wrote:
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? Absolutely. The snippet I gave in my previous reply will do exactly that. You don't necessarily need to use multiple projects if you don't want to. A single project can have multiple groups of source directories, known as source sets. Each source set has its own compile task which you can configure independently - including which javac to use. So, given a single project with a layout something like: src/common/java src/jdbc3/java src/jdbc4/java You could define a source set for each of these source directories, and assemble the classes into a single jar. Here is a (complete) example: sourceSets { common // default source dir is 'src/common/java' jdbc3 { compileClasspath = common.classes + common.compileClasspath } jdbc4 { compileClasspath = common.classes + common.compileClasspath } } compileJdbc3Java { fork(executable: 'path-to-java5') } compileJdbc4Java { fork(executable: 'path-to-java6') } jar { from sourceSets.common.classes from sourceSets.jdbc3.classes from sourceSets.jdbc4.classes } > 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. > > Gradle builds the dependency graph for tasks, rather than for projects, and so can deal with these sorts of cyclic project level dependencies. Arguably it's better not to have project dependency cycles, but, if you want or need them for some reason, Gradle will handle it. > 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. >> >> -- Adam Murdoch Gradle Developer http://www.gradle.org --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
