On Sep 27, 2008, at 1:34 AM, Adam Murdoch wrote:
Hi,
I've run across an interesting problem in the classloader isolation
stuff for groovy compilation.
The symptom is, when I change the constructor of a java class which
a groovy class extends, then compilation fails, complaining that
the java class does not have the old constructor. For example, when
I removed the dag parameter from DefaultTask and updated the groovy
tasks, I got lots of compilation failures complaining that
constructor DefaultTask(project, name, dag) did not exist, even
though everything had been updated to use the constructor.
I have run into this problem once before when I have tried to
refactor the exception hierarchy. I thought it was a bug in groovyc.
Digging a little, I found that if I excluded gradle*.jar from the
classpath used to build the isolated classloader in
GradleUtil.executeIsolatedAntScript() then everything compiled
fine. It appears that groovyc is picking up the old classes from
its classloader, rather than from the source it is given. However,
when I removed gradle from the classloader, I also had to remove
the ant logging adapter from the isolated ant build.
This makes a lot of sense to me now that you are pointing this out.
I have filed an issue: http://jira.codehaus.org/browse/GRADLE-246
I haven't checked any of these changes in - these were just
experiments on my machine.
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.
I went without success through the Ant Classloader hell before I
implemented the current solution. It is obviously very handcrafted.
From a design perspective this problem points out to a missing
modularization and isolation of our services (e.g. logging service).
I had a closer look at OSGi recently and it looks to be very useful
for Gradle. We could possibly use it for the internal modularization
of Gradle (logging, build script engine, ...) as well as for our
future plugin system.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
