I have more information on this. The dependencies of war A as defined by
its deployed pom are:
<dependencies>
<dependency>
<groupId>com.issinc.cdf.server</groupId>
<artifactId>cdf-rest-services</artifactId>
<version>${project.version}</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.issinc.cdf.sdk</groupId>
<artifactId>cdf-internal</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<scope>runtime</scope>
</dependency>
</dependencies>
The first two are internal war A's project/build, the 3rd is obviously an
external dependency. All of these have several transitive dependencies.
So my question is...how is this supposed to work in Maven? Currently in
the derivative project B Maven is not applying its dependencyManagement
rules when it uses war A as an overlay. So my questions is why, is that by
design and what's the rationale for that? Or are we doing something wrong
here and that is causing the behavior we are seeing? For instance I'm not
clear why all these dependencies are scoped runtime. In that war's build
there is no code being compiled...it is just assembling jars into a war so
compile or runtime scopes work fine but does runtime cause this undesired
effect?
Just trying to fully understand how Maven handles wars as overlays from
external projects (A) regarding dependencyManagement in project B.
-Dave
On Tue, Mar 11, 2014 at 2:09 PM, David Hoffer <[email protected]> wrote:
> In my project I'm dependent on war A that is created by a different group
> so I have no control over the versions of jars in that war. My project
> uses that war as an overlay (e.g. as my starting point) and I'm creating
> war B, however my project has different version of some of the jars in that
> war. I want to use my jar versions and not the ones in war A.
>
> If I do nothing and build I get both jar versions in the war (jars that
> were already in A and jars that are in my project).
>
> I would have thought that dependencyManagement should take care of this.
> E.g. if I specify version g:a:1.0.2 in my project and the overlay has
> g:a:1.0.1
> I want to use g:a:1.0.2 and not g:a:1.0.1. However it seems that wars do
> not honor dependencyManagement configuration, rather it seems wars are
> treated as 'zip' files with Maven not knowing about their contents? At
> least as far as dependencies are concerned?
>
> I found that I can use
> <dependentWarExcludes>WEB-INF/lib/something.*</dependentWarExcludes>
> to exclude jars but that means that I have to manually keep this in sync
> with what is already done by dependencyManagement.
>
> -Dave
>
>
> On Tue, Mar 11, 2014 at 1:53 PM, Wayne Fay <[email protected]> wrote:
>
>> > I have a war overlay I want to use in my war but need to specify a
>> > different jar version in my final war or remove some unused jars.
>> > Shouldn't dependencyManagement work for both of these cases? What's
>> the
>> > approach to handle these two cases?
>>
>> To be clear, are you saying that you want to compile & test with
>> g:a:1.0.1 but then package g:a:1.0.2 in your WAR? And you want to
>> build with g1:a1:1.0.1 and g2:a2:1.0.1 but then keep them out of the
>> WAR when you package it?
>>
>> If so, I don't understand these use cases, please explain things more.
>> If not, please explain with more concrete details/examples -- tell us
>> what you have right now vs what you want.
>>
>> Wayne
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
