Using modules to separate JDK dependencies

[Steve Ebersole]

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?

--
Steve Ebersole <steve@...>

Hibernate.org

-- Sent from my Palm Prē

[Adam Murdoch-2]

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

[Steve Ebersole]

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.


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 <steve@...>
Hibernate.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[hdockter]

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 <steve@...>
> 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

[Adam Murdoch-2]

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

[Steve Ebersole]

That easy and flexible?  Wow, just wow ;)  thanks for showing me.

-- Sent from my Palm Prē

steve@...
http://hibernate.org

---

Adam 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

[Steve Ebersole]

The difficulty here is that this does not fit well with IDEs (at least
not the IDEs with which I am familiar).  Most (all?) IDEs want to
associate a JDK with each module/project.  So the approach of using
multiple modules/projects here fits best IMO because it can be used in
gradle as well as in an IDE.

But I do love that gradle gives you this kind of flexibility.


On Wed, 2009-10-07 at 08:39 +1100, Adam Murdoch wrote:

> 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
> }

--
Steve Ebersole <steve@...>
Hibernate.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Ebersole]

I am trying to figure out exactly how I can specify that a different JDK
(different from the one used to launch gradle) be used for the javac
tasks for a given (sub)project.  Any pointers?

On Wed, 2009-10-07 at 10:14 -0500, Steve Ebersole wrote:

> The difficulty here is that this does not fit well with IDEs (at least
> not the IDEs with which I am familiar).  Most (all?) IDEs want to
> associate a JDK with each module/project.  So the approach of using
> multiple modules/projects here fits best IMO because it can be used in
> gradle as well as in an IDE.
>
> But I do love that gradle gives you this kind of flexibility.
>
>
> On Wed, 2009-10-07 at 08:39 +1100, Adam Murdoch wrote:
> > 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
> > }
>

--
Steve Ebersole <steve@...>
Hibernate.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Ebersole]

Ok, got past that (thanks to much help from Jason on IRC):

compileJava {
    options.fork(executable: '/opt/java/jdk-1.6/bin/javac')
}

However, I am not able to get the dependencies to work properly.  It
works fine if I just do:

dependencies {
    compile project(':core')
}

But that gives trouble later when I go to do:

jar {
    from { project(':jdbc3').sourceSets.main.classes }
    from { project(':jdbc4').sourceSets.main.classes }
}

complaining about:
* What went wrong:
Circular dependency between tasks. Cycle includes task
':core:uploadDefaultInternal'.

Looking closer at you suggestions, you had actually said to use:

dependencies {
    compile project(':core').sourceSets.main.classes
}

To reference the classes directory rather than the jar.  However, that
is leading to this on my system:
Cause: No such property: sourceSets for class:
org.gradle.api.internal.artifacts.dependencies.DefaultProjectDependency

Was unable to find DefaultProjectDependency in javadocs at
http://www.gradle.org/0.8/docs/javadoc/ to check.


On Thu, 2009-10-08 at 23:55 -0500, Steve Ebersole wrote:

> I am trying to figure out exactly how I can specify that a different JDK
> (different from the one used to launch gradle) be used for the javac
> tasks for a given (sub)project.  Any pointers?
>
> On Wed, 2009-10-07 at 10:14 -0500, Steve Ebersole wrote:
> > The difficulty here is that this does not fit well with IDEs (at least
> > not the IDEs with which I am familiar).  Most (all?) IDEs want to
> > associate a JDK with each module/project.  So the approach of using
> > multiple modules/projects here fits best IMO because it can be used in
> > gradle as well as in an IDE.
> >
> > But I do love that gradle gives you this kind of flexibility.
> >
> >
> > On Wed, 2009-10-07 at 08:39 +1100, Adam Murdoch wrote:
> > > 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
> > > }
> >

--
Steve Ebersole <steve@...>
Hibernate.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

Steve Ebersole wrote:

> Ok, got past that (thanks to much help from Jason on IRC):
>
> compileJava {
>     options.fork(executable: '/opt/java/jdk-1.6/bin/javac')
> }
>
> However, I am not able to get the dependencies to work properly.  It
> works fine if I just do:
>
> dependencies {
>     compile project(':core')
> }
>
> But that gives trouble later when I go to do:
>
> jar {
>     from { project(':jdbc3').sourceSets.main.classes }
>     from { project(':jdbc4').sourceSets.main.classes }
> }
>
> complaining about:
> * What went wrong:
> Circular dependency between tasks. Cycle includes task
> ':core:uploadDefaultInternal'.
>
>  

That's right. A project dependency uses the jar from the target project.
In your case, the jar need the classes from the other projects, which in
turn need the jar in order to be compiled.

> Looking closer at you suggestions, you had actually said to use:
>
> dependencies {
>     compile project(':core').sourceSets.main.classes
> }
>
> To reference the classes directory rather than the jar.  However, that
> is leading to this on my system:
> Cause: No such property: sourceSets for class:
> org.gradle.api.internal.artifacts.dependencies.DefaultProjectDependency
>
>  

You'll need to use:

dependencies {
    compile this.project(':core').sourceSets.main.classes
}

Note the call to this.project(...).

We need this because DependencyHandler (the delegate for the
dependencies {} closure) has a project() method which returns a
ProjectDependency, which we don't want - we want the ':core' Project
returned by Project.project().

I think the distinction is a little confusing. We could clean this up so
that project('...') always returns a Project, and we use some other
syntax for project dependencies which need configuring.

> Was unable to find DefaultProjectDependency in javadocs at
> http://www.gradle.org/0.8/docs/javadoc/ to check.
>
>
> On Thu, 2009-10-08 at 23:55 -0500, Steve Ebersole wrote:
>  
>> I am trying to figure out exactly how I can specify that a different JDK
>> (different from the one used to launch gradle) be used for the javac
>> tasks for a given (sub)project.  Any pointers?
>>
>> On Wed, 2009-10-07 at 10:14 -0500, Steve Ebersole wrote:
>>    
>>> The difficulty here is that this does not fit well with IDEs (at least
>>> not the IDEs with which I am familiar).  Most (all?) IDEs want to
>>> associate a JDK with each module/project.  So the approach of using
>>> multiple modules/projects here fits best IMO because it can be used in
>>> gradle as well as in an IDE.
>>>
>>> But I do love that gradle gives you this kind of flexibility.
>>>
>>>
>>> On Wed, 2009-10-07 at 08:39 +1100, Adam Murdoch wrote:
>>>      
>>>> 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
>>>> }
>>>>        

--
Adam Murdoch
Gradle Developer
http://www.gradle.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[LightGuard]

On Fri, Oct 9, 2009 at 00:49, Adam Murdoch <a@...> wrote:

>
>
> Steve Ebersole wrote:
>>
>> Ok, got past that (thanks to much help from Jason on IRC):
>>
>> compileJava {
>>    options.fork(executable: '/opt/java/jdk-1.6/bin/javac')
>> }
>>
>> However, I am not able to get the dependencies to work properly.  It
>> works fine if I just do:
>>
>> dependencies {
>>    compile project(':core')
>> }
>>
>> But that gives trouble later when I go to do:
>>
>> jar {
>>    from { project(':jdbc3').sourceSets.main.classes }
>>    from { project(':jdbc4').sourceSets.main.classes }
>> }
>>
>> complaining about:
>> * What went wrong:
>> Circular dependency between tasks. Cycle includes task
>> ':core:uploadDefaultInternal'.
>>
>>  
>
> That's right. A project dependency uses the jar from the target project. In
> your case, the jar need the classes from the other projects, which in turn
> need the jar in order to be compiled.
>
>> Looking closer at you suggestions, you had actually said to use:
>>
>> dependencies {
>>    compile project(':core').sourceSets.main.classes
>> }
>>
>> To reference the classes directory rather than the jar.  However, that
>> is leading to this on my system:
>> Cause: No such property: sourceSets for class:
>> org.gradle.api.internal.artifacts.dependencies.DefaultProjectDependency
>>
>>  
>
> You'll need to use:
>
> dependencies {
>   compile this.project(':core').sourceSets.main.classes
> }
>
> Note the call to this.project(...).
>
> We need this because DependencyHandler (the delegate for the dependencies {}
> closure) has a project() method which returns a ProjectDependency, which we
> don't want - we want the ':core' Project returned by Project.project().
>
> I think the distinction is a little confusing. We could clean this up so
> that project('...') always returns a Project, and we use some other syntax
> for project dependencies which need configuring.
>
>> Was unable to find DefaultProjectDependency in javadocs at
>> http://www.gradle.org/0.8/docs/javadoc/ to check.
>>
>>
>> On Thu, 2009-10-08 at 23:55 -0500, Steve Ebersole wrote:
>>  
>>>
>>> I am trying to figure out exactly how I can specify that a different JDK
>>> (different from the one used to launch gradle) be used for the javac
>>> tasks for a given (sub)project.  Any pointers?
>>>
>>> On Wed, 2009-10-07 at 10:14 -0500, Steve Ebersole wrote:    
>>>>
>>>> The difficulty here is that this does not fit well with IDEs (at least
>>>> not the IDEs with which I am familiar).  Most (all?) IDEs want to
>>>> associate a JDK with each module/project.  So the approach of using
>>>> multiple modules/projects here fits best IMO because it can be used in
>>>> gradle as well as in an IDE.
>>>>
>>>> But I do love that gradle gives you this kind of flexibility.
>>>>
>>>>
>>>> On Wed, 2009-10-07 at 08:39 +1100, Adam Murdoch wrote:
>>>>      
>>>>>
>>>>> 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
>>>>> }
>>>>>        
>
> --
> Adam Murdoch
> Gradle Developer
> http://www.gradle.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>

We must be doing something wrong Adam.

project structure:
|____build.gradle
|____core
| |____src
| | |____main
| | | |____java
|____jdbc3
| |____build.gradle
| |____src
| | |____main
| | | |____java
| | |____test
| | | |____java
| | | |____resources
|____jdbc4
| |____build.gradle
| |____src
| | |____main
| | | |____java
| | |____test
| | | |____java
| | | |____resources
|____settings.gradle

Here are the build files
[main]
usePlugin 'java'

jar {
 from this.project(':core').sourceSets.main.classes
 from this.project(':jdbc3').sourceSets.main.classes
 from this.project(':jdbc4').sourceSets.main.classes
}

subprojects {
    usePlugin('java')

    repositories {
       mavenCentral()
    }

    dependencies {
        compile(
            'org.slf4j:slf4j-api:1.5.8'
        )
        testCompile(
            'junit:junit:3.8.2',
            'org.slf4j:jcl-over-slf4j:1.5.8',
            'org.slf4j:slf4j-log4j12:1.5.8'
        )
    }

    group = 'org.gradle'
    version = '1.0'
    manifest.mainAttributes(provider: 'gradle')
}

dependsOnChildren()

[jdbc3]
dependencies {
    compile this.project(':core').sourceSets.main.classes
}

compileJava {
    options.fork( executable: '/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Commands/javac' )
}

[jdbc4]
dependencies {
    compile this.project(':core').sourceSets.main.classes
    compile this.project(':jdbc3').sourceSets.main.classes
}

compileJava {
    options.fork( executable: '/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/javac' )
}

output from main:
gradle jar
:core:compileJava
:core:processResources
:core:classes
:jdbc3:compileJava
:jdbc3:processResources
:jdbc3:classes
:jdbc4:compileJava
:compileJava
:jdbc4:processResources
:processResources
:jdbc4:classes
:classes
:core:jar
:jdbc3:jar
:jdbc4:jar
:jar
[ant:jar] Warning: skipping jar archive /Users/jporter/projects/gradle/gradle-1/build/libs/gradle-1-unspecified.jar because no files were included.
[ant:jar] Warning: skipping jar archive /Users/jporter/projects/gradle/gradle-1/build/libs/gradle-1-unspecified.jar because no files were included.

BUILD SUCCESSFUL

Every thing I've tried points to the fact that the source sets aren't being resolved to their correct locations, they keep going back to the main folder :
(

--
Jason Porter
Real Programmers think better when playing Adventure or Rogue.

PGP key id: 926CCFF5
PGP fingerprint: 64C2 C078 13A9 5B23 7738 F7E5 1046 C39B 926C CFF5
PGP key available at: keyserver.net, pgp.mit.edu

[Adam Murdoch-2]

Adam Murdoch wrote:

>
>
> Steve Ebersole wrote:
>> Ok, got past that (thanks to much help from Jason on IRC):
>>
>> compileJava {
>>     options.fork(executable: '/opt/java/jdk-1.6/bin/javac')
>> }
>>
>> However, I am not able to get the dependencies to work properly.  It
>> works fine if I just do:
>>
>> dependencies {
>>     compile project(':core')
>> }
>>
>> But that gives trouble later when I go to do:
>>
>> jar {
>>     from { project(':jdbc3').sourceSets.main.classes }
>>     from { project(':jdbc4').sourceSets.main.classes }
>> }
>>
>> complaining about:
>> * What went wrong:
>> Circular dependency between tasks. Cycle includes task
>> ':core:uploadDefaultInternal'.
>>
>>  
>
> That's right. A project dependency uses the jar from the target
> project. In your case, the jar need the classes from the other
> projects, which in turn need the jar in order to be compiled.

I wonder if it would be better for a project compilation dependency to
use the classes of the target project, rather the jar of the target
project. It would certainly help in your case.

It would also help more generally for projects where multiple projects
are aggregated into a single jar file, as we wouldn't need to build a
bunch of intermediate jars which are not actually used in a distribution.


--
Adam Murdoch
Gradle Developer
http://www.gradle.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[LightGuard]

On Fri, Oct 9, 2009 at 01:50, Adam Murdoch <a@...> wrote:

>
>
> Adam Murdoch wrote:
>>
>>
>> Steve Ebersole wrote:
>>>
>>> Ok, got past that (thanks to much help from Jason on IRC):
>>>
>>> compileJava {
>>>    options.fork(executable: '/opt/java/jdk-1.6/bin/javac')
>>> }
>>>
>>> However, I am not able to get the dependencies to work properly.  It
>>> works fine if I just do:
>>>
>>> dependencies {
>>>    compile project(':core')
>>> }
>>>
>>> But that gives trouble later when I go to do:
>>>
>>> jar {
>>>    from { project(':jdbc3').sourceSets.main.classes }
>>>    from { project(':jdbc4').sourceSets.main.classes }
>>> }
>>>
>>> complaining about:
>>> * What went wrong:
>>> Circular dependency between tasks. Cycle includes task
>>> ':core:uploadDefaultInternal'.
>>>
>>>  
>>
>> That's right. A project dependency uses the jar from the target project.
>> In your case, the jar need the classes from the other projects, which in
>> turn need the jar in order to be compiled.
>
> I wonder if it would be better for a project compilation dependency to use
> the classes of the target project, rather the jar of the target project. It
> would certainly help in your case.
>
> It would also help more generally for projects where multiple projects are
> aggregated into a single jar file, as we wouldn't need to build a bunch of
> intermediate jars which are not actually used in a distribution.
>
>
> --
> Adam Murdoch
> Gradle Developer
> http://www.gradle.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>

I think that would make a lot of sense.  That's really all you care about at the end of the day.  Intermittent jars slow things down too (zip, then unzip), also which MANIFEST.MF file is the one in the final jar?  Typically not a big concern, but it could be.

--
Jason Porter
Real Programmers think better when playing Adventure or Rogue.

PGP key id: 926CCFF5
PGP fingerprint: 64C2 C078 13A9 5B23 7738 F7E5 1046 C39B 926C CFF5
PGP key available at: keyserver.net, pgp.mit.edu

[Adam Murdoch-2]

lightguard.jp@... wrote:

> We must be doing something wrong Adam.
>
> project structure:
> |____build.gradle
> |____core
> | |____src
> | | |____main
> | | | |____java
> |____jdbc3
> | |____build.gradle
> | |____src
> | | |____main
> | | | |____java
> | | |____test
> | | | |____java
> | | | |____resources
> |____jdbc4
> | |____build.gradle
> | |____src
> | | |____main
> | | | |____java
> | | |____test
> | | | |____java
> | | | |____resources
> |____settings.gradle
>
> Here are the build files
> [main]
> usePlugin 'java'
>
> jar {
> from this.project(':core').sourceSets.main.classes
> from this.project(':jdbc3').sourceSets.main.classes
> from this.project(':jdbc4').sourceSets.main.classes
> }
>

I'm not sure why this doesn't work - I'll have to dig into this.

In the meantime, a workaround is to add .asFileTree to the end of each
classes set:

jar {
   from project(':core').sourceSets.main.classes.asFileTree
   ....
}


--
Adam Murdoch
Gradle Developer
http://www.gradle.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Ebersole]

Anyway, I got this to point I am pretty happy with.  There is still the
minor issue of jdbc3 and jdbc4 producing jars even though their classes
are consumed into the core jar, but that's really just a minor annoyance
(would be great if there were an option to not generate the jars at some
point though I think).

http://www.jboss.org/community/wiki/Hibernate-JDBC4support
http://in.relation.to/Bloggers/SimultaneouslySupportingJDBC3AndJDBC4WithMavenII

Anyway, thanks again to Hans, Adam and Jason for all the help.  


On Fri, 2009-10-09 at 20:53 +1100, Adam Murdoch wrote:

>
> lightguard.jp@... wrote:
> > We must be doing something wrong Adam.
> >
> > project structure:
> > |____build.gradle
> > |____core
> > | |____src
> > | | |____main
> > | | | |____java
> > |____jdbc3
> > | |____build.gradle
> > | |____src
> > | | |____main
> > | | | |____java
> > | | |____test
> > | | | |____java
> > | | | |____resources
> > |____jdbc4
> > | |____build.gradle
> > | |____src
> > | | |____main
> > | | | |____java
> > | | |____test
> > | | | |____java
> > | | | |____resources
> > |____settings.gradle
> >
> > Here are the build files
> > [main]
> > usePlugin 'java'
> >
> > jar {
> > from this.project(':core').sourceSets.main.classes
> > from this.project(':jdbc3').sourceSets.main.classes
> > from this.project(':jdbc4').sourceSets.main.classes
> > }
> >
>
> I'm not sure why this doesn't work - I'll have to dig into this.
>
> In the meantime, a workaround is to add .asFileTree to the end of each
> classes set:
>
> jar {
>    from project(':core').sourceSets.main.classes.asFileTree
>    ....
> }
>
>

--
Steve Ebersole <steve@...>
Hibernate.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Ebersole]

Actually Jason figured out the piece about skipping the jar building.
In the 2 projects where I dont want jars you just add the line:

jar.enabled = false

easy! :)

On Fri, 2009-10-09 at 12:23 -0500, Steve Ebersole wrote:

> Anyway, I got this to point I am pretty happy with.  There is still the
> minor issue of jdbc3 and jdbc4 producing jars even though their classes
> are consumed into the core jar, but that's really just a minor annoyance
> (would be great if there were an option to not generate the jars at some
> point though I think).
>
> http://www.jboss.org/community/wiki/Hibernate-JDBC4support
> http://in.relation.to/Bloggers/SimultaneouslySupportingJDBC3AndJDBC4WithMavenII
>
> Anyway, thanks again to Hans, Adam and Jason for all the help.  
>
>
> On Fri, 2009-10-09 at 20:53 +1100, Adam Murdoch wrote:
> >
> > lightguard.jp@... wrote:
> > > We must be doing something wrong Adam.
> > >
> > > project structure:
> > > |____build.gradle
> > > |____core
> > > | |____src
> > > | | |____main
> > > | | | |____java
> > > |____jdbc3
> > > | |____build.gradle
> > > | |____src
> > > | | |____main
> > > | | | |____java
> > > | | |____test
> > > | | | |____java
> > > | | | |____resources
> > > |____jdbc4
> > > | |____build.gradle
> > > | |____src
> > > | | |____main
> > > | | | |____java
> > > | | |____test
> > > | | | |____java
> > > | | | |____resources
> > > |____settings.gradle
> > >
> > > Here are the build files
> > > [main]
> > > usePlugin 'java'
> > >
> > > jar {
> > > from this.project(':core').sourceSets.main.classes
> > > from this.project(':jdbc3').sourceSets.main.classes
> > > from this.project(':jdbc4').sourceSets.main.classes
> > > }
> > >
> >
> > I'm not sure why this doesn't work - I'll have to dig into this.
> >
> > In the meantime, a workaround is to add .asFileTree to the end of each
> > classes set:
> >
> > jar {
> >    from project(':core').sourceSets.main.classes.asFileTree
> >    ....
> > }
> >
> >

--
Steve Ebersole <steve@...>
Hibernate.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email