Maven 2.x Assembly Plugin

outputFileNameMapping fails and includes parent's name

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Won't Fix
  • Affects Version/s: 2.2-beta-2
  • Fix Version/s: 2.2-beta-3
  • Component/s: None
  • Labels:
    None
  • Environment:
    Maven 2.0.9, JDK6, WinXP SP2 AND debian 4.0, Maven 2.0.8, JDK6 AND Maven Embedder m2eclipse 0.9.1
  • Number of attachments :
    5

Description

I have created a bin assembly descriptor containing:

<moduleSets>
		<moduleSet>
			<includes>
				<include>*:jar</include>
			</includes>
			<binaries>
				<includeDependencies>false</includeDependencies>
				<outputFileNameMapping>
					fckeditor-${module.artifactId}-${module.version}.${module.extension}
				</outputFileNameMapping>
				<unpack>false</unpack>
			</binaries>
		</moduleSet>
		<moduleSet>
			<includes>
				<include>*:jar</include>
			</includes>
			<binaries>
				<attachmentClassifier>javadoc</attachmentClassifier>
				<includeDependencies>false</includeDependencies>
				<outputFileNameMapping>
					fckeditor-${module.artifactId}-${module.version}-${module.classifier}.${module.extension}
				</outputFileNameMapping>
				<unpack>false</unpack>
			</binaries>
		</moduleSet>
	</moduleSets>

The expected zip distro should look like the expected attachment but sometimes (80 %) the outcome is the broken example.
It seems like it does not resolves the module but the my parent. Browser my source here if you like.

Interesting to say if the bin distro is fine, maven reports (note the parent warning):

[INFO] [assembly:assembly]
[INFO] Reading assembly descriptor: src/main/assembly/src.xml
[INFO] Reading assembly descriptor: src/main/assembly/bin.xml
[INFO] Adding site directory to assembly : D:\workspace_\fckeditor-java\target\s
ite
[INFO] Processing sources for module project: net.fckeditor:java-demo:war:2.4-SN
APSHOT
[INFO] Processing sources for module project: net.fckeditor:java-core:jar:2.4-SN
APSHOT
[INFO] Building zip: D:\workspace_\fckeditor-java\target\fckeditor-java-2.4-SNAP
SHOT-src.zip
[WARNING] NOTE: Currently, inclusion of module dependencies may produce unpredic
table results if a version conflict occurs.
[WARNING] NOTE: Currently, inclusion of module dependencies may produce unpredic
table results if a version conflict occurs.
[INFO] Processing DependencySet (output=lib)
[WARNING] Cannot include project artifact: net.fckeditor:fckeditor-java:pom:2.4-
SNAPSHOT; it doesn't have an associated file or directory.
[INFO] Building zip: D:\workspace_\fckeditor-java\target\fckeditor-java-2.4-SNAP
SHOT-bin.zip
[INFO]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] FCKeditor.Java Integration ............................ SUCCESS [32.797s]

[INFO] FCKeditor.Java Integration Core ....................... SUCCESS [15.203s]

[INFO] FCKeditor.Java Integration Demo Webapp ................ SUCCESS [4.609s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 minute 2 seconds
[INFO] Finished at: Mon Apr 14 12:14:40 CEST 2008
[INFO] Final Memory: 18M/33M
[INFO] ------------------------------------------------------------------------

D:\workspace_\fckeditor-java>

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
John Casey added a comment -

This is the test project structure I tried, but I cannot reproduce the issue. Can you try and/or modify this test project so it will fail, and re-attach it? Otherwise, I'm going to have to close this one as CANNOT REPRODUCE.

Show
John Casey added a comment - This is the test project structure I tried, but I cannot reproduce the issue. Can you try and/or modify this test project so it will fail, and re-attach it? Otherwise, I'm going to have to close this one as CANNOT REPRODUCE.
Hide
Permalink
Michael Osipov added a comment - - edited

JD,

I was able to reproduce the issue on your example with simple change which resembles my code:

--- E:/Downloads/massembly-309/src/main/assembly/bin.xml	Fri Sep 19 13:53:05 2008
+++ E:/massembly-309/src/main/assembly/bin.xml	Fri Sep 19 13:50:47 2008
@@ -1,13 +1,13 @@
 <assembly>
   <id>bin</id>
   <formats>
-    <format>dir</format>
+    <format>zip</format>
   </formats>
   <moduleSets>
     <moduleSet>
       <binaries>
         <includeDependencies>false</includeDependencies>
-        <outputFileNameMapping>module-${module.artifactId}-${module.version}.${module.extension}</outputFileNameMapping>
+        <outputFileNameMapping>module-${artifactId}-${version}.${extension}</outputFileNameMapping>
         <unpack>false</unpack>
       </binaries>
     </moduleSet>
@@ -15,7 +15,7 @@
       <binaries>
         <attachmentClassifier>javadoc</attachmentClassifier>
         <includeDependencies>false</includeDependencies>
-        <outputFileNameMapping>module-${module.artifactId}-${module.version}-${module.classifier}.${module.extension}</outputFileNameMapping>
+        <outputFileNameMapping>module-${artifactId}-${version}-${classifier}.${extension}</outputFileNameMapping>
         <unpack>false</unpack>
       </binaries>
     </moduleSet>

After that I added "module." to my bin.xml and it resolved the issue somewhat. This simply means that omitting the "module." does cause an interpolation error. I omitted the "module." because the documenation for the asssembly plugin told me so.
The prop name addition resolved only the jar naming issue. The site directory is still broken!
You may checkout my 2.4 tag and change the assembly plugin version and the properties and see the broken jars and the messed up site directory in the bin zip.
Additionally I added 2 images depicting the site dir issue.

Show
Michael Osipov added a comment - - edited JD, I was able to reproduce the issue on your example with simple change which resembles my code: 
--- E:/Downloads/massembly-309/src/main/assembly/bin.xml	Fri Sep 19 13:53:05 2008
+++ E:/massembly-309/src/main/assembly/bin.xml	Fri Sep 19 13:50:47 2008
@@ -1,13 +1,13 @@
 <assembly>
   <id>bin</id>
   <formats>
-    <format>dir</format>
+    <format>zip</format>
   </formats>
   <moduleSets>
     <moduleSet>
       <binaries>
         <includeDependencies>false</includeDependencies>
-        <outputFileNameMapping>module-${module.artifactId}-${module.version}.${module.extension}</outputFileNameMapping>
+        <outputFileNameMapping>module-${artifactId}-${version}.${extension}</outputFileNameMapping>
         <unpack>false</unpack>
       </binaries>
     </moduleSet>
@@ -15,7 +15,7 @@
       <binaries>
         <attachmentClassifier>javadoc</attachmentClassifier>
         <includeDependencies>false</includeDependencies>
-        <outputFileNameMapping>module-${module.artifactId}-${module.version}-${module.classifier}.${module.extension}</outputFileNameMapping>
+        <outputFileNameMapping>module-${artifactId}-${version}-${classifier}.${extension}</outputFileNameMapping>
         <unpack>false</unpack>
       </binaries>
     </moduleSet>
After that I added "module." to my bin.xml and it resolved the issue somewhat. This simply means that omitting the "module." does cause an interpolation error. I omitted the "module." because the documenation for the asssembly plugin told me so. The prop name addition resolved only the jar naming issue. The site directory is still broken! You may checkout my 2.4 tag and change the assembly plugin version and the properties and see the broken jars and the messed up site directory in the bin zip. Additionally I added 2 images depicting the site dir issue.
Hide
Permalink
John Casey added a comment -

we had to change the behavior of ${artifactId} and ${version} to be consistent with the rest of the descriptor (i.e. to reference the project currently being built). To make these expressions more intuitive, we're using ${artifact.artifactId} or ${module.artifactId} in the case of a module binary instead.

I've noted this as an area where the documentation needs to be updated in MASSEMBLY-151.

Show
John Casey added a comment - we had to change the behavior of ${artifactId} and ${version} to be consistent with the rest of the descriptor (i.e. to reference the project currently being built). To make these expressions more intuitive, we're using ${artifact.artifactId} or ${module.artifactId} in the case of a module binary instead. I've noted this as an area where the documentation needs to be updated in MASSEMBLY-151.
Hide
Permalink
Michael Osipov added a comment -

John,

I commented on #151 too. Thanks for your help. I have made some tests and you are right. The interpolation behavior between beta 1 and beta 2 has changed! The site problem is gone after I have changed

<moduleSet>
			<sources>
				<includeModuleDirectory>false</includeModuleDirectory>
				<fileSets>
					<fileSet>
						<outputDirectory>
							site/${artifactId}
						</outputDirectory>
						<directory>target/site</directory>
					</fileSet>
				</fileSets>
			</sources>
		</moduleSet>

to

<moduleSet>
			<sources>
				<includeModuleDirectory>false</includeModuleDirectory>
				<fileSets>
					<fileSet>
						<outputDirectory>
							site/${module.artifactId}
						</outputDirectory>
						<directory>target/site</directory>
					</fileSet>
				</fileSets>
			</sources>
		</moduleSet>
Show
Michael Osipov added a comment - John, I commented on #151 too. Thanks for your help. I have made some tests and you are right. The interpolation behavior between beta 1 and beta 2 has changed! The site problem is gone after I have changed 
<moduleSet>
			<sources>
				<includeModuleDirectory>false</includeModuleDirectory>
				<fileSets>
					<fileSet>
						<outputDirectory>
							site/${artifactId}
						</outputDirectory>
						<directory>target/site</directory>
					</fileSet>
				</fileSets>
			</sources>
		</moduleSet>
to 
<moduleSet>
			<sources>
				<includeModuleDirectory>false</includeModuleDirectory>
				<fileSets>
					<fileSet>
						<outputDirectory>
							site/${module.artifactId}
						</outputDirectory>
						<directory>target/site</directory>
					</fileSet>
				</fileSets>
			</sources>
		</moduleSet>

People

Vote (2)
Watch (2)

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.