tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: different versions of jars within EAR/WAR/EJB module
Date Sun, 21 Feb 2010 21:14:53 GMT
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.davidson@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:koh@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:koh@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:koh@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.ohme@t-systems.com
>

Mime
View raw message