I had a similar question with Groovy sources depending on Java classes, and
wondering if I had to have all of my Java files under src/groovy. But on
reading Peter's response more closely, I got it working with a minor tweak
to the build file. This was all I needed to do to get it to work:
sourceSets.main {
java.srcDirs = []
groovy.srcDir 'src/main/java'
}
Note that this isn't "configuring the workflow" per se, but avoids the need
to have java files under src/groovy, which seems to be the main concern
regarding communication and clarity. The only issue I see is if a developer
runs "compileJava" it doesn't do anything, since the java sources are
compiled by the "compileGroovy" task.
Hope that helps
Daz
On 9 May 2011 08:22, bart <[email protected]> wrote:
> Thanks for your reply Peter. I do understand your response and I know that
> the gradle way of doing this will work just fine. On a personal level I'm
> fine with the solution.
>
> However, this became a big discussion in the office and it felt a little
> like the old maven conversations. "It works fine if you do it the way the
> way they want, which is clearly documented, but no, we can't do it our way
> without writing our own plugin." You see we have a rather common business
> model with FTE's working out of multiple offices, varying numbers of
> contractors, and varying numbers of off shore developers. So, when our
> build makes a physical statement like "src/scala" we intend it to be a true
> statement. Not all developers would think to look in src/scala for java
> files. I know this is a mundane problem and is easily solved through
> effective communication. However, since we aren't communicating
> effectively
> by placing java files in the scala directory, that argument is not a very
> strong one.
>
> When I did the first the POC for gradle I was blown away by how
> configurable
> it was! I could take a LARGE and COMPLEX legacy java app (over 10 years
> old)
> and get it working with gradle in the EXACT same way as in ant, but with
> hundreds of fewer lines in the build files. The gradle folks really seemed
> to nail the concept of configurable convention! But this one little
> wrinkle
> with scala challenges how configurable gradle really is. So, if the answer
> is "no, you cannot configure the workflow" I'm fine with communicating that
> to my superiors. I just don't want to make a false statement. I've read
> as
> much I can find using google, and I don't really have any answers yet.
> That's why I'm asking here.
>
> Thanks for your thoughtful responses.
>
> Bart
>
> --
> View this message in context:
> http://gradle.1045684.n5.nabble.com/Mixed-Scala-Java-project-tp3378120p4381989.html
> Sent from the gradle-user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
