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. Others have played with it since so I am not sure what teh current state is. Personally I think fork mode is worth the overhead since it makes a clean separation between the Ant context and the compile context. I can envisage though situations where the overhead might be unacceptable. I think I prefer fork mode as default though. -- Russel. ==================================================== Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077
signature.asc
Description: This is a digitally signed message part
