On Sep 27, 2008, at 11:16 AM, Hans Dockter wrote:
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.
The AntLoggingAdapter is part of the existing gradle.jar. Therefore
the gradle.jar is needed in the classpath. But obviously it does not
belong there and is the reason for this bug. The solution would be to
have a separate logging-module which contains the AntLoggingAdapter
and some other Gradle logging classes. This module would have a
dependency on logback and slf4j.
When we have talked about the time table of modularization in the
other mail I had forgotten about this bug. I guess we have to tackle
this earlier. We probably should turn the Gradle build into a multi-
project build having a sub-project for each module. This would
clearly express the content of the modules as well as their
dependencies (vs creating a couple of jars in a single project build).
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
