War Overlays and Conflicting Jars

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

War Overlays and Conflicting Jars

Harper, Brad-2
Is there a way to detect when the dependencies of two war artifacts are
inconsistent with respect to packaged jar versions?

 

E.g. a war depends on artifact abc-1.0.0.jar. An overlay is performed
where an inconsistent dependency on abc-1.0.1.jar is also defined.

 

The resulting war will contain both jar files and, so far as I can tell,
the subsequent behavior is indeterminate.

 

Brad

Reply | Threaded
Open this post in threaded view
|

Re: War Overlays and Conflicting Jars

Nayan Hajratwala
mvn dependency:tree should let you see that there are 2 of the same  
jars, but it won't "alert" you.

A better solution might be to use a <dependencyManagement> section in  
the parent pom of both modules in which you specify the jar versions.  
That way you won't have the problem of using different versions in  
different modules.

---
Nayan Hajratwala
http://agileshrugged.com
http://twitter.com/nhajratw
734.658.6032

On May 11, 2009, at 3:55 PM, Harper, Brad wrote:

> Is there a way to detect when the dependencies of two war artifacts  
> are
> inconsistent with respect to packaged jar versions?
>
>
>
> E.g. a war depends on artifact abc-1.0.0.jar. An overlay is performed
> where an inconsistent dependency on abc-1.0.1.jar is also defined.
>
>
>
> The resulting war will contain both jar files and, so far as I can  
> tell,
> the subsequent behavior is indeterminate.
>
>
>
> Brad
>

Reply | Threaded
Open this post in threaded view
|

Re: War Overlays and Conflicting Jars

Mark Hobson
dependency:tree doesn't currently show overlaid war jars.  The war
overlay concept is conceptually outside of the normal dependency
mechanism, hence the possibility of ending up with two versions of the
same dependency.

Anyone aware of an issue about this?  The war plugin should really
fail the build, or at least warn, if the package war contains multiple
versions of the same jar.

Mark

2009/5/12 Nayan Hajratwala <[hidden email]>:

> mvn dependency:tree should let you see that there are 2 of the same jars,
> but it won't "alert" you.
>
> A better solution might be to use a <dependencyManagement> section in the
> parent pom of both modules in which you specify the jar versions. That way
> you won't have the problem of using different versions in different modules.
>
> ---
> Nayan Hajratwala
> http://agileshrugged.com
> http://twitter.com/nhajratw
> 734.658.6032
>
> On May 11, 2009, at 3:55 PM, Harper, Brad wrote:
>
>> Is there a way to detect when the dependencies of two war artifacts are
>> inconsistent with respect to packaged jar versions?
>>
>>
>>
>> E.g. a war depends on artifact abc-1.0.0.jar. An overlay is performed
>> where an inconsistent dependency on abc-1.0.1.jar is also defined.
>>
>>
>>
>> The resulting war will contain both jar files and, so far as I can tell,
>> the subsequent behavior is indeterminate.
>>
>>
>>
>> Brad
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: War Overlays and Conflicting Jars

Brad Harper


I was hoping to hear someone say that the war file should generate an error
or fail.

In our case, we have multiple versions of a general 'platform', each
represented by a war artifact. Derivative wars artifacts are built with
customizations and tailorings using a war overlay. When it becomes necessary
to fix or otherwise re-work a platform and re-release a corresponding
derivative, we need to exactly re-construct dependencies of the original
platform artifact [or risk including multiple versions] when building a new
one-off.

Unfortunately, the platform projects themselves are intermediate children of
a multi-module project and inherit from a <dependencyManagement> element
defined by that top-level [so that the latest version of a platform uses the
currently preferred versions of various dependencies.]

We must crack the war and meticulously re-create the dependencies of the
original platform when re-building. It would nice, at least, if a build
could systemically determine that a potential error has been introduced. On
the other hand, maybe we should re-think our use of <dependencyManagement>.

Thanks.

Brad


Mark Hobson wrote:

>
> dependency:tree doesn't currently show overlaid war jars.  The war
> overlay concept is conceptually outside of the normal dependency
> mechanism, hence the possibility of ending up with two versions of the
> same dependency.
>
> Anyone aware of an issue about this?  The war plugin should really
> fail the build, or at least warn, if the package war contains multiple
> versions of the same jar.
>
> Mark
>
> 2009/5/12 Nayan Hajratwala <[hidden email]>:
>> mvn dependency:tree should let you see that there are 2 of the same jars,
>> but it won't "alert" you.
>>
>> A better solution might be to use a <dependencyManagement> section in the
>> parent pom of both modules in which you specify the jar versions. That
>> way
>> you won't have the problem of using different versions in different
>> modules.
>>
>> ---
>> Nayan Hajratwala
>> http://agileshrugged.com
>> http://twitter.com/nhajratw
>> 734.658.6032
>>
>> On May 11, 2009, at 3:55 PM, Harper, Brad wrote:
>>
>>> Is there a way to detect when the dependencies of two war artifacts are
>>> inconsistent with respect to packaged jar versions?
>>>
>>>
>>>
>>> E.g. a war depends on artifact abc-1.0.0.jar. An overlay is performed
>>> where an inconsistent dependency on abc-1.0.1.jar is also defined.
>>>
>>>
>>>
>>> The resulting war will contain both jar files and, so far as I can tell,
>>> the subsequent behavior is indeterminate.
>>>
>>>
>>>
>>> Brad
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>

--
View this message in context: http://n2.nabble.com/War-Overlays-and-Conflicting-Jars-tp2867314p2871095.html
Sent from the maven users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: War Overlays and Conflicting Jars

Mark Hobson
2009/5/12 Brad Harper <[hidden email]>:

> I was hoping to hear someone say that the war file should generate an error
> or fail.
>
> In our case, we have multiple versions of a general 'platform', each
> represented by a war artifact. Derivative wars artifacts are built with
> customizations and tailorings using a war overlay. When it becomes necessary
> to fix or otherwise re-work a platform and re-release a corresponding
> derivative, we need to exactly re-construct dependencies of the original
> platform artifact [or risk including multiple versions] when building a new
> one-off.
>
> Unfortunately, the platform projects themselves are intermediate children of
> a multi-module project and inherit from a <dependencyManagement> element
> defined by that top-level [so that the latest version of a platform uses the
> currently preferred versions of various dependencies.]
>
> We must crack the war and meticulously re-create the dependencies of the
> original platform when re-building. It would nice, at least, if a build
> could systemically determine that a potential error has been introduced. On
> the other hand, maybe we should re-think our use of <dependencyManagement>.

Fancy raising an issue against the War Plugin to warn/error for this
situation, if there's not one there already?

Cheers,

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: War Overlays and Conflicting Jars

Jörg Schaible
In reply to this post by Harper, Brad-2
Harper, Brad wrote at Montag, 11. Mai 2009 21:55:

> Is there a way to detect when the dependencies of two war artifacts are
> inconsistent with respect to packaged jar versions?
>
>  
>
> E.g. a war depends on artifact abc-1.0.0.jar. An overlay is performed
> where an inconsistent dependency on abc-1.0.1.jar is also defined.
>
>  
>
> The resulting war will contain both jar files and, so far as I can tell,
> the subsequent behavior is indeterminate.

We avoid this by turning all war projects into projects with packaging jar
that creates a normal library out of the classes. The war is itself build
then with a classifier (webapp in our case). The jar plugin has been
configured to create the resulting jar in target/webapp/WEB-INF/lib while
the war is assembled in target/webapp. Therefore the war contains also the
local jar and resources. In case of an overlay we exclude then any stuff
from WEB-INF/lib and WEB-INF/classes and get the proper dependencies
declaring the jar and the webapp both as deps.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: War Overlays and Conflicting Jars

Harper, Brad-2
In reply to this post by Mark Hobson
I didn't see one, so I added one. Refer to
http://jira.codehaus.org/browse/MWAR-194.

Thanks.

Brad

-----Original Message-----
From: Mark Hobson [mailto:[hidden email]]
Sent: Wednesday, May 13, 2009 3:37 AM
To: Maven Users List
Subject: Re: War Overlays and Conflicting Jars

2009/5/12 Brad Harper <[hidden email]>:
> I was hoping to hear someone say that the war file should generate an
error
> or fail.
>
> In our case, we have multiple versions of a general 'platform', each
> represented by a war artifact. Derivative wars artifacts are built
with
> customizations and tailorings using a war overlay. When it becomes
necessary
> to fix or otherwise re-work a platform and re-release a corresponding
> derivative, we need to exactly re-construct dependencies of the
original
> platform artifact [or risk including multiple versions] when building
a new
> one-off.
>
> Unfortunately, the platform projects themselves are intermediate
children of
> a multi-module project and inherit from a <dependencyManagement>
element
> defined by that top-level [so that the latest version of a platform
uses the
> currently preferred versions of various dependencies.]
>
> We must crack the war and meticulously re-create the dependencies of
the
> original platform when re-building. It would nice, at least, if a
build
> could systemically determine that a potential error has been
introduced. On
> the other hand, maybe we should re-think our use of
<dependencyManagement>.

Fancy raising an issue against the War Plugin to warn/error for this
situation, if there's not one there already?

Cheers,

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: War Overlays and Conflicting Jars

Annies, Sebastian
In reply to this post by Harper, Brad-2
Hi Brad,

we had this issue too and used the following workaround (Works only if the overlay is never used as war itself):

In the war plugin we exclude packaging of the jars. So we got a skinny jar.

In the module building the actual war thatg is deployed to a container we depend the overlay with <type>war</type> and with <type>pom</type>. By doing so maven uses the whole dependency management stuff to resolve conflicts.

Best Regards,
Sebastian

-----Ursprüngliche Nachricht-----
Von: Harper, Brad [mailto:[hidden email]]
Gesendet: Montag, 11. Mai 2009 21:55
An: Maven Users List
Betreff: War Overlays and Conflicting Jars

Is there a way to detect when the dependencies of two war artifacts are
inconsistent with respect to packaged jar versions?

 

E.g. a war depends on artifact abc-1.0.0.jar. An overlay is performed
where an inconsistent dependency on abc-1.0.1.jar is also defined.

 

The resulting war will contain both jar files and, so far as I can tell,
the subsequent behavior is indeterminate.

 

Brad


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]