Maven 2.x and 3.x Site Plugin

An API incompatibility was encountered while executing org.apache.maven.plugins:maven-site-plugin:3.1:site: java.lang.ExceptionInInitializerError: null

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Not A Bug
  • Affects Version/s: 3.1
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    Using Maven 3.0.4
  • Number of attachments :
    3

Description

After updating maven site version from 3.0 to 3.1, I get the following error when running mvn clean site on my project.

As far as I can see, the error come from :
Caused by: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:385)
... 61 more

Full log is attached.
I added my parent pom.xml file and the pom.xml file for the first module (which fails).

Hope this help.
David.

  1. Text File
    mavensite3.log
    04/May/12 2:23 AM
    169 kB
    David Pilato
  2. XML File
    pom.xml
    04/May/12 2:23 AM
    1 kB
    David Pilato
  3. XML File
    pom.xml
    04/May/12 2:23 AM
    40 kB
    David Pilato

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dennis Lundberg added a comment -

I see from the log that this is built on Jenkins running on JBoss.
Do you get the same error when you run this build locally?
The reason I ask is because JBoss has has several problems relating to commons-logging.

Show
Dennis Lundberg added a comment - I see from the log that this is built on Jenkins running on JBoss. Do you get the same error when you run this build locally? The reason I ask is because JBoss has has several problems relating to commons-logging.
Hide
Permalink
Dennis Lundberg added a comment -

When I run 'mvn clean verify site' on banaco-jmx, with the parent POM placed in the directory above, I get a successful build.

Show
Dennis Lundberg added a comment - When I run 'mvn clean verify site' on banaco-jmx, with the parent POM placed in the directory above, I get a successful build.
Hide
Permalink
David Pilato added a comment -

Perfectly right. I launched it from Jenkins in à Jboss 4 container.
I will test it on Monday.

BTW, when I switch back to site plugin 3.0, it's running fine again.

I will let you know.

Thanks
David

Show
David Pilato added a comment - Perfectly right. I launched it from Jenkins in à Jboss 4 container. I will test it on Monday. BTW, when I switch back to site plugin 3.0, it's running fine again. I will let you know. Thanks David
Hide
Permalink
David Pilato added a comment -

Hi Dennis,

I tested a 'mvn clean verify site' on banaco-jmx with maven site plugin 3.0 and 3.1 and it was successful.

So, does it mean that maven site plugin 3.1 can not be launched from a Jboss 4.x container ? But 3.0 was able to do it ?
That's not a big issue for me as I can (and I should) migrate my Jenkins instance outside any JBoss container.

Is it your recommandation or is there any workaround ?

Thanks

Show
David Pilato added a comment - Hi Dennis, I tested a 'mvn clean verify site' on banaco-jmx with maven site plugin 3.0 and 3.1 and it was successful. So, does it mean that maven site plugin 3.1 can not be launched from a Jboss 4.x container ? But 3.0 was able to do it ? That's not a big issue for me as I can (and I should) migrate my Jenkins instance outside any JBoss container. Is it your recommandation or is there any workaround ? Thanks
Hide
Permalink
Dennis Lundberg added a comment -

Hi David,

Because of the bad decision by JBoss to include their own (slightly modified) copy of commons-logging in JBoss 4, adding newer versions of commons-logging in an application deployed to a JBoss 4 instance can lead to problems like this. The reason is that you end up with two incompatible versions of commons-logging (1.0.x and 1.1.x) in your applications classpath.

There are two possible workarounds:

1. Use a newer version of JBoss that doesn't bundle commons-logging in a classloader that is shared with the installed applications. Sorry, but I don't know which version.

2. Try to replace the version of commons-logging that is included in JBoss. I haven't tried this but it might work. Use version 1.1.1 if possible.

Show
Dennis Lundberg added a comment - Hi David, Because of the bad decision by JBoss to include their own (slightly modified) copy of commons-logging in JBoss 4, adding newer versions of commons-logging in an application deployed to a JBoss 4 instance can lead to problems like this. The reason is that you end up with two incompatible versions of commons-logging (1.0.x and 1.1.x) in your applications classpath. There are two possible workarounds: 1. Use a newer version of JBoss that doesn't bundle commons-logging in a classloader that is shared with the installed applications. Sorry, but I don't know which version. 2. Try to replace the version of commons-logging that is included in JBoss. I haven't tried this but it might work. Use version 1.1.1 if possible.

People

  • Assignee:
    Unassigned
    Reporter:
    David Pilato
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: