Skip to main content

mvn classpath:hell

Posted by jjviana on December 14, 2010 at 10:12 AM PST

Apache maven is supposed to solve the classpath hell; or so I´ve been told...

Started using maven 2 in a multi-pom project. One of the requirements is to be able to deploy EAR files to Weblogic.

After looking around it seemed like the most stable way of doing this with maven and Weblogic 10.x is to use the Weblogic Ant task. Not ideal since we are migrating away from Ant, but still okay.

So I happily added the maven antrun plugin to my pom.xml file:


                 <path id="wlappc.classpath">
                <fileset file="${wlFullClient}" />

            <taskdef name="wldeploy"
            classpathref="wlappc.classpath" />
         <wldeploy action="deploy" verbose="true" debug="true"        
           upload="true" name="Myapp" source="myservice-ear-1.0-SNAPSHOT.ear"
           user="${deployUser}" password="${deployPassword}" adminurl="${deployURL}" targets="${deployTargets}" />


Great! Now I can easily deploy my ear file before the integration tests are run.

But now, after all tests are run and Maven then tries to deploy the generated artifact to the remote repository, it fails with the misterious error:

[INFO] ------------------------------------------------------------------------
[INFO] Error deploying artifact: Failed to transfer file: Return code is: 401

After a few hours of debugging the repository user permissions and the repository installation itself (http error 401 is a permission denied error after all) I was almost giving up hope when it occurred to me to test disabling the antrun plugin execution. Suddently the repository deployment started working again.

It turns our there is something in wlfullclient.jar (the weblogic admin client used by the ant task) that is messing up with the maven deployment plugin. Since there is no way to isolate the classpath between the plugins I had to choose to either deploy to the integration application server or to deploy to the remote repository. I ended up choosing (for now) disabling the remote repository deployment for the EAR artifact:



This is hardly an appropriate solution, as now I have to manually manage the copy of these files to the production system.

For a build system that is supposed to get rid of the classpath hell, Maven is turning out to be for me a classpath devil itself (that is not my first classpath problem with Maven ).


Related Topics >>


can someone help me on how to profile an application running ...

can someone help me on how to profile an application running on Oracle Application server 10g a JDK 1.5 with Visual VM

mvn classpath:hell

I use the antrun plugin in one of my projects and it does not give troubles. So there must be another evil interaction.
In order to mitigate your workaround, do you have considered to use profiles? You can have the default profile e.g. that deploys locally and a specific profile that deploys remotely, alternatively excluding the offending stuff. In this way you can do both things, even though not at the same time, without constantly changing the POM.
PS There's nothing necessarily wrong in using Ant with Maven, if Ant is confined within a single goal - in other words, it's not a strange hybrid because the build system is really still the Maven workflow, and it's not "polluted" by Ant. With this usage, Ant is just a script interpreter, much like you were using a Maven plugin written in Groovy or such.

mvn classpath:hell

Interesting idea about using profiles. I will give it a try.
The problem is not with the antrun plugin itself . Rigorous investigation has proven that it is related to the wlfullclient jar file being loaded in the JVM maven is running in.
After executing any antrun target that uses the task defined in this file, all subsequent modules in the reactor fail to deploy with the HTTP 401 error.
It would not happen is maven kept each plugin on its own classloader. As it is seems like all plugins execute under the same classloader, which given the distributed nature of the plugin providers is bound to cause this type of clash.

mvn classpath:hell

Further testing shows it seems to have nothing to do with the wlfullclient.jar - just using the antrun plugin in a project seems enough to trigger the problem.
Tested with maven 2.2.1 . Will try 3.0 now.

mvn classpath:hell

It does happen with 3.0 also....
But it looks like it really depends on the loading of some classes in wlfullclient.jar. Argh....

Maven: the classpath devil

Goodness; try looks like it supports WebLogic 10+.

Maven: the classpath devil

I considered Cargo, but it only supports local deployment to Weblogic, and in this customer we need remote deployment.
There is also a Weblogic maven plugin, but its quite old and reported to be unstable with 10.x.

Maven: the classpath devil

It shouldn't be difficult to extend Cargo to support remote deployment to WebLogic - please submit a patch if you really need that functionality. :) The codebase is really easy to understand and extend.
I submitted a patch to the Cargo team earlier this year to allow configuring JNDI properties in a Jetty deployment via Maven. They took the patch and it was in the trunk within a few hours of submitting it.