Maven 2.x WAR Plugin

Referenced projects' artifacts naming scheme behaves differently when ran from reactor

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.0
  • Component/s: None
  • Labels:
    None
  • Environment:
    maven-war-plugin versions 2.0-beta-1 and 2.0-beta-2
  • Number of attachments :
    1

Description

When running mvn install from a war packaged project, the referenced projects' artifacts are bundled into the WEB-INF/lib directory with the following naming scheme ${groupId}-${artifactId}-${version}.jar, but when running mvn install as part of the reactor, the referenced projects' artifacts are bundled into the WEB-INF/lib directory with the following naming scheme ${pom.build.finalName}.jar

The naming scheme should be the same in the two situations for the sake of consistency, but also to avoid the disturbing (for the end user) situation where you end up having the same dependencies present twice with different names.

Issue Links

This issue is related to:
MNG-2045 Maven can't compile against sibling test-jar dependency in multiproject (Test Attached) Major Closed
MNG-4248 CLONE -Maven can't compile against sibling test-jar dependency in multiproject (Test Attached) Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Shinobu Kawai added a comment -

It would be great if the war plugin had a bundleFileName property like the ear plugin.

Show
Shinobu Kawai added a comment - It would be great if the war plugin had a bundleFileName property like the ear plugin.
Hide
Permalink
Brian Fox added a comment -

This is causing us some trouble now too. We need to load some jars from jasper and if we don't know for sure what the classpath is, we're hosed.

Show
Brian Fox added a comment - This is causing us some trouble now too. We need to load some jars from jasper and if we don't know for sure what the classpath is, we're hosed.
Hide
Permalink
Maria Odea Ching added a comment -

I cannot seem to reproduce the problem. Could anyone submit their sample test case? Thanks

Show
Maria Odea Ching added a comment - I cannot seem to reproduce the problem. Could anyone submit their sample test case? Thanks
Hide
Permalink
Brian Fox added a comment -

I can try to create one, but I'm leaving for a trip today. In general the project needs to look like this:
Parent
Project A (Jar)
Project B (War)

When you run from Project B (assuming A is already installed) you get projecta-1.0.jar, if you run from the parent, you get projecta.jar.

Show
Brian Fox added a comment - I can try to create one, but I'm leaving for a trip today. In general the project needs to look like this: Parent Project A (Jar) Project B (War) When you run from Project B (assuming A is already installed) you get projecta-1.0.jar, if you run from the parent, you get projecta.jar.
Hide
Permalink
Maria Odea Ching added a comment -

Okay, thanks for the comment Brian

Show
Maria Odea Ching added a comment - Okay, thanks for the comment Brian
Hide
Permalink
Maria Odea Ching added a comment -

The attached patch file changes the file name of the dependency jar file to the correct format. In the scenario described above, when mvn install or mvn package is executed from the reactor, project a's file name is in the
${artifactName}-${version}.jar format instead of ${pom.build.finalName}.jar format when included in the WEB-INF/lib directory of project b.

Show
Maria Odea Ching added a comment - The attached patch file changes the file name of the dependency jar file to the correct format. In the scenario described above, when mvn install or mvn package is executed from the reactor, project a's file name is in the ${artifactName}-${version}.jar format instead of ${pom.build.finalName}.jar format when included in the WEB-INF/lib directory of project b.
Hide
Permalink
Edwin Punzalan added a comment -

Patch applied with renamed method name. Thanks.

Show
Edwin Punzalan added a comment - Patch applied with renamed method name. Thanks.

People

Vote (4)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
10h
Original Estimate - 10 hours
Remaining:
2h
Time Spent - 8 hours Remaining Estimate - 2 hours
Logged:
8h
Time Spent - 8 hours Remaining Estimate - 2 hours
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.