You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Thomas Tardy <th...@gmail.com> on 2008/04/08 08:22:55 UTC

Using Maven Ant Tasks in a CI Environment with IBM Jazz

Hello,

I'm struggeling with some problems using the Maven ant tasks in the CI
environment with IBM Jazz. There are some ant tasks for IBM Jazz which
are handling the connection between the build engine and the Jazz
server. These Jazz ant tasks are working well as long as I haven't
used the Maven ant task in the build script. One of the Jazz guys
analyzed the problem as follows:

[quote]
I was able to get some understanding of this problem.  Maven is
switching out the context class loader on the main Ant thread when
their task is invoked.   Before the Maven task runs when everything
works properly...the main ant thread has a class loader of...

classLoader    Launcher$AppClassLoader  (id=113)
sun.misc.Launcher$AppClassLoader@92e78c

After the Maven task runs the class loader is now...

classLoader    RealmClassLoader  (id=166)
org.codehaus.classworlds.RealmClassLoader@1685e30

EMF can no longer find the appropriate factory as it delegates to the
class loader to find the EMF package.  The NPE is then thrown as it
attempts to use the null factory to get the item type in
WebServicesSAXXHandler while marshalling the request to the server.  I
hacked into our task a trap of the class loader before the Maven call
and then set it back the next time our task executed.  Everything
worked fine again.  It seems ridiculous that Maven is switching the
class loader for the main ant thread when their task executes...at the
very least if this insanity is necessary they should be switching it
back.

It appears you can work around this problem by making your pom call
into Maven before you call any of our ant tasks.  We then appear to
get initially loaded into their class loader correctly and everything
works ok.
[/quote]

Why is the Maven ant task switching the class loader for the main ant
thread? Is this a bug or works as designed?

Thanks for your feedback!

Regards,
Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Using Maven Ant Tasks in a CI Environment with IBM Jazz

Posted by Donald Weinand <dm...@us.ibm.com>.
Here's a simple ant class and script that demonstrates the problem.  It uses
the Maven sample.

The ant build script:
<?xml version="1.0" encoding="UTF-8"?>
<project name="MavenTest" default="default"
xmlns:artifact="antlib:org.apache.maven.artifact.ant">
    <description>
            description
    </description>

	<taskdef name="mavenTestTask"
	         classname="maven.test.task.MavenTestTask" />
	
    <target name="default">
    	<echo message="Invoking test class that does nothing but echo the
classloader"/>
        <mavenTestTask/>
    	
    	<echo message="Invoking maven artifact:pom task"/>
		<artifact:pom id="pom" file="C:/maven-sample/my-app/pom.xml" />

    	<echo message="Invoking test class again that does nothing but echo the
classloader"/>
    	
        <mavenTestTask/>
    	
    </target>
</project>

The simple Ant Task:
package maven.test.task;

import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.Task;

/**
 *  Test task demonstrating Maven switching the class loader.
 */
public class MavenTestTask extends Task {

    /* (non-Javadoc)
     * Intentionally not documented. See parent.
     */
    @Override
    public void execute() throws BuildException {
        log("Current Class Loader: " +
Thread.currentThread().getContextClassLoader());
    }
    

The output when run in Ant:
Buildfile: C:\Maven\Test\build.xml
default:
     [echo] Invoking test class that does nothing but echo the classloader
[mavenTestTask] Current Class Loader:
sun.misc.Launcher$AppClassLoader@e39a3e
     [echo] Invoking maven artifact:pom task
     [echo] Invoking test class again that does nothing but echo the
classloader
[mavenTestTask] Current Class Loader:
org.codehaus.classworlds.RealmClassLoader@c79809
BUILD SUCCESSFUL
Total time: 871 milliseconds


}



wibbo wrote:
> 
> Hello,
> 
> I'm struggeling with some problems using the Maven ant tasks in the CI
> environment with IBM Jazz. There are some ant tasks for IBM Jazz which
> are handling the connection between the build engine and the Jazz
> server. These Jazz ant tasks are working well as long as I haven't
> used the Maven ant task in the build script. One of the Jazz guys
> analyzed the problem as follows:
> 
> [quote]
> I was able to get some understanding of this problem.  Maven is
> switching out the context class loader on the main Ant thread when
> their task is invoked.   Before the Maven task runs when everything
> works properly...the main ant thread has a class loader of...
> 
> classLoader    Launcher$AppClassLoader  (id=113)
> sun.misc.Launcher$AppClassLoader@92e78c
> 
> After the Maven task runs the class loader is now...
> 
> classLoader    RealmClassLoader  (id=166)
> org.codehaus.classworlds.RealmClassLoader@1685e30
> 
> EMF can no longer find the appropriate factory as it delegates to the
> class loader to find the EMF package.  The NPE is then thrown as it
> attempts to use the null factory to get the item type in
> WebServicesSAXXHandler while marshalling the request to the server.  I
> hacked into our task a trap of the class loader before the Maven call
> and then set it back the next time our task executed.  Everything
> worked fine again.  It seems ridiculous that Maven is switching the
> class loader for the main ant thread when their task executes...at the
> very least if this insanity is necessary they should be switching it
> back.
> 
> It appears you can work around this problem by making your pom call
> into Maven before you call any of our ant tasks.  We then appear to
> get initially loaded into their class loader correctly and everything
> works ok.
> [/quote]
> 
> Why is the Maven ant task switching the class loader for the main ant
> thread? Is this a bug or works as designed?
> 
> Thanks for your feedback!
> 
> Regards,
> Thomas
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Using-Maven-Ant-Tasks-in-a-CI-Environment-with-IBM-Jazz-tp16556859s177p16568639.html
Sent from the Maven - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Using Maven Ant Tasks in a CI Environment with IBM Jazz

Posted by Hervé BOUTEMY <he...@free.fr>.
Le mardi 08 avril 2008, Jason van Zyl a écrit :
> Whatever operations are performed on our side that switches the
> classloader should switch it back.
>
> The analysis below doesn't really help us identify where this is
> happening, but Herve can probably take a look. It might be in the task
> code, or in Maven itself.
the switch is done in 
org.codehaus.plexus.org.codehaus.plexus#initializeClassWorlds(), called by 
org.codehaus.plexus.embed#start( ClassWorld )
The API does change the classloader without storing the previous one, and 
there is no API to switch it back.

For Maven Ant Tasks, it should be easy to fix the problem: please open a Jira 
issue, and I'll fix it before Maven Ant Tasks 2.0.9 which should be released 
in a week or 2

AFAIK, the problem exists in embedder too, or I missed the code in embedder 
that switches the classloader back...

Hervé

>
> On 7-Apr-08, at 11:22 PM, Thomas Tardy wrote:
> > Hello,
> >
> > I'm struggeling with some problems using the Maven ant tasks in the CI
> > environment with IBM Jazz. There are some ant tasks for IBM Jazz which
> > are handling the connection between the build engine and the Jazz
> > server. These Jazz ant tasks are working well as long as I haven't
> > used the Maven ant task in the build script. One of the Jazz guys
> > analyzed the problem as follows:
> >
> > [quote]
> > I was able to get some understanding of this problem.  Maven is
> > switching out the context class loader on the main Ant thread when
> > their task is invoked.   Before the Maven task runs when everything
> > works properly...the main ant thread has a class loader of...
> >
> > classLoader    Launcher$AppClassLoader  (id=113)
> > sun.misc.Launcher$AppClassLoader@92e78c
> >
> > After the Maven task runs the class loader is now...
> >
> > classLoader    RealmClassLoader  (id=166)
> > org.codehaus.classworlds.RealmClassLoader@1685e30
> >
> > EMF can no longer find the appropriate factory as it delegates to the
> > class loader to find the EMF package.  The NPE is then thrown as it
> > attempts to use the null factory to get the item type in
> > WebServicesSAXXHandler while marshalling the request to the server.  I
> > hacked into our task a trap of the class loader before the Maven call
> > and then set it back the next time our task executed.  Everything
> > worked fine again.  It seems ridiculous that Maven is switching the
> > class loader for the main ant thread when their task executes...at the
> > very least if this insanity is necessary they should be switching it
> > back.
> >
> > It appears you can work around this problem by making your pom call
> > into Maven before you call any of our ant tasks.  We then appear to
> > get initially loaded into their class loader correctly and everything
> > works ok.
> > [/quote]
> >
> > Why is the Maven ant task switching the class loader for the main ant
> > thread? Is this a bug or works as designed?
> >
> > Thanks for your feedback!
> >
> > Regards,
> > Thomas
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Using Maven Ant Tasks in a CI Environment with IBM Jazz

Posted by Jason van Zyl <ja...@maven.org>.
Whatever operations are performed on our side that switches the  
classloader should switch it back.

The analysis below doesn't really help us identify where this is  
happening, but Herve can probably take a look. It might be in the task  
code, or in Maven itself.

On 7-Apr-08, at 11:22 PM, Thomas Tardy wrote:
> Hello,
>
> I'm struggeling with some problems using the Maven ant tasks in the CI
> environment with IBM Jazz. There are some ant tasks for IBM Jazz which
> are handling the connection between the build engine and the Jazz
> server. These Jazz ant tasks are working well as long as I haven't
> used the Maven ant task in the build script. One of the Jazz guys
> analyzed the problem as follows:
>
> [quote]
> I was able to get some understanding of this problem.  Maven is
> switching out the context class loader on the main Ant thread when
> their task is invoked.   Before the Maven task runs when everything
> works properly...the main ant thread has a class loader of...
>
> classLoader    Launcher$AppClassLoader  (id=113)
> sun.misc.Launcher$AppClassLoader@92e78c
>
> After the Maven task runs the class loader is now...
>
> classLoader    RealmClassLoader  (id=166)
> org.codehaus.classworlds.RealmClassLoader@1685e30
>
> EMF can no longer find the appropriate factory as it delegates to the
> class loader to find the EMF package.  The NPE is then thrown as it
> attempts to use the null factory to get the item type in
> WebServicesSAXXHandler while marshalling the request to the server.  I
> hacked into our task a trap of the class loader before the Maven call
> and then set it back the next time our task executed.  Everything
> worked fine again.  It seems ridiculous that Maven is switching the
> class loader for the main ant thread when their task executes...at the
> very least if this insanity is necessary they should be switching it
> back.
>
> It appears you can work around this problem by making your pom call
> into Maven before you call any of our ant tasks.  We then appear to
> get initially loaded into their class loader correctly and everything
> works ok.
> [/quote]
>
> Why is the Maven ant task switching the class loader for the main ant
> thread? Is this a bug or works as designed?
>
> Thanks for your feedback!
>
> Regards,
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

-- Jacques Ellul, The Technological Society 




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org