Groovy/Java mixed codebase

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Groovy/Java mixed codebase

rstudner
This is a problem i'm sure has been solved over and over.. I just can't =
find it via da googles :)

src
main
 java
  com
   AClass
   BClass
 groovy
  com
   SomeOtherClass

SomeOtherClass refers to AClass.. but BClass refers to SomeOtherClass

Since it performs compileJava and then compileGroovy, it is a chicken =
and egg problem.

Right now I solve this by putting 100% of my code under src/main/groovy

i'm guessing this is a sourceSet issue, or a way to include things on =
the classpath (one or the other).

Thanks!

Roger


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Groovy/Java mixed codebase

John Murph
Actually, what you are doing is the correct thing.  It's not a Gradle issue so much as a Groovy compiler issue -- to cross-compile between Java and Groovy when there are references back and forth (as you have), the Groovy compiler has to handle compiling both Java and Groovy sources.  Gradle does this when all your code lives under src/*/groovy as you said.  I do suspect you could tell Gradle to use both src/main/java and src/main/groovy as the Groovy source directories, but that would seem confusing anyway, since people could put .groovy files in src/main/java and .java files in src/main/groovy and everything would continue working.


On Thu, Apr 22, 2010 at 8:08 PM, Roger Studner <[hidden email]> wrote:
This is a problem i'm sure has been solved over and over.. I just can't =
find it via da googles :)

src
main
 java
 com
  AClass
  BClass
 groovy
 com
  SomeOtherClass

SomeOtherClass refers to AClass.. but BClass refers to SomeOtherClass

Since it performs compileJava and then compileGroovy, it is a chicken =
and egg problem.

Right now I solve this by putting 100% of my code under src/main/groovy

i'm guessing this is a sourceSet issue, or a way to include things on =
the classpath (one or the other).

Thanks!

Roger


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

   http://xircles.codehaus.org/manage_email





--
John Murph
Automated Logic Research Team
Reply | Threaded
Open this post in threaded view
|

Re: Groovy/Java mixed codebase

Adam Murdoch-2
In reply to this post by rstudner


On 23/04/10 10:08 AM, Roger Studner wrote:

> This is a problem i'm sure has been solved over and over.. I just can't =
> find it via da googles :)
>
> src
> main
>   java
>    com
>     AClass
>     BClass
>   groovy
>    com
>     SomeOtherClass
>
> SomeOtherClass refers to AClass.. but BClass refers to SomeOtherClass
>
> Since it performs compileJava and then compileGroovy, it is a chicken =
> and egg problem.
>
> Right now I solve this by putting 100% of my code under src/main/groovy
>
>    

This is what the groovy plugin convention expects, which may or may not
be a good idea.

You can do something like this, so you can put java source under
src/main/java and groovy source under src/main/groovy, and still get the
joint compilation:

sourceSets.main.java.srcDirs = [] // ie there's no stand-alone java source
sourceSets.main.groovy.srcDir 'src/main/java' // ie include the 'java'
dir as groovy source

It's a little awkward.

Perhaps it would be better if you could declare dependencies between
source sets, something like:

sourceSets.main {
     java {
         dependsOn groovy // a cycle -> Gradle does joint compilation
     }
     groovy {
         dependsOn java  // this is the default
     }
}

Or perhaps if you could add one source set to another, something like:

sourceSets.main {
     groovy {
         from java // include in joint compilation
     }
}


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


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Groovy/Java mixed codebase

Kenneth Kousen
I'm trying to use gradle on some existing Groovy/Java projects that were created using the Groovy Eclipse plugin.  Since those projects don't separate groovy and java classes in the src directory, I just mapped the project like:

sourceSets {
    main {
        java {
            srcDir 'src'
        }
        groovy {
            srcDir 'src'
        }
    }
    test {
        java {
            srcDir 'tests'
        }
        groovy {
            srcDir 'tests'
        }
    }
}

I have both Java and Groovy classes in my src and tests directories.  When I run "gradle build", everything seems to work okay.  Is that a reasonable approach?  It seems a lot easier than trying to rewrite the project structure.

Ken

On Fri, Apr 23, 2010 at 8:28 PM, Adam Murdoch <[hidden email]> wrote:


On 23/04/10 10:08 AM, Roger Studner wrote:
This is a problem i'm sure has been solved over and over.. I just can't =
find it via da googles :)

src
main
 java
  com
   AClass
   BClass
 groovy
  com
   SomeOtherClass

SomeOtherClass refers to AClass.. but BClass refers to SomeOtherClass

Since it performs compileJava and then compileGroovy, it is a chicken =
and egg problem.

Right now I solve this by putting 100% of my code under src/main/groovy

 

This is what the groovy plugin convention expects, which may or may not be a good idea.

You can do something like this, so you can put java source under src/main/java and groovy source under src/main/groovy, and still get the joint compilation:

sourceSets.main.java.srcDirs = [] // ie there's no stand-alone java source
sourceSets.main.groovy.srcDir 'src/main/java' // ie include the 'java' dir as groovy source

It's a little awkward.

Perhaps it would be better if you could declare dependencies between source sets, something like:

sourceSets.main {
   java {
       dependsOn groovy // a cycle -> Gradle does joint compilation
   }
   groovy {
       dependsOn java  // this is the default
   }
}

Or perhaps if you could add one source set to another, something like:

sourceSets.main {
   groovy {
       from java // include in joint compilation
   }
}


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



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

  http://xircles.codehaus.org/manage_email





--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: [hidden email]
Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen
Reply | Threaded
Open this post in threaded view
|

Re: Groovy/Java mixed codebase

Adam Murdoch-2


On 7/05/10 7:46 AM, Kenneth Kousen wrote:
I'm trying to use gradle on some existing Groovy/Java projects that were created using the Groovy Eclipse plugin.  Since those projects don't separate groovy and java classes in the src directory, I just mapped the project like:

sourceSets {
    main {
        java {
            srcDir 'src'
        }
        groovy {
            srcDir 'src'
        }
    }
    test {
        java {
            srcDir 'tests'
        }
        groovy {
            srcDir 'tests'
        }
    }
}

I have both Java and Groovy classes in my src and tests directories.  When I run "gradle build", everything seems to work okay.  Is that a reasonable approach?  It seems a lot easier than trying to rewrite the project structure.

An important goal for Gradle is that it can deal with whatever layout you have, and not force you to move stuff around if you don't want to. Of course, there are good reasons to follow the conventional layout, but if you don't want to, you don't have to.

So, your approach is quite reasonable. One problem with what you've declared is that Gradle will attempt to compile the java source twice. The compileJava task compiles **/*.java in the java source dirs, and the compileGroovy task compiles **/*.java and **/*.groovy in the groovy source dirs (for joint compilation). This is arguably an implementation problem, and that compileGroovy should exlude everything that compileJava will compile. Regardless, you can work around this by doing something like:

sourceSets {
    main {
        java { srcDirs = [] } // no source dirs
        groovy { srcDir 'src' } // includes all .groovy and .java files under src
   }
   ...
}



Ken

On Fri, Apr 23, 2010 at 8:28 PM, Adam Murdoch <[hidden email]> wrote:


On 23/04/10 10:08 AM, Roger Studner wrote:
This is a problem i'm sure has been solved over and over.. I just can't =
find it via da googles :)

src
main
 java
  com
   AClass
   BClass
 groovy
  com
   SomeOtherClass

SomeOtherClass refers to AClass.. but BClass refers to SomeOtherClass

Since it performs compileJava and then compileGroovy, it is a chicken =
and egg problem.

Right now I solve this by putting 100% of my code under src/main/groovy

 

This is what the groovy plugin convention expects, which may or may not be a good idea.

You can do something like this, so you can put java source under src/main/java and groovy source under src/main/groovy, and still get the joint compilation:

sourceSets.main.java.srcDirs = [] // ie there's no stand-alone java source
sourceSets.main.groovy.srcDir 'src/main/java' // ie include the 'java' dir as groovy source

It's a little awkward.

Perhaps it would be better if you could declare dependencies between source sets, something like:

sourceSets.main {
   java {
       dependsOn groovy // a cycle -> Gradle does joint compilation
   }
   groovy {
       dependsOn java  // this is the default
   }
}

Or perhaps if you could add one source set to another, something like:

sourceSets.main {
   groovy {
       from java // include in joint compilation
   }
}


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



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

  http://xircles.codehaus.org/manage_email





--
Kenneth A. Kousen
President
Kousen IT, Inc.

Email: [hidden email]
Site: http://www.kousenit.com
Blog: http://kousenit.wordpress.com
Twitter: @kenkousen

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