GMaven 'execute' goal + Class.forName

[Tom Nichols]

I seem to have a problem with how GMaven does its dependency
classloading, particularly in relation to dependencies from
groovy:execute scripts.

From a script, I can create an instance of a given class, but can't
load that same class via Class.forName.  Now I don't mind so much
about that, but dependent code that I'm trying to execute relies on
this behavior.

Example POM attached.  You'll see that the first line prints out the
class' name (so it's on the classpath) but this script's classloader
fails to load the class when calling Class.forName.

Bug report?

Thanks.
-Tom

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>gmaven-classloading</groupId>
  <artifactId>gmaven-classloading</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>gmaven-classloading</name>
        <build>
                <plugins>
                        <plugin>
                                <groupId>org.codehaus.groovy.maven</groupId>
                                <artifactId>gmaven-plugin</artifactId>
                                <configuration>
                                        <source>
                                                import org.apache.commons.io.*
                                                println FileCleaner.class.name
                                                Class.forName 'org.apache.commons.io.FileCleaner'
                                        </source>
                                </configuration>
                        </plugin>
                        <plugin>
                                <artifactId>maven-compiler-plugin</artifactId>
                                <configuration>
                                        <source>1.5</source>
                                        <target>1.5</target>
                                </configuration>
                        </plugin>
                </plugins>
        </build>
  <dependencies>
                <dependency>
                        <groupId>org.codehaus.groovy</groupId>
                        <artifactId>groovy</artifactId>
                        <version>[1.5,)</version>
                </dependency>
                <dependency>
                        <groupId>org.apache.commons</groupId>
                        <artifactId>commons-io</artifactId>
                        <version>1.3.2</version>
                </dependency>
        </dependencies>
       
</project>

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

    http://xircles.codehaus.org/manage_email

[Jason Dillon]

This may be due to Class.forName() not looking at the TCL, actually I  
don't recommend *ever* using Class.forName() because of this... or  
really, use the TCL, then fall-back to Class.forName().  The classes  
are there on the thread context classloader (aka TCL).

IMO Sun's impl of Class.forName() is broke for more than the simplest  
of configurations... so I recommend getting your dependency to  
properly load classes in a non-trivial environment by using the TCL.

--jason


On Jun 23, 2009, at 1:21 AM, Tom Nichols wrote:

> I seem to have a problem with how GMaven does its dependency
> classloading, particularly in relation to dependencies from
> groovy:execute scripts.
>
> From a script, I can create an instance of a given class, but can't
> load that same class via Class.forName.  Now I don't mind so much
> about that, but dependent code that I'm trying to execute relies on
> this behavior.
>
> Example POM attached.  You'll see that the first line prints out the
> class' name (so it's on the classpath) but this script's classloader
> fails to load the class when calling Class.forName.
>
> Bug report?
>
> Thanks.
> -Tom
> <
> pom
> .xml
> >---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email

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

    http://xircles.codehaus.org/manage_email