On Nov 5, 2008, at 7:16 AM, Russel Winder wrote:
On Mon, 2008-11-03 at 11:00 +0100, Hans Dockter wrote:
My first approach was to stick with the Ant defaults. Then I adapted
them to our needs when problems arose. Javac seems capable of
isolating itself properly when run in non fork mode (if
includeAntRuntime is set to false). Groovyc can't do this as I have
just discovered (I guess you have noticed my postings to the Groovy
list). So fork = true is a must have for Groovyc compile. I can't see
any reasons why we shouldn't do the same for javac but I wanted to
ask if other people have a reason not to do it.
Another advantage of forking is that the build can define the memory
it needs and people don't have to manually modify the JAVA_OPTS.
I have never tinkered with includeAntRuntime, I have always just used
javac in non-fork mode for trivial cases (where the classpath doesn't
actually matter than much) or fork mode when I need control of the
classpath. I guess this mind set was very much behind not even
thinking
of includeAntRuntime when I added fork mode to groovyc.
Then you might be in trouble ;). The 'includeAntRuntime' is by
default set to true (for javac as well as groovyc). So even using
groovyc in fork mode will add the ant runtime classpath to the forked
compilation, if includeAntRuntime is not explicitly set to false.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
