Hans Dockter wrote:
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.
I have filed an issue: http://jira.codehaus.org/browse/GRADLE-246
This has bitten me again. I had to upload a new wrapper distribution
as a work around.
It bit me a couple of times over the weekend too. I ended up rolling
back some changes rather than update the wrapper. It's become really
annoying. I'm going to have a go at fixing this.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
