Maven 2.x Ear Plugin

Incorrect file name in class path (in manifest) if specifying different bundleFileName for module

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.3.1
  • Fix Version/s: 2.4
  • Labels:
    None
  • Environment:
    Windows XP SP2, Maven 2.0.7, JDK 1.5.0_12
  • Number of attachments :
    1

Description

The file name included in the class path in the generated Manifest.mf file is incorrect if a different bundle file name is defined in the configuration for the ear plugin. The file name used in the class path is the original file name, not the defined bundle file name (which is the actual file name in the created ear).

In my POM I have:

pom.xml
	...
	<dependencies>
		<dependency>
			<groupId>jbossaop-poc</groupId>
			<artifactId>aop</artifactId>
			<type>jar</type>
		</dependency>
		...
	</dependencies>

	<build>
		<plugins>
			<plugin>
				<artifactId>maven-ear-plugin</artifactId>
				<configuration>
					<archive>
						<manifest>
							<addClasspath>true</addClasspath>
						</manifest>
					</archive>
					<modules>
						<jarModule>
							<groupId>jbossaop-poc</groupId>
							<artifactId>aop</artifactId>
							<bundleFileName>aop-${pom.version}.aop</bundleFileName>
							<includeInApplicationXml>true</includeInApplicationXml>
						</jarModule>
					</modules>
				</configuration>
			</plugin>
		</plugins>
	</build>

In the resulting ear file, the included artifact 'aop-1.0-SNAPSHOT.jar' has been renamed to 'aop-1.0-SNAPSHOT.aop'. However, in the Manifest.mf (in the ear) the class path incorrectly specifies:
Class-Path: aop-1.0-SNAPSHOT.jar

Attached is a multi-module project that should reproduce this.

Issue Links

relates to

Improvement - An improvement or enhancement to an existing feature or task. MEAR-60 Improve support for skinny war files

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Stéphane Nicoll added a comment -

Yep, good point. This is probably applicable to all plugins that update the file name of libs.

However, I wonder why you're using a manifest for an EAR. The way to define dependencies is through the application.xml, not the manifest.

Show
Stéphane Nicoll added a comment - Yep, good point. This is probably applicable to all plugins that update the file name of libs. However, I wonder why you're using a manifest for an EAR. The way to define dependencies is through the application.xml, not the manifest.
Hide
Permalink
Anders Hammar added a comment -

No reason actually. The manifest part was created by the j2ee-simple archetype and I've removed it now for my project. However, being a good OSS citizen I reported the bug.

Feel free to lower the priority as I guess it isn't major. Also, if the jira should be filed for some other component tell me and I'll do it.

Show
Anders Hammar added a comment - No reason actually. The manifest part was created by the j2ee-simple archetype and I've removed it now for my project. However, being a good OSS citizen I reported the bug. Feel free to lower the priority as I guess it isn't major. Also, if the jira should be filed for some other component tell me and I'll do it.
Hide
Permalink
Barend Garvelink added a comment -

Here's a vote in favour of raising the priority for this issue. Consider the following scenario:

  • We have converted a large, existing application to Maven. The application uses EJB 2.1 and throughout all the EJB and WEB deployment descriptors the <ejb-link>EjbModule.jar#EJB-NAME</ejb-link> element is used for wiring everything together.
  • To make the ejb-links work, we're using the <bundleFileName> directive to strip version numbers from the JARs and WARs upon inclusion in the EAR file.
  • This breaks the manifest class-paths of the wars and ejb-jar's that have been included int he ear, as mentioned in the original issue. On WebSphere v5.1, this is a serious problem; correct manifest class-paths in the embedded modules are a requirement (e.g. if a WAR and EJB-JAR are are part of the same EAR, and the WAR uses the EJB's, the manifest class-path for the WAR file must mention the EJB-JAR file by its name within the EAR). The manifest class-path of the ear itself, as Stephane mentions in comment 1, isn't so important.

In my opinion, the maven-ear-plugin is justified in rewriting the manfest class-paths of its included modules on the basis that these modules become part of a larger assembly and (in that scope) no longer exist on their own. The original modules remain unchanged in the repository. Rewriting the manifest class paths is easier than rewriting the ejb-links, and has a potentially wider applicability.

We're in the process of selecting the least painful of a number of work-arounds. If the maven-ear-plugin would update the manifest classpaths for the modules it includes, that'd be mighty helpful.

Show
Barend Garvelink added a comment - Here's a vote in favour of raising the priority for this issue. Consider the following scenario: We have converted a large, existing application to Maven. The application uses EJB 2.1 and throughout all the EJB and WEB deployment descriptors the <ejb-link>EjbModule.jar#EJB-NAME</ejb-link> element is used for wiring everything together. To make the ejb-links work, we're using the <bundleFileName> directive to strip version numbers from the JARs and WARs upon inclusion in the EAR file. This breaks the manifest class-paths of the wars and ejb-jar's that have been included int he ear, as mentioned in the original issue. On WebSphere v5.1, this is a serious problem; correct manifest class-paths in the embedded modules are a requirement (e.g. if a WAR and EJB-JAR are are part of the same EAR, and the WAR uses the EJB's, the manifest class-path for the WAR file must mention the EJB-JAR file by its name within the EAR). The manifest class-path of the ear itself, as Stephane mentions in comment 1, isn't so important. In my opinion, the maven-ear-plugin is justified in rewriting the manfest class-paths of its included modules on the basis that these modules become part of a larger assembly and (in that scope) no longer exist on their own. The original modules remain unchanged in the repository. Rewriting the manifest class paths is easier than rewriting the ejb-links, and has a potentially wider applicability. We're in the process of selecting the least painful of a number of work-arounds. If the maven-ear-plugin would update the manifest classpaths for the modules it includes, that'd be mighty helpful.
Hide
Permalink
Barend Garvelink added a comment -

If anything is done about <bundleFileName> and manifest class-paths, the <defaultLibBundleDir> element should be taken into account as well.

Show
Barend Garvelink added a comment - If anything is done about <bundleFileName> and manifest class-paths, the <defaultLibBundleDir> element should be taken into account as well.
Hide
Permalink
Stéphane Nicoll added a comment -

Last reported bug over here. Let's kill it!

Show
Stéphane Nicoll added a comment - Last reported bug over here. Let's kill it!
Hide
Permalink
Stéphane Nicoll added a comment -

The issue is now fixed and a SNAPSHOT of 2.3.3 is available on the apache repository.

The way the Class-Path entry is generated now is through a call to the getUri() method on each EarModules. This method returns the location of the file according to the root of the EAR file.

Please test this solution to validate it fits your needs.

I will call a vote to release 2.3.3 in the coming days.

Show
Stéphane Nicoll added a comment - The issue is now fixed and a SNAPSHOT of 2.3.3 is available on the apache repository. The way the Class-Path entry is generated now is through a call to the getUri() method on each EarModules. This method returns the location of the file according to the root of the EAR file. Please test this solution to validate it fits your needs. I will call a vote to release 2.3.3 in the coming days.
Hide
Permalink
Stéphane Nicoll added a comment -

nobody cares?

Show
Stéphane Nicoll added a comment - nobody cares?
Hide
Permalink
Anders Hammar added a comment -

I don't have any real project depending on this feature, so I don't. I just reported the bug when I ran into it doing some dev tests. Thanks for fixing it and if you think it works it's good enough for me!

Show
Anders Hammar added a comment - I don't have any real project depending on this feature, so I don't. I just reported the bug when I ran into it doing some dev tests. Thanks for fixing it and if you think it works it's good enough for me!

People

  • Assignee:
    Stéphane Nicoll
    Reporter:
    Anders Hammar
Vote (6)
Watch (6)

Dates

  • Created:
    Updated:
    Resolved: