jars with differents versions can be in WEB-INF/lib with war as dependencies

i guess this is a problem. =) maybe you can add an warExclude entry for the unneeded log4j

s/an/a/g

No agree with this.
IMO the content of WEB-INF/lib must populated with the dependencies section of the pom.
With this you are sure to have the same classpath content when you made : compile, test and package.
The WEB-LIB/lib of merged wars must be exclude by default.

Olivier

Other tests made which causes some troubles.
My pom has a dependency to a SNAPSHOT dependecy (in example called foo).
An included war dependency has the same dependency.
The deployed war dependency contains a timestamped version of this (foo-64456-1.jar).
On my machine I have a SNAPSHOT of this (foo-SNAPSHOT.jar) due to an install which include fixes..
When I package my war, the WEB-LIB contains :
foo-64456-1.jar
foo-SNAPSHOT.jar
This cause real trouble and long time debugging to find the trouble because the timestamped one win in the appserver.
The ones declares in the pom (and transitive ones) doesn't win.
Junit passes but not the application deployed in the appserver.
This breaks the maven benefit's because you're really sure about your dependencies.
IMO this issue must be set to blocker
Olivier

well, this shouldn't happen for two reasons:
a) it shouldn't duplicate
b) wars shouldn't pass on dependencies (you should get the war in web-inf/lib)

confirmed regression since beta-2

ok, it took me a bit to realise this was because the war is being unpacked.

You should use warExclude for now.

This is a much bigger change that will require excluding WEB-INF/lib and pulling in the dependencies from the dependant WAR using the maven artifact mechanism. I don't think it's a good idea to exclude the WEB-INF/lib by default without that, though.

Why not using Set artifacts = project.getArtifacts();
And get dependencies of the artifacts with type war.
But I think in case of war type transitive dependencies are not resolved.
I don't know exactly but I think there is an issue in MNG.
With all jars in WEB-INF will come from poms dependencies declaration.
IMHO, it's the best and cleaner solution ?
With this I'm sure to have the same classpath when I try a junit and when I build my war.

–
Olivier

I believe this is a blocker too. In my (automatically generated) WEB-INF/lib dir I have duplicate jar files with different version which are causing me application errors. I would expect that jars on the WEB-INF/lib directory be the same as the ones generated with eclipse:eclipse plugin, but no.

Even those dependencies that I exclude in the pom.xml file are included in the war, so you must understand that it is breaking havoc for me. This makes maven unusable for war projects, at least for me.

We are currently doing our own repackaging that I developed prior to MWAR support of it. This issue here is a blocker for us to move over to using the MWAR repackaging. I'd much rather use the standard because my method also doesn't pick up the dependencies...I have to make sure they are duplicated in the repackaging war.

Workaround:

Using latest version in svn you can do

<dependentWarExcludes>WEB-INF/lib/**</dependentWarExcludes>

to avoid the jars from the war

I also discovered this problem today in a production environment.

Thanks to the various exclude mechanisms this is easy to fix. But since this a fairly common scenario, we should really try to implement an automated handling.

First of all, this problem exists only if one WAR is depending on another WAR, am i right? Is there any other scenario not involving two dependent WAR files?

Assuming this, i think the problem is that - since dependencies of WAR files currently are not transitive - we are stuck with the jars comming from the wars WEB-INF/lib.
On the other hand, if the dependent WAR file has any dependencies defined in the POM and those would be treated as usual transitive dependencies (keep in mind that this is only valid when a WAR is currently beeing built), we may simply forget about the libs from the dependent WAR and the conflict could be solved by the standard maven mechanism.

This also has no negative effect for manually imported WARs (not beeing built with maven). Those WARs simply have no dependencies specified in the POM, so all the libs would be used for overlaying without any exclusion.

This is a huge showstopper for us. We have a number of WAR projects that include 1-5 other war projects as dependencies. We are getting many many duplicate jars with conflicting version numbers and with unpredictable results. It would be great if the war overlay would allow us to exclude the lib directory and instead use the transitive dependencies that were originally defined in the war that is being overlayed. This would also require all dependencies from all overlayed wars to be reconciled between themselves as well as within the containing artifact. This would also tranfer down the chain of depedencies so that all transitive dependencies would be resolved correctly and at one time.

sorry, wrong issue.

Scott, we would like to have this as well but this needs a heavy change in the maven core. I think it's been scheduled for 2.1 but I'm not sure.

What I would like to implement for this is a WEB-INF/lib postpackagingtask that will scan WEB-INF/lib and will report any duplicate dependencies that is found. A strict mode flag (set to false by default) can fail the build if a duplicate is found.

I hope this will be a first solution till we have the ability to resolve the war's transitive dependencies.

Brian, does that help? Any suggestion?

We fight with this problem also. Currently we use warExcludes and redeclare all the deps. The best solution though might be to introduce a war-client.jar similar to an ejb-client. The war-client.jar would contain all classes and - as attached artifact - it would provide the transitive deps. With such an artifact you could use a dependent war as overlay and exclude anything from WEB-INF/lib and WEB-INF/classes and declare the war-client as additional dep. Since the war-client is a jar, you'll inherit then all the transitive deps.

Having the ability to deploy the server-side code is actually a good idea and I used it in most projects with the build-helper plugin. I'd like to make this a feature of the war plugin.

Since we have many watchers over here, I'm open to suggestions with regard to the classifier's name + parameter name (war-client does not sound intuitive to me but I guess you used that for illustration purposes)

My project team gets hit by this at least twice a week. But shouldn't MWAR-60 have fixed this? It's caused by developer workspaces containing a different version in src/main/webapp/WEB-INF/lib but Maven pulling down a different version in the build process. If we could just exclude WEB-INF/classes and WEB-INF/lib, this problem would be history.

Huge show stopper for us. We extend a 3rd party product and the current state of the WAR plugin forces us to redeclare > 100 3rd party dependencies which is practically impossible.

Brett - IMHO you described a proper solution (ignore/empty out WEB-INF/lib, resolve all deps only using project descriptors). Is this really that tricky to implement (sounds like loads of efforts) - especially considering that this issue is years old - what about current versions of maven ?

Regarding WEB-INF/lib: there's no point in using a tool like Maven for dependency management and then rely on plain old files (like ant) for web applications - this is definitely not following the "declaration" concept of Maven.

Good news.

I looks to me as I was able to work around the issue. After a long-day debug session in maven I figured out how to enable the inclusion of transitive dependencies on WAR dependencies.

I changed apache-maven-2.0.9/lib/maven-2.0.9-uber.jar/META-INF/plexus/components.xml which obviously configures the plexus container and its components.

<component>
<role>org.apache.maven.artifact.handler.ArtifactHandler</role>
<role-hint>war</role-hint>
<implementation>org.apache.maven.artifact.handler.DefaultArtifactHandler</implementation>
<configuration>
<type>war</type>
<includesDependencies>false</includesDependencies>
<language>java</language>
<addedToClasspath>false</addedToClasspath>
</configuration>
</component>

Changing <includeDependendies/> from true to false for WAR artifacts causes Maven to not consider dependencies from WAR artifacts to be already included in the WAR artifact itself. Instead they are properly resolved including a proper dependency resolution. I'll attach an sample overlay project so that this is reproducible for others.

Using the following section in the overlay build itself leads to an empty WEB-INF/lib for the overlay.

<build>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<dependentWarExcludes>
WEB-INF/lib/*.jar</dependentWarExcludes>
</configuration>
</plugin>
</plugins>
</build>

This in combination with the above <includesDependencies/> change means: an overlay's WEB-INF/lib is populated with all transitive dependencies from scratch. Be aware that I only exclude JAR dependencies here for now.

Does that make sense ? Feedback appreciated. Personally I would consider this to be the expected default behaviour (compatibility-issues aside) and would love to see that behaviour in a newer release (either default behaviour or a configuration option somewhere). Right now everyone here has to apply these settings manually in their maven installation which is ok for now (but not in the long term).

Someone can give feedback on the consequences and side-effects of the above change ? Do we break something here in this respect in other places ?

Regards Alex

MWAR-33-example.zip shows the initial issue. MWAR-33-workaround.zip describes the workaround.

Alex, the workaround described above works. Simply exclude WEB-INF/lib and WEB-INF/classes from the war building. However, I concede this is a hack and expected the plugin to know better.

Paul

I agree with you that this could be more under control of the war plugin. However it looks (at least to me) like the handling (resolution) of artifacts of certain types (WAR in our case here) is fundamentally settled in the plexus configuration and artifact resolution. The war plugin (from what I've seen during my debug session) just gets the resolved artifacts presented without being able to control that process. Therefore is "just receives" the resolved dependencies based on the WAR artifact type which does (based on the plexus configuration) not include transitive dependencies.

If the WAR plugin should be configurable in this respect I guess it's more difficult as there needs to be some communication between WAR plugin and dependency resolution (which does not exist as far as I know).

I think the actual question first is: should the dependency resolution really be different for WARs compared to JARs ? Does a WAR dependency justify the dependency resolution mechanism to cut off transitive dependencies ? In the end both types of artifacts are quite similar - both are essentially java class artifacts (or libraries if you want) where the WAR artifact may include additional filesystem resources and libraries. The existence of libraries leads to a conflict here as the WAR bundle itself and maven "want" to take over control over dependencies in general. The current situation is: the WAR file wins and maven does not deal with transitive dependencies in favor of the WAR artifact. This leads to the conflict that "on-top" artifacts based on WAR files can't be handled by maven properly as there is some kind of processing gap in the dependency chain where maven is missing proper information about dependencies to properly deal with them.

This is why I personally do not really consider this to be a hack. I think the change would reflect a fundamental change in the behaviour of dealing with WAR artifacts. And it would not just be a local fix to the WAR plugin but a change which would straighten the dependency resolution in general for maven (and all affected plugins). I'm aware of that this is a quite severe change (e.g. what are the effects on other plugins dealing with WARs ?). But on the other hand I consider this issue being a bigger problem as well as Maven remains some kind of "incomplete" dependeny maangement solution for WAR projects.