Hans Dockter wrote:
On Oct 6, 2008, at 11:32 PM, Adam Murdoch wrote:
Hans Dockter wrote:
On Sep 27, 2008, at 1:34 AM, Adam Murdoch wrote:
So, I'm not sure what to do with this now. I don't really
understand the purpose of executeIsolatedAntScript() so I can't
really suggest (or implement) any solutions yet. I guess that
strictly speaking, the classpath of the isolated ant script should
be as minimal as possible. This means probably just ant and groovy
and nothing else
The Groovyc Ant task (as well as the Groovydoc task) is part of the
groovy distribution. We want to make it possible for Groovy projects
to use a different version of Groovyc and Groovycdoc then the ones
contained in the groovy version shipped with Gradle. In particular
for Groovyc this is very important for people using some new
features of Groovy 1.6. You could not compile them with Groovyc 1.5.
Do you mean use a different version of groovy for their source, or
for their build files, or both? How do you specify that you want to
use a different version of groovy?
For their sources. See user's guide, beginning of chapter 10.
Sorry, I didn't notice that.
I went without success through the Ant Classloader hell before I
implemented the current solution. It is obviously very handcrafted.
I don't understand how this works. It looks like the isolated ant
script is still going to be picking up groovy from gradle's lib dir.
It is picked up but has no precedence as the loaderClasspath parameter
of the executeIsolatedAntScript method contains the user defined
groovy version and is higher in the classpath. In the case of a
compile this loaderClasspath property gets its content from the
getGroovyClasspath property of GroovyCompile. This again is assigned
in the GroovyPlugin. Obviously this code is confusing. The
groovyproject integration test, tests this behavior.
It certainly is confusing. The confusion for me is in figuring out the
*intent* of what its trying to do. Perhaps some renames would help.
Another thing that would help would for the classpath to contain only
ant + groovy and nothing else, and have some kind of modelling so that
they are represented as 2 separate file collection objects.
Another option would be to use an extra classloader, a parent one with
the shared libs (ie ant). This would be shared by the main Gradle
classloader, plus the isolated groovy compilation classloader. Put these
behind a registry and I think we've just started the modularisation work.
Another option would be run the compilation task in a forked process.
Can we invoke the groovy compiler and groovydoc tools directly, rather
than as ant tasks? Then we don't need ant in the classpath.
I suspect we should do the isolated classloader thing for java compiles
too, as the javac tool uses its (context?) classloader to find classes
which are not supplied on the compile classpath.
On a slightly related note, I wonder if we should care about people
wanting to use a version of ant other than the one shipped with Gradle
in their build files? How about a different version of groovy? Both
these things will shake out the modularisation model, and allowing
different versions of groovy will help detangle the core from the DSL layer.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
