Classpaths/classloaders in Gradle

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Classpaths/classloaders in Gradle

Allan Lewis
I'm having an issue now where code that works when run via command line/Eclipse fails when run through Gradle.  I'm sure that I have the same set of JARs on the classpath in both cases.  I had a similar issue a while back when trying to run as an Ant task, which I never resolved.

I need to track this down further and come up with a test case, but is there anything obvious you can point me at in the meantime?  What is different about classpaths and classloading when running within the context of a Gradle build?
Reply | Threaded
Open this post in threaded view
|

Re: Classpaths/classloaders in Gradle

hans_d
Administrator
Hi Allan,

On May 7, 2008, at 4:01 PM, Allan Lewis wrote:

I'm having an issue now where code that works when run via command
line/Eclipse fails when run through Gradle.  I'm sure that I have the same
set of JARs on the classpath in both cases.  I had a similar issue a while
back when trying to run as an Ant task, which I never resolved.

I need to track this down further and come up with a test case, but is there
anything obvious you can point me at in the meantime?  What is different
about classpaths and classloading when running within the context of a
Gradle build?

Have a look at the class org.gradle.ToolsMain.


This is the class which gets called by the gradle start script.

It adds the tools.jar to the classpath when com.sun.tools.javac.Main can't be found in the classpath. If you start Gradle, at the very beginning of the output you find the message "Modern compiler found." or "No modern compiler." Which of those messages is printed on your machine? If there is no modern compiler (e.g. Sun JDK's for Linux and Windows) we set a new Context Classloader to the executing thread. I'm not sure if this has anything to do with your problems.

Of course I'm very much interested in any code that reproduces this problem.

- Hans

-- 
Sent from the gradle-user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:




--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Classpaths/classloaders in Gradle

Allan Lewis
Hi Hans,

I still need to come up with a good test case, but in the meantime, here is some more info.  I run into issues if I try to execute code from the 'generatefile' you came up with for my multi-project build (executed from a compile.doFirst block).  However, this same code works perfectly well if run from a JUnit test.  Can you think of anything offhand that would be different in these 2 cases?  I remember that when I worked with Maven plugins that I had to force the dependency resolution for my plugin to 'test' to get things to run correctly during the 'generate-sources' phase...

Thanks
Allan
Reply | Threaded
Open this post in threaded view
|

Re: Classpaths/classloaders in Gradle

Allan Lewis
Hans,

Still not sure what the issue was, but I've been able to work around it.  Stuck this in compile.doFirst and everything works perfectly well.

List classpath = test.dependencyManager.resolveTask('test')
       
ant.path(id: 'my-classpath') {
            classpath.each {
                pathelement(location: it)
            }
}
       
ant.java(classname: 'GeneratorGradleWrapper', classpathref: 'my-classpath')

Reply | Threaded
Open this post in threaded view
|

Re: Classpaths/classloaders in Gradle

hans_d
Administrator
In reply to this post by Allan Lewis

On May 8, 2008, at 7:06 AM, Allan Lewis wrote:

Hi Hans,

I still need to come up with a good test case, but in the meantime, here is
some more info.  I run into issues if I try to execute code from the
'generatefile' you came up with for my multi-project build (executed from a
compile.doFirst block).  However, this same code works perfectly well if run
from a JUnit test.  Can you think of anything offhand that would be
different in these 2 cases? 

I guess it has something to do with:

new GroovyShell(new URLClassLoader(classpath, Thread.currentThread().contextClassLoader),            new Binding(project: project)).evaluate(file('generatefile'))
This could lead to classloading problems. What kind of Exceptions did you get?
- Hans

I remember that when I worked with Maven
plugins that I had to force the dependency resolution for my plugin to
'test' to get things to run correctly during the 'generate-sources' phase...

Thanks
Allan
-- 
Sent from the gradle-user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:




--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Classpaths/classloaders in Gradle

Allan Lewis
I've determined that the root of the issue seemed to be coming from a call to the Lookupclass buried within some third-party libraries that I use.  The Lookup class is making use of the JDK's provider extension mechanism (http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Provider%20Configuration%20File).  When running within the GroovyShell, the Lookup class was never able to find an implementation, even though a JAR containing it was on the classpath.  

As I said, I had this exact problem when trying to run my tool as an Ant task a ways back, so this could easily be something related to Ant.  As stated in my other post, I've been able to deal with this by simply doing an Ant java call to run my generator.