Maven 2.x WAR Plugin

Overridden artifact finalName ist ignored by the war plugin.

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Duplicate
  • Affects Version/s: 2.1-alpha-1
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    Maven 2.0.9, JDK 6, WinXP SP2
  • Number of attachments :
    1

Description

I have a multimodule project.
groupId: net.fckeditor

Parent ArtifactId: fckeditor-java
1. module ArtifactId: java-core; finalName "fckeditor-${artifactId}-${version}" though => e.g. fckeditor-java-core-2.4-SNAPSHOT
2. module ArtifactId: java-demo; finalName "fckeditor-${artifactId}-${version}" though

module one is a jar artifact, module 2 a war artifact which has a dependency on module 1.

the final WAR file contains all dependencies included the java-core but the jar name is not fckeditor-java-core-2.4-SNAPSHOT.jar but java-core-2.4-SNAPSHOT.jar

An example picture is attached and the project can be checked out at our trac and the SVN directly.

Issue Links

This issue is duplicated by:
MWAR-215 class file JAR inconsistency (archiveClasses and attachClasses options) Major Open
This issue relates to:
MWAR-211 Ability to rename a dependency's jar when putting it on the lib folder Major Open

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Michael Osipov added a comment - - edited

Correction:
module one is a jar artifact, module 2 a war artifact. The war depends on the jar.

Show
Michael Osipov added a comment - - edited Correction: module one is a jar artifact, module 2 a war artifact. The war depends on the jar.
Hide
Permalink
Tim Schwenk added a comment -

This also affects manifest creation for "skinny" WARs. That is, the maven-ear-plugin puts the artifact into the EAR using the specified finalName, but the maven-war-plugin uses the default artifact name when adding the dependency to the WAR's META-INF/MANIFEST.MF.

Steps to reproduce:

1. create a simple JAR project and define the finalName in the build section as: <finalName>${artifactId}</finalName>
2. create a simple WAR project and specify the JAR created in step one as a dependency and make it optional so that it isn't included in WEB-INF/lib.
3. in the WAR project, configure the maven-war-plugin to generate the manifest and add the classpath.
4. create an EAR project and define the WAR project created in step one as a web module.
5. 'mvn package' the EAR project and look at the META-INF/MANIFEST.MF generated for the WAR project.

I realize these are very rough directions, but I'm not permitted by my employer to share the project that I was building when I ran into the bug. If this is not clear enough, I could probably put together a minimal example project.

Also, I think this is a new bug, because switching back to 2.1-alpha-2 solved the problem for me.

Show
Tim Schwenk added a comment - This also affects manifest creation for "skinny" WARs. That is, the maven-ear-plugin puts the artifact into the EAR using the specified finalName, but the maven-war-plugin uses the default artifact name when adding the dependency to the WAR's META-INF/MANIFEST.MF. Steps to reproduce: 1. create a simple JAR project and define the finalName in the build section as: <finalName>${artifactId}</finalName> 2. create a simple WAR project and specify the JAR created in step one as a dependency and make it optional so that it isn't included in WEB-INF/lib. 3. in the WAR project, configure the maven-war-plugin to generate the manifest and add the classpath. 4. create an EAR project and define the WAR project created in step one as a web module. 5. 'mvn package' the EAR project and look at the META-INF/MANIFEST.MF generated for the WAR project. I realize these are very rough directions, but I'm not permitted by my employer to share the project that I was building when I ran into the bug. If this is not clear enough, I could probably put together a minimal example project. Also, I think this is a new bug, because switching back to 2.1-alpha-2 solved the problem for me.
Hide
Permalink
Stephane Nicoll added a comment -

This is a duplicate. See MWAR-215.

Show
Stephane Nicoll added a comment - This is a duplicate. See MWAR-215.

People

Vote (2)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
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.