Re: different versions of jars within EAR/WAR/EJB module

[Stephen Connolly]

another solution could be to use the maven-shade-plugin to rename the  
packages of dependencies so that you no longer have the version  
conflict...

for example if war depends on both A and B and A depends on asm:2 and  
B depends on asm:3 (see kohsuke's blog for a rant on asm and backward  
non compatibility) you would use maven-shade-plugin to relocate eg asm: 
2 from its current package to another, while rewriting A to use the  
new location, thereby removing the version conflict (it is not nice to  
have to do this, but sometimes necessary)

Sent from my [rhymes with tryPod] ;-)

On 21 Feb 2010, at 20:03, "Stephen Davidson"  
<stephen.david...@etcc.com> wrote:

Yes & no.

Keep in mind, in general you have multiple classloaders running when
deploying an Ear (for JBoss, you have to set its classloading policy  
to
STRICT).

The Jars will have their own classloader, with its own (isolated
classpath), same with the WARs and EAR.  Jars & Wars will both have a
dependency on the EAR classloader, and inherit anything the EAR knows
about.  So, anything declared in the EAR's Lib directory will be
globally available.  But in the case of Jars and Wars, especially when
they and their dependencies are in the EAR Root directory (EJB Jars,
anyone?), you have to specifically list the jars they depend on in the
MANIFEST Class-path entry.  Using this mechanism, one can safely use
different versions of a library jar in the same Ear (just keep them  
out
of the EAR/lib directory) for different Jars & Wars.  It may take some
experimenting to "fine tune" stuff, as well as some additional  
research.

-Steve


-----Original Message-----
From: Karsten Ohme [mailto:k...@mms-dresden.de]
Sent: Sunday, February 21, 2010 1:54 PM
To: users@openejb.apache.org
Subject: Re: different versions of jars within EAR/WAR/EJB module

Am 21.02.2010 20:27, schrieb Stephen Davidson:
Hi Karsten.

I also forgot to mention;

           <!--  Make the test class available for deployment -->
           <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-jar-plugin</artifactId>
               <version>2.2</version>
               <configuration>
                   <archive>
                       <manifest>
                           <addClasspath>true</addClasspath>
                       </manifest>
                   </archive>
               </configuration>
           </plugin>

This will allow your jars to use their version specific dependencies.
If you are deploying your test jars as well, you will need to set the
Executions section of the plugin.


But this does not affect the class loader, right? So any class loaded
first/last will be taken?

Regards,
Karsten
-Steve

-----Original Message-----
From: Karsten Ohme [mailto:k...@mms-dresden.de]
Sent: Sunday, February 21, 2010 12:26 PM
To: users@openejb.apache.org
Subject: Re: different versions of jars within EAR/WAR/EJB module

Am 21.02.2010 19:15, schrieb Karsten Ohme:

I had the idea that for the dependency conflicts the dependency
overview
of the super pom can help. Usually Maven plugins have support for
this.

For the convergence of used versions the site report of maven can
help,
e.g.

http://microlog.sourceforge.net/site/dependency-convergence.html

Hi Stephen,

but how have you found out, which libraries are used by sub  
libraries
and solved this?

E:g I have Foo.jar using commons-lang-2.3 and Bar.jar

commons-lang-2.4.

Now I only want to have one one the commons-lang. One way is to  
strip
away the version so an already used one is overwritten, but I'm not

sure

if this always works if the API has changed.

Maybe there is some version aware class loader out there which can

load

from class information the right one.

Regards,
Karsten
Am 21.02.2010 18:36, schrieb Stephen Davidson:


Hi Karsten.

I had this problem as well, especially my project uses multiple
wars.

I

researched "skinny wars", and found a solution.  In a nutshell, you

have

jars & wars declare all shared dependencies (such as
commons-logging,

or

whatever third-party library has this as its dependency) with scope
"provided".  You can do this by default be declaring your shared
dependencies at the parent pom level.
Then, in the EAR's pom, I redeclared the dependency, without the
"provided" scope.  The only annoying thing was when I had to
automatically provide some jars on a EAR wide level.  I had to add

the

following section;
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<!-- configuring the ear plugin -->
<configuration>
<!-- (one for each jar to had to have its classes automatically
available, dependency MUST be explicitly declared in the pom's
dependency section) -->
 <jarModule>
   <groupId>groupId</groupId>
   <artifactId>shared</artifactId>
   <bundleDir>lib</bundleDir>
 </jarModule>
</configuration>
<plugin>

Regards,
Steve

-----Original Message-----
From: Karsten Ohme [mailto:k...@mms-dresden.de]
Sent: Sunday, February 21, 2010 11:16 AM
To: users@openejb.apache.org
Subject: different versions of jars within EAR/WAR/EJB module

Hi,

I have the following problem:

I'm using different utility libraries which are using also  
different

versions of e.g. Apache-commons libraries. Now some libraries are

used

in different versions. So, I have possibly some default library

versions

in the application server and some library versions in my ear and
the
ear can also include different library versions.
Which library wins? Until now somehow this always worked, but now I

had

the problem with different versions. I received strange exceptions

while

using different versions together.

How can this problem be solved? Do I have to exclude in my Maven
configuration all duplicates manually?

Regards,
Karsten










--
Karsten Ohme
T-Systems Multimedia Solutions GmbH
Portal Technologies, Applications & Appliances
Hausanschrift: Riesaer Strasse 5, 01129 Dresden
Postanschrift: Postfach 10 02 24, 01072 Dresden
Telefon: +49 351 28 20 - 2123
Fax: +49 171 351 28 20 - 5116
E-Mail: karsten.o...@t-systems.com