date:20101001


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-186:
--

Fix Version/s: (was: 2.2)

 Download files from HTTP or FTP
 ---

 Key: MASSEMBLY-186
 URL: http://jira.codehaus.org/browse/MASSEMBLY-186
 Project: Maven 2.x Assembly Plugin
  Issue Type: New Feature
 Environment: All
Reporter: Marcel Schoen
Assignee: John Casey
Priority: Minor

 It would be nice if the assembly plugin could also gather files to be packed 
 from external sources over HTTP or FTP. The configuration could look like 
 this:
   urlSet
   urlhttp://files.acme.com/data/url
   excludes
   exclude**/*.jar/exclude
   /excludes
   outputDirectory//outputDirectory
   /urlSet
   urlSet
   urlftp://files.acme.com/data/url
   excludes
   exclude**/*.jar/exclude
   /excludes
   outputDirectory//outputDirectory
   /urlSet
 It could support basically every available URL protocoll suitable for file 
 retrieval, like scp:, smb: etc.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-350) outputFileNameMapping


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-350:
--

Fix Version/s: (was: 2.2)

 outputFileNameMapping
 -

 Key: MASSEMBLY-350
 URL: http://jira.codehaus.org/browse/MASSEMBLY-350
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
 Environment: unix
Reporter: Michael Meng
Assignee: John Casey
Priority: Blocker

 in the pom.xml file we define the 
dependency  service versionas SNAPSHOT
dependency  serviceTools version  as SNAPSHOT
 however in the package it created, this dependency show as 
 service-20080826.230044-12.jar and 
 serviceTools-SNAPSHOT.jar
 How to make both show as -SNAPSHOT.jar ? 
 I defined
 outputFileNameMapping${artifact.artifactId}-${artifact.baseVersion}.${artifact.extension}/outputFileNameMapping
 but seems not work.
 Any suggestion or do you why one show as -SNAPSHOT and other not ?
 Thanks

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-409) Predefined project assembly needs fixes to use it for ASF based source releases


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-409:
--

Fix Version/s: (was: 2.2)

 Predefined project assembly needs fixes to use it for ASF based source 
 releases  
 -

 Key: MASSEMBLY-409
 URL: http://jira.codehaus.org/browse/MASSEMBLY-409
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2, 2.2-beta-3
Reporter: Ate Douma
Assignee: John Casey
Priority: Critical

 We've been using the 2.2-beta-2 plugin for recent Apache Portals releases 
 (not 2.2-beta-3 because of MASSEMBLY-405) en encountered a few annoying 
 issues.
 1) Used together with apache-release profile of the Apache 6 pom, the 
 maven-remote-resource-plugin is also executed by default (as it should) but 
 that produces a velocity.log file in the project root which is then included 
 by the project assembly. The main problem IMO is that predefined assemblies 
 do not take *any* configuration overrides/extensions.
 As each (ASF) project is different, the likelihood some temporary build 
 output is produced during the release and subsequently assembled should be 
 expected, the velocity.log produced by the m-r-r-p just being an example.
 My preference therefore would be that predefined assemblies do accept 
 additional configuration settings so we can include/exclude specific files as 
 needed.
 If that is not doable (on short notice), the project assembly as a minimum 
 should add an exclude for velocity.log as disabling creating that file on the 
 m-r-r-p doesn't seem doable either.
 NB: see also http://issues.apache.org/jira/browse/PORTALS-16 as reference.
 2) Related to the above is the fact that the project assembly uses 
 classifier project. This is by design of course, but as we are used to 
 providing source distributions with a -src postfix, and end-users will look 
 for that by default,
 it would be good if the classifier can be overridden/configurable (using the 
 predefined src assembly instead clearly isn't possible for this purpose).
 However, even while the classifier is (still) specified as a *deprecated* 
 optional parameter, it is completely ignored (now?).
 I strongly suggest to re-enable the classifier parameter again, or provide 
 a new alternative parameter for this purpose. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-457) The empty assemblies should be skipped in multimodule projects.


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-457:
--

Fix Version/s: (was: 2.2)

 The empty assemblies should be skipped in multimodule projects.
 ---

 Key: MASSEMBLY-457
 URL: http://jira.codehaus.org/browse/MASSEMBLY-457
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-5
 Environment: Windows7, java1.6, maven 2.2.1  or Linux + Hudson 1.33x 
Reporter: Kek
Assignee: John Casey
Priority: Critical
 Attachments: patch.txt, test-modules.zip


 Our workspace contains
 - multimodule project  (like in attached  test-modules.zip)
 - defined assembly on parent to zip  src/main/config  or src/test/config  
 folders and attach the zip to module
 - but some child-modules could have empty config folders
 than we obtain
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to create 
 assembly: Error creating assembly archive config: You must set at least one 
 file.
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
   at 
 org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create 
 assembly: Error creating assembly archive config: You must set at least one 
 file.
   at 
 org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:421)
   at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
   ... 17 more
 Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: 
 Error creating assembly archive config: You must set at least one file.
   at 
 org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:194)
   at 
 org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:370)
   ... 19 more
 Caused by: org.codehaus.plexus.archiver.ArchiverException: You must set at 
 least one file.
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:272)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:250)
   at 
 org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:852)
   at 
 org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:496)
   at 
 org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:190)
   ... 20 more
 I found the similar issue on maven-source-plugin:   
 http://jira.codehaus.org/browse/MSOURCES-44
 So I suppose, that the problem could be solved in the same way.
 May be, that this bug is duplicated with 
 http://jira.codehaus.org/browse/MASSEMBLY-420, but I'm not sure.
 The similar problem was with previous version of maven-jar-plugin, but 
 current version is already repaired and works in same waz as 
 maven-source-plugin. So we use the maven-jar-plugin instead of 
 assembly-plugin  as workaround for this issue. But there are empty jars 
 created, so

[jira] Updated: (MASSEMBLY-348) Configuration option to define a different extension.


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-348:
--

Fix Version/s: (was: 2.2)

 Configuration option to define a different extension.
 -

 Key: MASSEMBLY-348
 URL: http://jira.codehaus.org/browse/MASSEMBLY-348
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
Affects Versions: 2.2-beta-2
Reporter: Stefano Bagnara
Assignee: John Casey
 Attachments: MASSEMBLY-348.diff, plexus-archiver-sar-support-1.0.jar, 
 plexus-archiver-sar-support-1.0.jar


 I have to create a Avalon Phoenix SAR file. It is a zip/jar, with a 
 different extension.
 The assembly plugin allow me to create a zip or a jar, let me choose the 
 name, but I cannot alter the extension.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-335) 'attached' goal execution is not consistent (and fails for EasyEclipse server java 1.2.2.2 with .m2eclipse plugin on Ubuntu 8.04)


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-335:
--

Fix Version/s: (was: 2.2)

 'attached' goal execution is not consistent (and fails for EasyEclipse server 
 java 1.2.2.2 with .m2eclipse plugin on Ubuntu 8.04)
 -

 Key: MASSEMBLY-335
 URL: http://jira.codehaus.org/browse/MASSEMBLY-335
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
 Environment: Ubuntu 8.04 Hardy Heron, Easy Eclipse java server 
 distribution with m2eclipse plugin (www.easyeclipse.org), maven 2.0.9
Reporter: Mahender Didwania
Assignee: John Casey
 Attachments: pom.xml, src.xml


 From the build output for environment mentioned in Environment:
 ...
 Diagnosis: Internal error in the plugin manager executing goal 
 'org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-2:attached': Error 
 adding plugin dependency 'org.codehaus.plexus:plexus-archiver:jar' into 
 plugin manager: Cannot add jar resource: 
 /home/developer/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-10/plexus-archiver-1.0-alpha-10.jar
  (error discovering new components)
 FATAL ERROR: Error executing Maven for a project
 [ERROR] reactor-execute : /home/developer/eclipse.workspace/PIDataLoad-PFR_F
 Diagnosis: Internal error in the plugin manager executing goal 
 'org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-2:attached': Error 
 adding plugin dependency 'org.codehaus.plexus:plexus-archiver:jar' into 
 plugin manager: Cannot add jar resource: 
 /home/developer/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-10/plexus-archiver-1.0-alpha-10.jar
  (error discovering new components)
 FATAL ERROR: Error executing Maven for a project
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Internal error in the plugin manager executing goal 
 'org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-2:attached': Error 
 adding plugin dependency 'org.codehaus.plexus:plexus-archiver:jar' into 
 plugin manager: Cannot add jar resource: 
 /home/developer/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-10/plexus-archiver-1.0-alpha-10.jar
  (error discovering new components)
 Component descriptor role: 
 'org.codehaus.plexus.archiver.manager.ArchiverManager', implementation: 
 'org.codehaus.plexus.archiver.manager.DefaultArchiverManager', role hint: 
 'default' has a hint, but implementation 
 org.codehaus.plexus.archiver.manager.DefaultArchiverManager doesn't
 ...
 Note that if I use Windows XP SP2, maven 2.0.9, the Eclipse distribution 
 3.3.1.1 with .m2eclipse plugin installed from 
 http://m2eclipse.sonatype.org/update/ , then I get a warning (instead of 
 error) during the build, as follows:
 ...
 [WARNING]
 DEPRECATED: Binding aggregator mojos to lifecycle phases in the POM is 
 considered dangerous.
 This feature has been deprecated.  Please adjust your POM files accordingly.
 Offending mojo:
 org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-1:attached
 ...
 (Since when has this been deprecated, what is the workaround?  Is the error I 
 face in any way related to this?)
 Note that if I perform the build from the command line using mvn package, the 
 build succeeds but all my .jar files in Support/lib end up with the same name 
 within the created assembly (.zip), that name is PFR4700.${extension}.  I am 
 attaching the pom.xml and src.xml (assembly descriptor).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-259) Delete archived-file-set folders in home


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-259:
--

Fix Version/s: (was: 2.2)

 Delete archived-file-set folders in home
 

 Key: MASSEMBLY-259
 URL: http://jira.codehaus.org/browse/MASSEMBLY-259
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
 Environment: WinXP, Ubuntu
Reporter: stefan stieglitz
Assignee: John Casey

 Unpack creates archived-file-set folders in the users home directory that 
 are never deleted. In large projects this can lead to a temp folder 
 containing several GB of wasted disk space.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-323) Unable to unzip a file created with maven assembly plugin using JDK 1.6 (IllegalArgumentException at getUTF8String(byte[] b, int off, int len))


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-323:
--

Fix Version/s: (was: 2.2)

 Unable to unzip a file created with maven assembly plugin using JDK 1.6 
 (IllegalArgumentException at getUTF8String(byte[] b, int off, int len))
 ---

 Key: MASSEMBLY-323
 URL: http://jira.codehaus.org/browse/MASSEMBLY-323
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
 Environment: Maven version: 2.0.8
 Java version: 1.6.0_05
 OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Gervais Mickaël
Assignee: John Casey

 I've a pom with:
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-assembly-plugin/artifactId
   executions
   execution
   !-- this is used for inheritance merges --
   idmake-assembly/id
   !-- append to the packaging phase. --
   phasepackage/phase
   goals
   !-- goals == mojos --
   goalattached/goal
   /goals
   configuration
   descriptors
   
 descriptorassembly-config.xml/descriptor
   /descriptors
   /configuration
   /execution
   /executions
 /plugin 
 and I want to unzip the zip file with JDK 1.6. I've an exception...
 If I open the zip file with 7zip I can see that OS host is set to linux even 
 if I'm on windows.
 When I do mvn package in debug mode I can see that the file encoding is set 
 to null...
 Is this a plexus archiver mistake or a bug?
 Thanks

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-459) Assembly descriptors should be loaded from standard location.


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-459:
--

Fix Version/s: (was: 2.2)

 Assembly descriptors should be loaded from standard location.
 -

 Key: MASSEMBLY-459
 URL: http://jira.codehaus.org/browse/MASSEMBLY-459
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
Affects Versions: 2.2-beta-5
Reporter: Emerson Farrugia
Assignee: John Casey
Priority: Minor

 The Maven standard directory layout uses src/main/assembly as the location 
 for assembly descriptors. 
 (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html)
 The maven-assembly-plugin does not search this directory at all (let alone 
 first) for descriptor files. Should we be able to put file.xml in that 
 location, specify file.xml in the plugin configuration, and trust in 
 conventions that the plugin will find it?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-339) Overridden artifact finalName with classifier is ignored by the assembly plugin.


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-339:
--

Fix Version/s: (was: 2.2)

 Overridden artifact finalName with classifier is ignored by the assembly 
 plugin.
 

 Key: MASSEMBLY-339
 URL: http://jira.codehaus.org/browse/MASSEMBLY-339
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-1
 Environment: Maven 2.0.9, JDK 6, WinXP SP2
Reporter: Michael Osipov
Assignee: John Casey
 Attachments: assemblyClassifierMapping.png


 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
 I did create a bin assembly. The assembly contains the javadoc jars but their 
 names do not correspond to the overridden finalNames.
 The javadoc:jar genereation is bound to the package phase.
 An example picture is attached and the project can be checked out at our 
 [trac|http://dev.fckeditor.net/browser/FCKeditor.Java/trunk] and the 
 [SVN|http://svn.fckeditor.net/FCKeditor.Java/trunk/] directly.
 Checkout the 
 [bin.xml|http://dev.fckeditor.net/browser/FCKeditor.Java/trunk/src/main/assembly/bin.xml]
  and comment out the second outputFileNameMapping and run mvn clean site 
 package assembly:assembly.
 You should be able to reproduce the problem.
 I did find a workaround for the problem by defining the outputFileNameMapping 
 as same as in the modules poms. This works just because all modules have the 
 same finalName remapping.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-461) Better error handling for duplicate assembly ID


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-461:
--

Fix Version/s: (was: 2.2)

 Better error handling for duplicate assembly ID
 ---

 Key: MASSEMBLY-461
 URL: http://jira.codehaus.org/browse/MASSEMBLY-461
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
Affects Versions: 2.2-beta-5
Reporter: Paul Gier
Assignee: John Casey
Priority: Minor

 I have two assemblies in a project.  The assemblies have the same name except 
 for the extension, but they are different files.  The assembly plugin 
 currently throws a warning if these two assemblies use the same id.  It 
 should only give a warning if the complete file name is the same.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-391) Sharing a default assembly descriptor across sub modules does not work if invoked from parent project


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-391:
--

Fix Version/s: (was: 2.2)

 Sharing a default assembly descriptor across sub modules does not work if 
 invoked from parent project
 -

 Key: MASSEMBLY-391
 URL: http://jira.codehaus.org/browse/MASSEMBLY-391
 Project: Maven 2.x Assembly Plugin
  Issue Type: New Feature
Affects Versions: 2.0.1
Reporter: Stephen Evanchik
Assignee: John Casey
 Attachments: test.error


 I have a multi-project folders setup like one shown below,
   
 root 
 |_ sub-folder1 
 |_ sub-folder2 
 |_ sub-folder3 
 |_ etc   
   
 Have a root pom.xml at the root folder level and in that I have defined 
 plugin 
 artifactIdmaven-assembly-plugin/artifactId 
 configuration 
 descriptors 
 descriptorsrc/main/assembly/descriptor.xml 
 /descriptor 
 /descriptors   
 /configuration 
 /plugin 
   
 Above descriptor works fine only if I have defined a descriptor file on the 
 src/main/assembly folder for each sub-folder1, sub-folder2, etc. 
 It would be great if maven supports me in defining a common assembly 
 descriptor and can be shared by all the sub modules from a common location.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-368) In a DependencySet I cannot get scope to be transitive


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-368:
--

Fix Version/s: (was: 2.2)

 In a DependencySet I cannot get scope to be transitive
 --

 Key: MASSEMBLY-368
 URL: http://jira.codehaus.org/browse/MASSEMBLY-368
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
 Environment: I define an assembly having the  dir format.
Reporter: Jean-Sébastien Scrève
Assignee: John Casey

 I have a project A who has a dependency to another project named myDomain.
 dependency
   groupIdmyDomain/groupId
   artifactIdmyDomain/artifactId
   version1.0.0/version
   scopeprovided/scope
 /dependency
 myDomain also has others provided dependencies :
 dependency
   groupIdasm/groupId
   artifactIdasm/artifactId
   version2.2.3/version
   scopeprovided/scope
 /dependency
 dependency
   groupIdasm/groupId
   artifactIdasm-attrs/artifactId
   version2.2.3/version
   scopeprovided/scope
 /dependency
 In my assembly descriptor, I define the following dependency set :
 dependencySet
   useProjectArtifactfalse/useProjectArtifact
   useTransitiveDependenciestrue/useTransitiveDependencies
   outputDirectory/outputDirectory
   unpackfalse/unpack
   scopeprovided/scope
 /dependencySet
 None of the provided dependencies of myDomain project are included into my 
 assembly. 
 That is :asm:asm and asm:asm-attrs are not included but myDomain:myDomain is 
 included.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-394) Property filtering does not work inside the outputDirectory element content


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-394:
--

Fix Version/s: (was: 2.2)

 Property filtering does not work inside the outputDirectory element content
 ---

 Key: MASSEMBLY-394
 URL: http://jira.codehaus.org/browse/MASSEMBLY-394
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-3
 Environment: Maven version: 2.0.10
 Java version: 1.5.0_15
 Ubuntu 8.10
 OS name: linux version: 2.6.27-11-generic arch: i386 Family: unix
Reporter: Keith Wedinger
Assignee: John Casey

 Inside my POM, I have the following property defined:
 properties
 clump.nameb2b_oba/clump.name
 /properties
 Inside my assembly descriptor, I am attempting to use the property above as 
 well as project defined properties to filter the outputDirectory element 
 content contained within filesfile.  The relevant descriptor snippet is 
 below:
 files
 file
 
 source${clump.codejar.output.directory}/${project.name}.jar/source
 
 outputDirectory${project.name}/jars/${clump.name}/${clump.version.dir}/outputDirectory
 /file
 /files
 After running mvn assembly:assembly, the resultant outputDirectory content 
 remains as follows.  None of the properties are replaced with their 
 corresponding values.
 outputDirectory${project.name}/jars/${project.name}/${clump.version.dir}/outputDirectory
 maven-assembly-plugin version 2.1 does not have this issue.  When I use 
 version 2.1, property filtering on the outputDirectory works correctly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-485) DependencySet unpack doesn't allows expression


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-485:
--

Fix Version/s: (was: 2.2)

 DependencySet unpack doesn't allows expression
 --

 Key: MASSEMBLY-485
 URL: http://jira.codehaus.org/browse/MASSEMBLY-485
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Reporter: Mark Berner
Assignee: John Casey

 DependencySet unpack doesn't allows expression such ${exploded.ear} when 
 exploded.ear is property. unpack allows just constants true/false and in case 
 of expression behaves as for false
 In the maven-ear-plugin module unpack option allows expressions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-441) manifest is incorrectly 'overwritten' when using jar-with-dependencies


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-441:
--

Fix Version/s: (was: 2.2)

 manifest is incorrectly 'overwritten' when using jar-with-dependencies
 --

 Key: MASSEMBLY-441
 URL: http://jira.codehaus.org/browse/MASSEMBLY-441
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-4
 Environment: Maven 2.1
 JDK 1.5
Reporter: Adrian Shum
Assignee: John Casey

 plugin
 artifactIdmaven-assembly-plugin/artifactId
 configuration
 descriptorRefs
 descriptorRefjar-with-dependencies/descriptorRef
 /descriptorRefs
 archive
 manifest
 
 mainClassmy.fullly.qualified.MainClass/mainClass
 /manifest
 /archive
 /configuration
 executions
 execution
 idmake-assembly/id
 phasepackage/phase
 goals
 goaldirectory/goal!-- same case when 
 using single --
 /goals
 /execution
 /executions
 /plugin
 I used the plugin config above and tried to create a 'all-in-one executable 
 jar'.
 However, I found the MANIFEST.MF is not really what I declared.
 It seems that MANIFEST.MF of certain dependencies JARs is put there instead
 (In my case, Oracle's JDBC driver JAR's MANIFEST.MF is presented)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-390) No way to exclude moduleSet binary artifacts, while still including their dependencies


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-390:
--

Fix Version/s: (was: 2.2)

 No way to exclude moduleSet binary artifacts, while still including their 
 dependencies
 --

 Key: MASSEMBLY-390
 URL: http://jira.codehaus.org/browse/MASSEMBLY-390
 Project: Maven 2.x Assembly Plugin
  Issue Type: Wish
Reporter: Ben Coughlan
Assignee: John Casey
Priority: Trivial
 Attachments: useModuleArtifact.patch


 There is no way to exclude a moduleSet binary artifact without excluding all 
 of its dependencies.  This is necessary when dependencies of different types 
 need to be sorted into different deployment directories, to prevent the 
 module artifacts being included everywhere.
 The patch attached provides an example implementation of what I am thinking.
 An example descriptor would be:
 {code}
 assembly
 ...
 moduleSets
 !-- All Non Jar dependencies --
 moduleSet
 ...
 binaries
 useModuleArtifactfalse/useModuleArtifact
 dependencySets
 dependencySet
 excludes
 exclude*:jar/exclude
 /excludes
 /dependencySet
 /dependencySets
 outputDirectorynonjars/outputDirectory
 /binaries
 /moduleSet
 !-- All Jar dependencies --
 moduleSet
 binaries
 useModuleArtifactfalse/useModuleArtifact
 dependencySets
 dependencySet
 includes
 include*:jar/include
 /includes
 /dependencySet
 /dependencySets
 outputDirectoryjars/outputDirectory
 /binaries
 /moduleSet
 /moduleSets
 /assembly
 {code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-492) Reopen of MASSEMBLY-126 : DependencySet: Jars with scope runtime not assembled anymore


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-492:
--

Fix Version/s: (was: 2.2)

 Reopen of MASSEMBLY-126 : DependencySet: Jars with scope runtime not 
 assembled anymore
 --

 Key: MASSEMBLY-492
 URL: http://jira.codehaus.org/browse/MASSEMBLY-492
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-3, 2.2-beta-4, 2.2-beta-5
 Environment: Windows XP, maven 2.2.1
Reporter: Pinson Pierre-Marie
Assignee: John Casey

 Before I used 2.2-beta-1 version of assembly plugin to create my binary, and 
 it worked well.
 Today I upgraded the plugin to version 2.2-beta-5.
 There is a difference in the treatment of scope runtime in dependancySet.
 The libraries of this scope are not included in the archive.
 I tested 2.2-beta-4 and 2.2-beta-3, is the same problem.
 In 2.2-beta-2, it work.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-260) Empty archive-tmp appears in target folder after assembly created.


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-260:
--

Fix Version/s: (was: 2.2)

 Empty archive-tmp appears in target folder after assembly created.
 --

 Key: MASSEMBLY-260
 URL: http://jira.codehaus.org/browse/MASSEMBLY-260
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
 Environment: I'm using Maven 2.0.7, and maven-assembly-plugin version 
 2.2-beta-1.
Reporter: Matthew Tordoff
Assignee: John Casey

 I have created a custom assembly which packages up 3 directories within my 
 projects root directory as a zip file. This file can be seen as follows:
 assembly
   idMy Format/id
   formats
 formatzip/format
   /formats
   fileSets
 fileSet
   directory${basedir}\folderA/directory
   outputDirectory\folderA/outputDirectory
   includes
 include**\**/include
   /includes
 /fileSet
 fileSet
   directory${basedir}\folderB/directory
   outputDirectory\folderB/outputDirectory
   includes
 include**\**/include
   /includes
 /fileSet
 fileSet
   directory${basedir}\folderC/directory
   outputDirectory\folderC/outputDirectory
   includes
 include**\**/include
   /includes
 /fileSet
   /fileSets
 /assembly
 My POM.xml is packaging type 'pom', and in my base directory I have the 
 following file structure:
 basedir -- pom.xml
-- my_package_format.xml
-- folderA
-- folderB
-- folderC
 Note: I do not have the src directory. I am using this module purely to 
 package up DB files to be distributed as a ZIP.
 I have appropriately connected the plugin to the build cycle, however, after 
 I perform mvn package I am left with 2 things - 1) The correctly produced 
 ZIP file and 2) an erroneous empty directory archive-tmp. I am assuming 
 that this folder is normally created to be populated by the appropriate 
 contents of the src folder and subsequently packaged in some manner, however, 
 since I dont have a src directory it is never getting deleted.
 Any more information required then please let me know.
 Matt

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-338) Overridden artifact finalName is ignored by the assembly plugin.

[
http://jira.codehaus.org/browse/MASSEMBLY-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dennis Lundberg updated MASSEMBLY-338:
--

Fix Version/s: (was: 2.2)

Overridden artifact finalName is ignored by the assembly plugin.

Key: MASSEMBLY-338
URL: http://jira.codehaus.org/browse/MASSEMBLY-338
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-1
Environment: Maven 2.0.9, JDK 6, WinXP SP2
Reporter: Michael Osipov
Assignee: John Casey
Attachments: assemblyMapping.png

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
I did create a bin assembly. The assembly contains the jars but their names
do not correspond to the overridden finalNames.
An example picture is attached and the project can be checked out at our
[trac|http://dev.fckeditor.net/browser/FCKeditor.Java/trunk] and the
[SVN|http://svn.fckeditor.net/FCKeditor.Java/trunk/] directly.
Checkout the
[bin.xml|http://dev.fckeditor.net/browser/FCKeditor.Java/trunk/src/main/assembly/bin.xml]
and comment out the first outputFileNameMapping and run mvn clean site
package assembly:assembly.
You should be able to reproduce the problem.
I did find a workaround for the problem by defining the outputFileNameMapping
as same as in the modules poms. This works just because all modules have the
same finalName remapping.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-347) Plugin classpath is invalid during call of assembly:assembly


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-347:
--

Fix Version/s: (was: 2.2)

 Plugin classpath is invalid during call of assembly:assembly
 

 Key: MASSEMBLY-347
 URL: http://jira.codehaus.org/browse/MASSEMBLY-347
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
 Environment: Windows XP SP2, maven 2.0.8
Reporter: Oleg Atamanenko
Assignee: John Casey

 I use antrun plugin during compilation phase of one of my modules.
 My ant task uses plugin classpath for working (it loads some tasks from 
 classpath).
 If I run build with mvn compile or mvn install, plugin classpath is correct 
 and is passed to my ant file.
 If I want to build mvn assembly:assembly, then my plugin classpath is almost 
 empty.
 The broken classpath:
 =
  [echo] plugin classpath:  C:\Documents and 
 Settings\oatamanenko\.m2\repository\org\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar;C:\Documents
  and 
 Settings\oatamanenko\.m2\repository\ant\ant\1.6.5\ant-1.6.5.jar;C:\Documents 
 and 
 Settings\oatamanenko\.m2\repository\ant\ant-launcher\1.6.5\ant-launcher-1.6.5.jar;C:\HOME\Programs\apache-maven-2.0.8\lib\maven-2.0.8-uber.jar
 Correct classpath (during install phase) contains much more entries:
 =
  [echo] plugin classpath:  C:\Documents and 
 Settings\oatamanenko\.m2\repository\org\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar;C:\Documents
  and 
 Settings\oatamanenko\.m2\repository\commons-lang\commons-lang\2.4\commons-lang-2.4.jar;C:\Documents
  and 
 Settings\oatamanenko\.m2\repository\ant\ant\1.6.5\ant-1.6.5.jar;C:\Documents 
 and 
 Settings\oatamanenko\.m2\repository\org\drools\drools-ant\4.0.7\drools-ant-4.0.7.jar;C:\Documents
  and 
 Settings\oatamanenko\.m2\repository\org\drools\drools-core\4.0.7\drools-core-4.0.7.jar;C:\Documents
  and 
 Settings\oatamanenko\.m2\repository\org\mvel\mvel\1.3.1-java1.4\mvel-1.3.1-java1.4.jar;C:\Documents
  and 
 Settings\oatamanenko\.m2\repository\org\drools\drools-analytics\4.0.7\drools-analytics-4.0.7.jar;C:\Documents
  and 
 Settings\oatamanenko\.m2\repository\org\drools\drools-compiler\4.0.7\drools-compiler-4.0.7.jar;C:\Documents
  and 
 Settings\oatamanenko\.m2\repository\org\antlr\antlr-runtime\3.0\antlr-runtime-3.0.jar;C:\Documents
  and 
 Settings\oatamanenko\.m2\repository\org\eclipse\jdt\core\3.2.3.v_686_R32x\core-3.2.3.v_686_R32x.jar;C:\Documents
  and 
 Settings\oatamanenko\.m2\repository\janino\janino\2.5.10\janino-2.5.10.jar;C:\Documents
  and 
 Settings\oatamanenko\.m2\repository\xml-apis\xml-apis\1.3.04\xml-apis-1.3.04.jar;C:\Documents
  and 
 Settings\oatamanenko\.m2\repository\xerces\xercesImpl\2.8.1\xercesImpl-2.8.1.jar;C:\Documents
  and Settings\oatamanenko\.m2\repository\com\tho
 ughtworks\xstream\xstream\1.2.2\xstream-1.2.2.jar;C:\Documents and 
 Settings\oatamanenko\.m2\repository\xpp3\xpp3_min\1.1.3.4.O\xpp3_min-1.1.3.4.O.jar;
  ... and a lot of other output.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-327) Using filtered within dependencySet unpackOptions


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-327:
--

Fix Version/s: (was: 2.2)

 Using filtered within dependencySet unpackOptions
 -

 Key: MASSEMBLY-327
 URL: http://jira.codehaus.org/browse/MASSEMBLY-327
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
Reporter: Andy Yeung
Assignee: John Casey

 The files within the unpacked jar did not apply the filters defined.
 pom configuration includes
   configuration
   filters
   
 filtersrc/assemble/filter.properties/filter
   /filters
   /configuration
 which contains 
storage.id=abcde
 assembly.xml defines dependency set
   dependencySet
   outputDirectory/snp-agent1/outputDirectory
   unpacktrue/unpack
   unpackOptions
   filteredtrue/filtered
   /unpackOptions
   scoperuntime/scope
   includes
   include
   XXX.agent:agent-ear-config
   /include
   /includes
   /dependencySet
 However, the files within are not filtered.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-32) Provide installer support like NSIS or InnoSetup


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-32:
-

Fix Version/s: (was: 2.2)

 Provide installer support like NSIS or InnoSetup
 

 Key: MASSEMBLY-32
 URL: http://jira.codehaus.org/browse/MASSEMBLY-32
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Reporter: Vincent Siveton
Assignee: John Casey
 Attachments: MASSEMBLY-32.patch, maven-assembly-plugin.zip, 
 MNG-1643.diff, MNG-1643.diff, plexus-installer.diff


 Add the support of installer compiler like NSIS or InnoSetup. 
 See the thread:
 http://www.nabble.com/m2-developers-rfc%3A-The-assembly-plugin-ans-thirdparty-installation-builders-%28REPOST%29-t57.html#a1546470

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-473) Single file assemblies, please


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-473:
--

Fix Version/s: (was: 2.2)

 Single file assemblies, please
 --

 Key: MASSEMBLY-473
 URL: http://jira.codehaus.org/browse/MASSEMBLY-473
 Project: Maven 2.x Assembly Plugin
  Issue Type: New Feature
Affects Versions: 2.2-beta-5
Reporter: Benson Margulies
Assignee: John Casey

 I found myself wanting to take a single file, compress it, and make it into 
 an attached artifact. The build-helper won't compress, and, indeed, that's a 
 complex piece of code, all already here in the assembly plugin. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-253) It would be nice to support assembly descriptors from classpath


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-253:
--

Fix Version/s: (was: 2.2)

 It would be nice to support assembly descriptors from classpath
 ---

 Key: MASSEMBLY-253
 URL: http://jira.codehaus.org/browse/MASSEMBLY-253
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
 Environment: mvn 2.0.7
 jdk1.5
 winxp
Reporter: Andreas Höhmann
Assignee: John Casey
Priority: Minor

 for multi-projects it would be nice if i can define a single distribution 
 file for all subprojects.
 (see 
 http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html)
 a example:
 1. project-structur
 parent-project (pom)
  build-tools (jar)
  sub-module 1 (pom)
sub-module 1.1 (jar)
sub-module 1.2 (war)
  sub-module 2 (pom)
   sub-module 2.1 (jar)
 2. the distribution.xml in /parent-project/build-tools/src/main/resources/
 assembly
   iddistribution/id
   formats
 formatzip/format
   /formats
   includeBaseDirectoryfalse/includeBaseDirectory
   moduleSets
 moduleSet
   sources
 includeModuleDirectoryfalse/includeModuleDirectory
 fileSets
   fileSet
 outputDirectorysources/${artifactId}/outputDirectory
 excludes
   excludetarget/exclude
   exclude.project/exclude
   exclude.classpath/exclude
   exclude.settings/exclude
   exclude.checkstyle/exclude
   excludesrc/main/doc/exclude
   excludesrc/main/site/exclude
 /excludes
 includes
   includesrc/main/java/**/include
   includesrc/main/resources/**/include
   includesrc/main/webapp/**/include
 /includes
   /fileSet
 /fileSets
   /sources
   binaries
 outputDirectorybinary/outputDirectory
 includeDependenciestrue/includeDependencies
 unpackfalse/unpack
   /binaries
 /moduleSet
   /moduleSets
 /assembly
 3. the parent-project/pom.xml
 build
extensions
   extension
 groupIdde.ahoehma.test/groupId
 artifactIdbuild-tools/artifactId
 version1.0-SNAPSHOT/version
   /extension
/extensions
...
plugins
  plugin
 artifactIdmaven-assembly-plugin/artifactId
 configuration
   descriptors
 descriptordistribution.xml/descriptor
   /descriptors
   appendAssemblyIdfalse/appendAssemblyId
   outputDirectory${distribution.dir}/outputDirectory
   finalName${distribution.name}/finalName
 /configuration
   /plugin
...
 so i can build a distribution inside the parent-project:
'mvn clean package assembly:assembly'
 this distribution contains all source/binaries (defined in distribution.xml) 
 for all submodules
 and i can go into sub-module 1 
   'mvn clean package assembly:assembly'
 this distribution contains all source/binaries (defined in distribution.xml) 
 *only* for the submodule 1

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-471) [Multi-projects] Define maven-assembly-plugin in root pom.xml causes plugin's dependencies of child modules failed.


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-471:
--

Fix Version/s: (was: 2.2)

 [Multi-projects] Define maven-assembly-plugin in root pom.xml causes plugin's 
 dependencies of child modules failed.
 ---

 Key: MASSEMBLY-471
 URL: http://jira.codehaus.org/browse/MASSEMBLY-471
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-5
 Environment: Windows XP, Maven 2.2.1
Reporter: Jérémy Soula
Assignee: John Casey
Priority: Minor
 Attachments: bug-maven-assembly.zip


 I have a multi-module project (see attachment):
  * pom.xml: Define the version of the plugin maven-assembly-plugin
  * assembly: Jar project, contains an assembly descriptor
  * livraison: Project for building assembly artifact. Use the previous 
 assembly descriptor via dependencies. Attach assembly on the install phase.
  
  In the root directory, launch {{mvn clean install}} cause build failed:
  
  {code} 
 [INFO] 
 
 [INFO] Building Unnamed - fr.jsoula:livraison:pom:1.0-SNAPSHOT
 [INFO]task-segment: [clean, install]
 [INFO] 
 
 [INFO] [clean:clean {execution: default-clean}]
 [INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
 [INFO] [install:install {execution: default-install}]
 [INFO] Installing D:\perso\MyProjets\bug-maven-assembly\livraison\pom.xml to 
 D:\Documents\jsoula\.m2\repository\fr\jsoula\livraiso
 n\1.0-SNAPSHOT\livraison-1.0-SNAPSHOT.pom
 [INFO] [assembly:directory-single {execution: make-assembly}]
 [INFO] Reading assembly descriptor: assembly-test.xml
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Error reading assembly descriptors: Error locating assembly 
 descriptor: assembly-test.xml
 [1] [INFO] Searching for file location: 
 D:\perso\MyProjets\bug-maven-assembly\livraison\assembly-test.xml
 [2] [INFO] File: 
 D:\perso\MyProjets\bug-maven-assembly\livraison\assembly-test.xml does not 
 exist.
 [3] [INFO] Invalid artifact specification: 'assembly-test.xml'. Must contain 
 at least three fields, separated by ':'.
 [4] [INFO] Failed to resolve classpath resource: assemblies/assembly-test.xml 
 from classloader: org.codehaus.classworlds.RealmClas
 sloa...@b7c0b7c
 [5] [INFO] Failed to resolve classpath resource: assembly-test.xml from 
 classloader: org.codehaus.classworlds.realmclassloa...@b7c
 0b7c
 [6] [INFO] File: D:\perso\MyProjets\bug-maven-assembly\assembly-test.xml does 
 not exist.
 [7] [INFO] Building URL from location: assembly-test.xml
 Error:
 java.net.MalformedURLException: no protocol: assembly-test.xml
 at java.net.URL.init(URL.java:567)
 at java.net.URL.init(URL.java:464)
 at java.net.URL.init(URL.java:413)
 at 
 org.apache.maven.shared.io.location.URLLocatorStrategy.resolve(URLLocatorStrategy.java:54)
 at 
 org.apache.maven.shared.io.location.Locator.resolve(Locator.java:81)
 at 
 org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.addAssemblyFromDescriptor(DefaultAssemblyReader.java:309)
 at 
 org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssemblies(DefaultAssemblyReader.java:140)
 at 
 org.apache.maven.plugin.assembly.mojos.AbstractDirectoryMojo.execute(AbstractDirectoryMojo.java:49)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
 at 
 org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
 at

[jira] Updated: (MASSEMBLY-315) outputFileNameMapping in dependencySet uses pom's artifactid


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-315:
--

Fix Version/s: (was: 2.2)

 outputFileNameMapping in dependencySet uses pom's artifactid
 

 Key: MASSEMBLY-315
 URL: http://jira.codehaus.org/browse/MASSEMBLY-315
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Reporter: Thomas Diesler
Assignee: John Casey

 The descriptor below incorrectly produces a single output file in 
 server/default/lib
 assembly xmlns=http://maven.apache.org/POM/4.0.0; 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
 http://maven.apache.org/xsd/assembly-1.1.0-SNAPSHOT.xsd;
   
   iddeploy-structure-jboss422/id
   formats
 formatdir/format
   /formats
   includeBaseDirectoryfalse/includeBaseDirectory
   
   dependencySets
 
 !-- bin --
 dependencySet
   outputDirectorybin/outputDirectory
   useStrictFilteringtrue/useStrictFiltering
   unpacktrue/unpack
   includes
 include*:jbossws-framework:zip:scripts/include
   /includes
 /dependencySet
 
 !-- server/default/lib --
 dependencySet
   outputDirectoryserver/default/lib/outputDirectory
   
 outputFileNameMapping${artifactId}.${extension}/outputFileNameMapping
   useStrictFilteringtrue/useStrictFiltering
   unpackfalse/unpack
   includes
 include*:jaxws-api:jar/include
 include*:jbossws-common:jar/include
 include*:jbossws-framework:jar/include
 include*:jbossws-spi:jar/include
 include*:saaj-api:jar/include
   /includes
 /dependencySet
   /dependencySets
   
   moduleSets
 !-- client --
 moduleSet
   includes
 includeorg.jboss.ws:jbossws-cxf-client/include
   /includes
   binaries
 outputDirectoryclient/outputDirectory
 
 outputFileNameMapping${module.artifactId}.${module.extension}/outputFileNameMapping
 unpackfalse/unpack
 dependencySets
   dependencySet
 
 outputFileNameMapping${module.artifactId}.${module.extension}/outputFileNameMapping
 useStrictFilteringtrue/useStrictFiltering
 includes
   include*:cxf-*/include
   include*:geronimo-javamail*/include
   include*:geronimo-ws-metadata*/include
   include*:jaxb-api:jar/include
   include*:jaxb-impl:jar/include
   include*:jaxb-xjc:jar/include
   include*:jaxws-api:jar/include
   include*:jbossws-common:jar/include
   include*:jbossws-framework:jar/include
   include*:jbossws-spi:jar/include
   include*:neethi:jar/include
   include*:saaj-api:jar/include
   include*:saaj-impl:jar/include
   include*:spring-beans:jar/include
   include*:spring-context:jar/include
   include*:spring-core:jar/include
   include*:stax-api:jar/include
   include*:wsdl4j:jar/include
   include*:xml-resolver:jar/include
   include*:XmlSchema:jar/include
 /includes
   /dependencySet
   dependencySet
 outputFileNameMappingwstx.jar/outputFileNameMapping
 useStrictFilteringtrue/useStrictFiltering
 includes
   include*:wstx-asl:jar/include
 /includes
   /dependencySet
 /dependencySets
   /binaries
 /moduleSet
   /moduleSets
 
 /assembly
 [tdies...@tddell trunk]$ ls 
 target/deploy-structure-jboss422/server/default/lib/
 jbossws-cxf.${extension}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-401) Exclude with useTransitiveFiltering is excluding transitive artifacts which have ancestors in both include and exclude condition


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-401:
--

Fix Version/s: (was: 2.2)

 Exclude with useTransitiveFiltering is excluding transitive artifacts which 
 have ancestors in both include and exclude condition
 

 Key: MASSEMBLY-401
 URL: http://jira.codehaus.org/browse/MASSEMBLY-401
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-3
 Environment: maven 2.0.9
 Java 1.6.0_12
 WinXP
Reporter: Jean-Paul GUIGUI
Assignee: John Casey

 If we have the following dependencies:
 A depends of C,D
 B depends of C,E
 and if I exclude B and useTransitiveFiltering=true into the assembly 
 descriptor, then the dependency C is as well excluded. It supposed to be kept 
 since it is included from the path A as well, not only from B.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-362) Not able to include ejb-client artifact in jar-with-dependencies


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-362:
--

Fix Version/s: (was: 2.2)

 Not able to include ejb-client artifact in jar-with-dependencies
 

 Key: MASSEMBLY-362
 URL: http://jira.codehaus.org/browse/MASSEMBLY-362
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
Reporter: Henrik Brautaset Aronsen
Assignee: John Casey

 The assembly:assembly target with jar-with-dependencies does not include my 
 ejb-client dependency.  The jar dependencies are included.  I've tried 
 specifiying my own assembly.xml, but the artifact isn't included nonetheless:
 assembly.xml:
 {code}includes
includemygroup:myartifact-ejb/include
 /includes
 {code}
 pom.xml:
 {code}dependency
groupIdmygroup/groupId
artifactIdmyartifact-ejb/artifactId
typeejb-client/type
 /dependency
 {code}
 I've also tried {{mygroup:myartifact-ejb:*}}, 
 {{mygroup:myartifact-ejb:ejb-client}} and a couple of other combinations.  
 Maven still complains:
 {code}[WARNING] The following patterns were never triggered in this artifact 
 inclusion filter:
 o  'mygroup:myartifact-ejb'
 {code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-426) Inconsistant inheritance


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-426:
--

Fix Version/s: (was: 2.2)

 Inconsistant inheritance
 

 Key: MASSEMBLY-426
 URL: http://jira.codehaus.org/browse/MASSEMBLY-426
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-4
 Environment: mvn 2.0.9 jdk1.5
Reporter: fabrice
Assignee: John Casey
 Attachments: basedir.zip


 Hi
 A concret example is easy to understand :
 My superPom contains :
 pluginManagement
   plugins
 ...
   plugin
   
 artifactIdmaven-assembly-plugin/artifactId
   dependencies
   dependency
   
 groupIdcom.almerys.assemblies/groupId
   artifactId
   
 My-jar-assembly-descriptor
   /artifactId
   
 version1.0.0.0.3/version
   /dependency
   /dependencies
   executions
   execution
   idmake-assembly/id
   phasepackage/phase
   goals
   
 goalsingle/goal
   /goals
   /execution
   /executions
   /plugin
 
 /pluginManagement
 And a child project overwritte the plugin conf to specify the assembly.xml  
 that is placed in My-jar-assembly-descriptor. But In this way I can specify 
 another assembly.xml that the default (in My-jar-assembly-descriptor)
   plugin
   artifactIdmaven-assembly-plugin/artifactId  
 
   configuration
   descriptors
   descriptor
   assembly.xml
   /descriptor
   /descriptors
   /configuration
   /plugin
 I have the error bellow :
 Reason: Error reading assemblies: Error locating assembly descriptor file: 
 D:\workspace7.5\BatchAGLBPS\assembly.xml
 Ok but if in my child I add for exemple the version (anyone it does not 
 matter) it works ! assembly plugin find the assembly.xml in my-jar-descriptor 
 !
 version2.2-beta-2/version for instance
 I do not understand is a bug ?
 Fabrice
 When I do a help:effective-pom I have my maven that say it uses 2.2-beta-1 in 
 the pluginManagment section and 2.2-beta-2 in the child...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-325) Pre-defined descriptor for appassembler goodness


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-325:
--

Fix Version/s: (was: 2.2)

 Pre-defined descriptor for appassembler goodness
 

 Key: MASSEMBLY-325
 URL: http://jira.codehaus.org/browse/MASSEMBLY-325
 Project: Maven 2.x Assembly Plugin
  Issue Type: New Feature
Reporter: Paul Smith
Assignee: John Casey
Priority: Minor

 The predefined assembly descriptors are nice.  I'd love to have a built in 
 one that matched the output of the appassembler plugin, something like:
 assembly
   formats
 formattar.gz/format
   /formats
   fileSets
 fileSet
   includes
 includeREADME*/include
 includeLICENSE*/include
 includeNOTICE*/include
   /includes
 /fileSet
 fileSet
   directorytarget/appassembler/directory
   outputDirectory/outputDirectory
 /fileSet
   /fileSets
 /assembly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-480) Files with ending with a .formatted extention not cleaned up


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-480:
--

Fix Version/s: (was: 2.2)

 Files with ending with a .formatted extention not cleaned up
 

 Key: MASSEMBLY-480
 URL: http://jira.codehaus.org/browse/MASSEMBLY-480
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-5
 Environment: dev on windows, build runs on Linux
Reporter: J T
Assignee: John Casey

 In the target directory below my project directory a folder called 
 archive-tmp is created and never cleaned up. In it are directories ending in 
 .formatted and files that were being copied as part of this task ending in 
 .formatted. Also in the primary directory where the output of the build is 
 placed there are tons of .formatted files co-mingled with regular files we 
 want to output. Looking through some of the code I think the .formatted 
 extention appears to be used to create temp files as things are copied around 
 but I'm not sure why they are never being cleaned up. We use the outputed 
 files placed in the target directory so this is causing us to get a bunch of 
 unwanted files as part of our build output.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-320) Website page needs to be updated to tell us where assembly descriptor goes.


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-320:
--

Fix Version/s: (was: 2.2)

 Website page needs to be updated to tell us where assembly descriptor goes.
 ---

 Key: MASSEMBLY-320
 URL: http://jira.codehaus.org/browse/MASSEMBLY-320
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Reporter: Glen Mazza
Assignee: John Casey

 Hi, I'm a complete Maven assembly plugin newbie.  The page below[1] describes 
 an assembly descriptor, but I don't know *where* it goes--is it part of the 
 POM, or a separate file that the pom references, or...?   Please update [1] 
 to tell us that information.
 Thanks,
 Glen
 [1] 
 http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/filtering-some-distribution-files.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-443) Module Sets don't support flat hierarchy of projects


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-443:
--

Fix Version/s: (was: 2.2)

 Module Sets don't support flat hierarchy of projects
 

 Key: MASSEMBLY-443
 URL: http://jira.codehaus.org/browse/MASSEMBLY-443
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-4
Reporter: Marshall Schor
Assignee: John Casey
Priority: Minor

 If a multi-module project is using a flat hierarchy of projects, including 
 the POMs, or a mixed hierarchy, and specifying modules like:
   modules
 module../../XXXproject/module
 module../../YYYproject/module
   /modules
 the moduleSet mechanism doesn't find the modules, and nothing is included.  
 If the layout is changed to the standard hierarchical one, then the very same 
 assembly descriptor works.
 The assembly descriptor was pared down in my testing to just this:
 assembly
   idbin/id
   formats
 formattar.gz/format
 formatzip/format
   /formats
   includeBaseDirectoryfalse/includeBaseDirectory
   moduleSets
 moduleSet
   sources
 fileSets
   fileSet
 directorysrc/directory
   /fileSet
 /fileSets
   /sources
 /moduleSet
   /moduleSets
 /assembly 
 Note that the non-hierarchical (flat) layout works for all of our other maven 
 operations (except release - but I see that may have been also fixed in 
 /MRELEASE-261 - haven't tried that...)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-402) Assembly plugin goals should have a forceCreation parameter.


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-402:
--

Fix Version/s: (was: 2.2)

 Assembly plugin goals should have a forceCreation parameter.
 

 Key: MASSEMBLY-402
 URL: http://jira.codehaus.org/browse/MASSEMBLY-402
 Project: Maven 2.x Assembly Plugin
  Issue Type: New Feature
Reporter: Paul Gier
Assignee: John Casey

 Assembly jars are created every time whether or not the files contained in 
 them have been updated.  There should be a plugin parameter called 
 forceCreation similar to the jar plugin and source plugin that determines 
 if the assemblies should only be created when there have been updates to the 
 files.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-470) skipAssembly doesn't work for directory based mojos


 [ 
http://jira.codehaus.org/browse/MASSEMBLY-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MASSEMBLY-470:
--

Fix Version/s: (was: 2.2)

 skipAssembly doesn't work for directory based mojos
 ---

 Key: MASSEMBLY-470
 URL: http://jira.codehaus.org/browse/MASSEMBLY-470
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-5
Reporter: Mike Mansell
Assignee: John Casey
 Attachments: skipAssembly-directory.patch


 The skipAssembly property is only used within the execute method of the 
 AbstractAssemblyMojo. However, the AbstractDirectoryMojo overrides (and 
 doesn't call) the execute. Unfortunately, this overridden execute doesn't 
 respect the skipAssembly variable. Therefore, the directory based mojos 
 (directory-inline, directory and directory-single) can't be skipped.
 This is a simple fix and the patch is included.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MASSEMBLY-459) Assembly descriptors should be loaded from standard location.

2010-10-01 Thread Emerson Farrugia (JIRA)


[ 
http://jira.codehaus.org/browse/MASSEMBLY-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237096#action_237096
 ] 

Emerson Farrugia commented on MASSEMBLY-459:


I'm not sure I follow. If the src/main/assembly directory is the advertised 
location of assembly descriptors, it should probably also be the default 
location for component descriptors. I fail to see why 

plugin
  artifactIdmaven-assembly-plugin/artifactId
  configuration
descriptors
  descriptorfile.xml/descriptor
/descriptors
  /configuration
/plugin

would look for file.xml in ${basedir} instead of in 
${basedir}/src/main/assembly. 

 Assembly descriptors should be loaded from standard location.
 -

 Key: MASSEMBLY-459
 URL: http://jira.codehaus.org/browse/MASSEMBLY-459
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
Affects Versions: 2.2-beta-5
Reporter: Emerson Farrugia
Assignee: John Casey
Priority: Minor

 The Maven standard directory layout uses src/main/assembly as the location 
 for assembly descriptors. 
 (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html)
 The maven-assembly-plugin does not search this directory at all (let alone 
 first) for descriptor files. Should we be able to put file.xml in that 
 location, specify file.xml in the plugin configuration, and trust in 
 conventions that the plugin will find it?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DOXIA-413) Missing image is only logged as debug - should be error!

2010-10-01 Thread Michael Wenig (JIRA)


[ 
http://jira.codehaus.org/browse/DOXIA-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237097#action_237097
 ] 

Michael Wenig commented on DOXIA-413:
-

Thnaks Lukas,

now there is a real error message:

[INFO] [doxia:render-books {execution: default}]
[WARNING] [iText Sink] No image 
'/software/hudson/slave-1/data/workspace/de.wwag.infra.oocsd~projectadmin~B-trunk~site/modules/projectadmin-_doku/target/generated-site/pdf/book-userDoku/ui_namespace_New.png'
 found in your system, check the path. [INFO] 
 
[ERROR] FATAL ERROR [INFO] 
 [INFO] 
The URL of the image is missing. [INFO] 
 

Thanks for your work!

Regards

Michael

 Missing image is only logged as debug - should be error!
 

 Key: DOXIA-413
 URL: http://jira.codehaus.org/browse/DOXIA-413
 Project: Maven Doxia
  Issue Type: Bug
  Components: Book, Module - Itext
Affects Versions: 1.1.3
Reporter: Michael Wenig
Assignee: Lukas Theussl
 Fix For: 1.1.4


 I have a project which uses doxia to create books in html, pdf and rtf.
 My development is on Windows, CI is on Linux.
 Accidently I added an image and referenced it in the apt-sources with a wrong 
 case.
 The local build works fine (as windows is case-insensitive) but the central 
 build fails (as expected)
 Unfortunately I cannot see the problem unless I activate the Debug (!) mode:
 This error should be logged as error and not as debug as it denotes a serious 
 problem and leads directly to the solution of the problem
 [DEBUG] [iText Sink] No image 
 '/software/hudson/slave-1/data/workspace/de.wwag.infra.oocsd~projectadmin~B-trunk~site/modules/projectadmin-_doku/target/generated-site/pdf/book-userDoku/ui_natureMaven_updateParentPOM.png'
  found in your system, check the path.
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] The URL of the image is missing.
 [INFO] 
 
 [DEBUG] Trace
 ExceptionConverter: java.net.MalformedURLException: The URL of the image is 
 missing.
   at com.lowagie.text.Image.getInstance(Unknown Source)
   at com.lowagie.text.xml.SAXiTextHandler.handleStartingTags(Unknown 
 Source)
   at com.lowagie.text.xml.SAXiTextHandler.startElement(Unknown Source)
   at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
 Source)
   at 
 org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown 
 Source)
   at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
  Source)
   at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
  Source)
   at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
 Source)
   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
   at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
   at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
   at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
 Source)
   at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
   at com.lowagie.text.xml.XmlParser.go(Unknown Source)
   at com.lowagie.text.xml.XmlParser.parse(Unknown Source)
   at com.lowagie.text.xml.XmlToXXX.parse(Unknown Source)
   at 
 org.apache.maven.doxia.module.itext.ITextUtil.writePdf(ITextUtil.java:132)
   at 
 org.apache.maven.doxia.book.services.renderer.PdfBookRenderer.renderXML(PdfBookRenderer.java:50)
   at 
 org.apache.maven.doxia.book.services.renderer.AbstractITextBookRenderer.renderBook(AbstractITextBookRenderer.java:165)
   at 
 org.apache.maven.doxia.book.DefaultBookDoxia.renderBook(DefaultBookDoxia.java:142)
   at 
 org.apache.maven.doxia.plugin.DoxiaRenderBooksMojo.execute(DoxiaRenderBooksMojo.java:265)
   at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
   at 
 hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:182)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
   at

[jira] Issue Comment Edited: (DOXIA-413) Missing image is only logged as debug - should be error!

2010-10-01 Thread Michael Wenig (JIRA)


[ 
http://jira.codehaus.org/browse/DOXIA-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237097#action_237097
 ] 

Michael Wenig edited comment on DOXIA-413 at 10/1/10 6:23 AM:
--

Thanks Lukas,

now there is a real error message:

[INFO] [doxia:render-books {execution: default}]
[WARNING] [iText Sink] No image 
'/software/hudson/slave-1/data/workspace/de.wwag.infra.oocsd~projectadmin~B-trunk~site/modules/projectadmin-_doku/target/generated-site/pdf/book-userDoku/ui_namespace_New.png'
 found in your system, check the path. [INFO] 
 
[ERROR] FATAL ERROR [INFO] 
 [INFO] 
The URL of the image is missing. [INFO] 
 

Thanks for your work!

Regards

Michael

  was (Author: micha123):
Thnaks Lukas,

now there is a real error message:

[INFO] [doxia:render-books {execution: default}]
[WARNING] [iText Sink] No image 
'/software/hudson/slave-1/data/workspace/de.wwag.infra.oocsd~projectadmin~B-trunk~site/modules/projectadmin-_doku/target/generated-site/pdf/book-userDoku/ui_namespace_New.png'
 found in your system, check the path. [INFO] 
 
[ERROR] FATAL ERROR [INFO] 
 [INFO] 
The URL of the image is missing. [INFO] 
 

Thanks for your work!

Regards

Michael
  
 Missing image is only logged as debug - should be error!
 

 Key: DOXIA-413
 URL: http://jira.codehaus.org/browse/DOXIA-413
 Project: Maven Doxia
  Issue Type: Bug
  Components: Book, Module - Itext
Affects Versions: 1.1.3
Reporter: Michael Wenig
Assignee: Lukas Theussl
 Fix For: 1.1.4


 I have a project which uses doxia to create books in html, pdf and rtf.
 My development is on Windows, CI is on Linux.
 Accidently I added an image and referenced it in the apt-sources with a wrong 
 case.
 The local build works fine (as windows is case-insensitive) but the central 
 build fails (as expected)
 Unfortunately I cannot see the problem unless I activate the Debug (!) mode:
 This error should be logged as error and not as debug as it denotes a serious 
 problem and leads directly to the solution of the problem
 [DEBUG] [iText Sink] No image 
 '/software/hudson/slave-1/data/workspace/de.wwag.infra.oocsd~projectadmin~B-trunk~site/modules/projectadmin-_doku/target/generated-site/pdf/book-userDoku/ui_natureMaven_updateParentPOM.png'
  found in your system, check the path.
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] The URL of the image is missing.
 [INFO] 
 
 [DEBUG] Trace
 ExceptionConverter: java.net.MalformedURLException: The URL of the image is 
 missing.
   at com.lowagie.text.Image.getInstance(Unknown Source)
   at com.lowagie.text.xml.SAXiTextHandler.handleStartingTags(Unknown 
 Source)
   at com.lowagie.text.xml.SAXiTextHandler.startElement(Unknown Source)
   at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown 
 Source)
   at 
 org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown 
 Source)
   at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
  Source)
   at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
  Source)
   at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
 Source)
   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
   at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
   at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
   at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown 
 Source)
   at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
   at com.lowagie.text.xml.XmlParser.go(Unknown Source)
   at com.lowagie.text.xml.XmlParser.parse(Unknown Source)
   at com.lowagie.text.xml.XmlToXXX.parse(Unknown Source)
   at 
 org.apache.maven.doxia.module.itext.ITextUtil.writePdf(ITextUtil.java:132)
   at 
 org.apache.maven.doxia.book.services.renderer.PdfBookRenderer.renderXML(PdfBookRenderer.java:50)
   at

[jira] Created: (MANTRUN-155) Encoding issue with created build-main.xml

2010-10-01 Thread Anders Hammar (JIRA)

Encoding issue with created build-main.xml
--

 Key: MANTRUN-155
 URL: http://jira.codehaus.org/browse/MANTRUN-155
 Project: Maven 2.x Antrun Plugin
  Issue Type: Bug
Affects Versions: 1.5
 Environment: Windows XP SP2
Sun JDK 1.6.0_16
Maven 3.0-RC2
Reporter: Anders Hammar
 Attachments: antrun_error.log

Having non-ASCII chars in the antrun configuration breaks the build. The reason 
seems to be that the created build-main.xml is in the os default encoding, 
while the project is configured with another encoding. It works with m-antrun-p 
v1.4.

I've attached a log of the error message.

Could this issue be related to the refactoring done in MANTRUN-142?


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MNG-4845) [regression] MavenProject.getDependencyArtifact() returns artifacts without version for dependency with version range

2010-10-01 Thread Benjamin Bentmann (JIRA)


 [ 
http://jira.codehaus.org/browse/MNG-4845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bentmann updated MNG-4845:
---

Description: 
For a dependency using a version range, the corresponding artifact in 
{{MavenProject.getDependencyArtifacts()}} has no resolved version.

Concrete case that exhibits this bug is {{mvn versions:resolve-ranges}}.

  was:For a dependency using a version range, the corresponding artifact in 
{{MavenProject.getDependencyArtifacts()}} has no resolved version.


 [regression] MavenProject.getDependencyArtifact() returns artifacts without 
 version for dependency with version range
 -

 Key: MNG-4845
 URL: http://jira.codehaus.org/browse/MNG-4845
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.0-beta-3
Reporter: Benjamin Bentmann

 For a dependency using a version range, the corresponding artifact in 
 {{MavenProject.getDependencyArtifacts()}} has no resolved version.
 Concrete case that exhibits this bug is {{mvn versions:resolve-ranges}}.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MNG-4845) [regression] MavenProject.getDependencyArtifact() returns artifacts without version for dependency with version range

2010-10-01 Thread Benjamin Bentmann (JIRA)

[regression] MavenProject.getDependencyArtifact() returns artifacts without 
version for dependency with version range
-

 Key: MNG-4845
 URL: http://jira.codehaus.org/browse/MNG-4845
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.0-beta-3
Reporter: Benjamin Bentmann


For a dependency using a version range, the corresponding artifact in 
{{MavenProject.getDependencyArtifacts()}} has no resolved version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MNG-4845) [regression] MavenProject.getDependencyArtifact() returns artifacts without version for dependency with version range

2010-10-01 Thread Benjamin Bentmann (JIRA)


 [ 
http://jira.codehaus.org/browse/MNG-4845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bentmann closed MNG-4845.
--

   Resolution: Fixed
Fix Version/s: 3.0
 Assignee: Benjamin Bentmann

Fixed in [r1003537|http://svn.apache.org/viewvc?view=revisionrevision=1003537].

 [regression] MavenProject.getDependencyArtifact() returns artifacts without 
 version for dependency with version range
 -

 Key: MNG-4845
 URL: http://jira.codehaus.org/browse/MNG-4845
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.0-beta-3
Reporter: Benjamin Bentmann
Assignee: Benjamin Bentmann
 Fix For: 3.0


 For a dependency using a version range, the corresponding artifact in 
 {{MavenProject.getDependencyArtifacts()}} has no resolved version.
 Concrete case that exhibits this bug is {{mvn versions:resolve-ranges}}.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MRELEASE-602) Repositories defined in a profile are ignored while processing dependency management pom imports in a pom resolved from the repository

2010-10-01 Thread Pedro Rodriguez (JIRA)

Repositories defined in a profile are ignored while processing dependency 
management pom imports in a pom resolved from the repository
--

 Key: MRELEASE-602
 URL: http://jira.codehaus.org/browse/MRELEASE-602
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
  Components: prepare
Affects Versions: 2.0
Reporter: Pedro Rodriguez


We define the repositories in a profile.

The dependency management resolution fails to resolve a pom import if the 
import occurs 
in an imported pom not found in the reactor.  

The following code fragment shows the problem: 

While merging managed dependencies of a dependency resolved from the 
repository, 
the ProjectBuilderConfiguration that is used do not contain the 
ProfileManager.  
   


Class: org.apache.maven.project.DefaultMavenProjectBuilder

mergeManagedDependencies(...) 

...
if ( dep.getType().equals( pom )
  Artifact.SCOPE_IMPORT.equals( dep.getScope() ) )
{
Artifact artifact = 
artifactFactory.createProjectArtifact( dep.getGroupId(), dep.getArtifactId(),

  dep.getVersion(), dep.getScope() );
MavenProject project = buildFromRepository(artifact, 
parentSearchRepositories, localRepository, false);

DependencyManagement depMgmt = 
project.getDependencyManagement();

...


buildFromRepository(...) 

...
Model model = findModelFromRepository( artifact, 
remoteArtifactRepositories, localRepository, allowStubModel );

ProjectBuilderConfiguration config = new 
DefaultProjectBuilderConfiguration().setLocalRepository( localRepository );

return buildInternal( Artifact [ + artifact + ], model, config, 
remoteArtifactRepositories,
  null, false );



buildInternal( ... )

...
ProfileManager externalProfileManager = 
config.getGlobalProfileManager();

...

Set aggregatedRemoteWagonRepositories = new LinkedHashSet();

List activeExternalProfiles;

if ( externalProfileManager != null )
{
activeExternalProfiles = 
externalProfileManager.getActiveProfiles();
}
else
{
activeExternalProfiles = Collections.EMPTY_LIST;
}


for ( Iterator i = activeExternalProfiles.iterator(); i.hasNext(); )
{
Profile externalProfile = (Profile) i.next();

for ( Iterator repoIterator = 
externalProfile.getRepositories().iterator(); repoIterator.hasNext(); )
{
Repository mavenRepo = (Repository) repoIterator.next();

ArtifactRepository artifactRepo = artifactRepo =
ProjectUtils.buildArtifactRepository( mavenRepo, 
artifactRepositoryFactory, container );

aggregatedRemoteWagonRepositories.add( artifactRepo );
}
}


Because the GlobalProfileManager was not specified in the 
DefaultProjectBuilderConfiguration, 
the activeExternalProfiles list is empty and all remote repositories are 
ignored. 



In general, the ProjectBuilderConfiguration is created with a factory method 
which correctly set the GlobalProfileManager. 


org.apache.maven.execution.DefaultMavenExecutionRequest

public ProjectBuilderConfiguration getProjectBuilderConfiguration()
{
ProjectBuilderConfiguration config = new 
DefaultProjectBuilderConfiguration();
config.setLocalRepository( getLocalRepository() )
  .setGlobalProfileManager( getGlobalProfileManager() )
  .setExecutionProperties( getExecutionProperties() )
  .setUserProperties( getUserProperties() )
  .setBuildStartTime( startTime );

return config;
}



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3309) Is it possible to trigger profiles from profiles


[ 
http://jira.codehaus.org/browse/MNG-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237147#action_237147
 ] 

Vladimir Konkov commented on MNG-3309:
--

Current implementation is useles in real projects. Below the simple example:
from pom.xml:

profiles
profile
iddb-mysql/id
activation
property
namedb.type/name
valuemysql/value
/property
/activation
properties
db.driverMySQL/db.driver
/properties
/profile
profile
iddb-postgre/id
activation
property
namedb.type/name
valuepostgresql/value
/property
/activation
properties
db.hostPostgreSQL/db.host
/properties
/profile
profile
idprod/id
properties
db.typepostgresql/db.type
server.typetomcat/server.type
/properties
/profile
/profiles

$ mvn3 package -P prod 

Property db.host are'nt set.

I can't move that logic into settings because it's project scope. I've minimum 
3 dimensions of profiles (db,app server,data dir) in my projects and as now is 
no way to implement effective buid process with maven.

Maven is near it 3 version but missed some critical future: profile activation 
by other profile. It's so simple and so essential future... (I now about 
MNG-2276)

PS: Is there any questions why big multienviroment projects (Alfresco, Liferay 
etc) not moved to maven until now?


 Is it possible to trigger profiles from profiles
 

 Key: MNG-3309
 URL: http://jira.codehaus.org/browse/MNG-3309
 Project: Maven 2  3
  Issue Type: New Feature
Affects Versions: 2.0.7
Reporter: Andreas Höhmann
 Fix For: 3.x / Backlog


 I want include profiles from profiles ... a example ... please tell me if 
 this is nonsense :-)
 profiles
 !-- my default-profile ... this profile defines properties  so i try 
 to include other property-triggered-profiles --
 profile
   iddefault/id
   activation
 activeByDefaulttrue/activeByDefault
   /activation
   properties
 !-- include profile tomcat6 --
 tomcat6/tomcat
 !-- include profile myfaces12 --
 jsfmyfaces12/jsf
!-- include profile richfaces --
 richfacestrue/richfaces
!-- don't include profile seam --
 seamfalse/seam
   /properties
 /profile
 profile
   !-- 
 JBoss Seam JSF framework : -Dseam=yes 
   --
   idseam/id
   activation
 activeByDefaultfalse/activeByDefault
 property
   nameseam/name
   valuetrue/value
 /property
   /activation
   ...
 /profile
 profile
   !-- 
 JBoss Richfaces Component Lib for JSF : -Drichfaces=true 
   --
   idrichfaces/id
   activation
 activeByDefaultfalse/activeByDefault
 property
   namerichfaces/name
   valuetrue/value
 /property
   /activation
   ...
 /profile
 profile
   !-- 
 MyFaces JSF Implementation 1.2 : -Djsf=myfaces12 
   --
   idmyfaces12/id
   activation
 activeByDefaultfalse/activeByDefault
 property
   namejsf/name
   valuemyfaces12/value
 /property
   /activation
   ...
 /profile
 profile
   !-- 
 MyFaces JSF Implementation 1.1 : -Djsf=myfaces11 
   --
   idmyfaces11/id
   activation
 activeByDefaultfalse/activeByDefault
 property
   namejsf/name
   valuemyfaces11/value
 /property
   /activation
   ...
 /profile
 profile
   !-- 
 Sun's JSF Reference Implementation 1.2 : -Djsf=ri12
   --
   idjsfri12/id
   activation
 activeByDefaultfalse/activeByDefault
 property
   namejsf/name
   valueri12/value
 /property
   /activation
   
 /profile
 profile
   !-- 
 Tomcat 5.x Environment : -Dtomcat=5
   --
   idtomcat5/id
   activation
 activeByDefaultfalse/activeByDefault
 property
   nametomcat/name
   value5/value
 /property
   /activation
   build
 defaultGoaljetty:run/defaultGoal
   /build
   dependencies
 dependency
   groupIdjavax.servlet/groupId
   artifactIdservlet-api/artifactId
   version2.4/version
   scopeprovided/scope
 /dependency
 dependency
   groupIdjavax.servlet.jsp/groupId

[jira] Issue Comment Edited: (MNG-3309) Is it possible to trigger profiles from profiles


[ 
http://jira.codehaus.org/browse/MNG-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237147#action_237147
 ] 

Vladimir Konkov edited comment on MNG-3309 at 10/1/10 9:15 AM:
---

Current implementation is useles in real projects. Below the simple example:
from pom.xml:

profiles
profile
iddb-mysql/id
activation
property
namedb.type/name
valuemysql/value
/property
/activation
properties
db.driverMySQL/db.driver
/properties
/profile
profile
iddb-postgre/id
activation
property
namedb.type/name
valuepostgresql/value
/property
/activation
properties
db.hostPostgreSQL/db.host
/properties
/profile
profile
idprod/id
properties
db.typepostgresql/db.type
server.typetomcat/server.type
/properties
/profile
/profiles

$ mvn3 package -P prod 

Property db.host are'nt set.

I can't move that logic into settings because it's project scope. I've minimum 
3 dimensions of profiles (db,app server,data dir) in my projects and as now is 
no way to implement effective buid process with maven.

Maven is near it 3 version but missed some critical future: profile activation 
by other profile. It's so simple and so essential future... (I now about 
MNG-3309)

PS: Is there any questions why big multienviroment projects (Alfresco, Liferay 
etc) not moved to maven until now?


  was (Author: vladimirfx):
Current implementation is useles in real projects. Below the simple example:
from pom.xml:

profiles
profile
iddb-mysql/id
activation
property
namedb.type/name
valuemysql/value
/property
/activation
properties
db.driverMySQL/db.driver
/properties
/profile
profile
iddb-postgre/id
activation
property
namedb.type/name
valuepostgresql/value
/property
/activation
properties
db.hostPostgreSQL/db.host
/properties
/profile
profile
idprod/id
properties
db.typepostgresql/db.type
server.typetomcat/server.type
/properties
/profile
/profiles

$ mvn3 package -P prod 

Property db.host are'nt set.

I can't move that logic into settings because it's project scope. I've minimum 
3 dimensions of profiles (db,app server,data dir) in my projects and as now is 
no way to implement effective buid process with maven.

Maven is near it 3 version but missed some critical future: profile activation 
by other profile. It's so simple and so essential future... (I now about 
MNG-2276)

PS: Is there any questions why big multienviroment projects (Alfresco, Liferay 
etc) not moved to maven until now?

  
 Is it possible to trigger profiles from profiles
 

 Key: MNG-3309
 URL: http://jira.codehaus.org/browse/MNG-3309
 Project: Maven 2  3
  Issue Type: New Feature
Affects Versions: 2.0.7
Reporter: Andreas Höhmann
 Fix For: 3.x / Backlog


 I want include profiles from profiles ... a example ... please tell me if 
 this is nonsense :-)
 profiles
 !-- my default-profile ... this profile defines properties  so i try 
 to include other property-triggered-profiles --
 profile
   iddefault/id
   activation
 activeByDefaulttrue/activeByDefault
   /activation
   properties
 !-- include profile tomcat6 --
 tomcat6/tomcat
 !-- include profile myfaces12 --
 jsfmyfaces12/jsf
!-- include profile richfaces --
 richfacestrue/richfaces
!-- don't include profile seam --
 seamfalse/seam
   /properties
 /profile
 profile
   !-- 
 JBoss Seam JSF framework : -Dseam=yes 
   --
   idseam/id
   activation
 activeByDefaultfalse/activeByDefault
 property
   nameseam/name
   valuetrue/value
 /property
   /activation
   ...
 /profile
 profile
   !-- 
 JBoss Richfaces Component Lib for JSF : -Drichfaces=true 
   --
   idrichfaces/id
   activation
 activeByDefaultfalse/activeByDefault
 property
   namerichfaces/name
   valuetrue/value
 /property
   /activation
   ...

[jira] Issue Comment Edited: (MNG-3309) Is it possible to trigger profiles from profiles


[ 
http://jira.codehaus.org/browse/MNG-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237147#action_237147
 ] 

Vladimir Konkov edited comment on MNG-3309 at 10/1/10 9:24 AM:
---

Current implementation with properties is useles in real projects. Below the 
simple example:
from pom.xml:

profiles
profile
iddb-mysql/id
activation
property
namedb.type/name
valuemysql/value
/property
/activation
properties
db.driverMySQL/db.driver
/properties
/profile
profile
iddb-postgre/id
activation
property
namedb.type/name
valuepostgresql/value
/property
/activation
properties
db.hostPostgreSQL/db.host
/properties
/profile
profile
idprod/id
properties
db.typepostgresql/db.type
server.typetomcat/server.type
/properties
/profile
/profiles

$ mvn3 package -P prod 

Property db.host are'nt set.

I can't move that logic into settings because it's project scope. I've minimum 
3 dimensions of profiles (db,app server,data dir) in my projects and as now is 
no way to implement effective buid process with maven.

Maven is near it 3 version but missed some critical future: profile activation 
by other profile. It's so simple and so essential future...

PS: Is there any questions why big multienviroment projects (Alfresco, Liferay 
etc) not moved to maven until now?


  was (Author: vladimirfx):
Current implementation is useles in real projects. Below the simple example:
from pom.xml:

profiles
profile
iddb-mysql/id
activation
property
namedb.type/name
valuemysql/value
/property
/activation
properties
db.driverMySQL/db.driver
/properties
/profile
profile
iddb-postgre/id
activation
property
namedb.type/name
valuepostgresql/value
/property
/activation
properties
db.hostPostgreSQL/db.host
/properties
/profile
profile
idprod/id
properties
db.typepostgresql/db.type
server.typetomcat/server.type
/properties
/profile
/profiles

$ mvn3 package -P prod 

Property db.host are'nt set.

I can't move that logic into settings because it's project scope. I've minimum 
3 dimensions of profiles (db,app server,data dir) in my projects and as now is 
no way to implement effective buid process with maven.

Maven is near it 3 version but missed some critical future: profile activation 
by other profile. It's so simple and so essential future... (I now about 
MNG-3309)

PS: Is there any questions why big multienviroment projects (Alfresco, Liferay 
etc) not moved to maven until now?

  
 Is it possible to trigger profiles from profiles
 

 Key: MNG-3309
 URL: http://jira.codehaus.org/browse/MNG-3309
 Project: Maven 2  3
  Issue Type: New Feature
Affects Versions: 2.0.7
Reporter: Andreas Höhmann
 Fix For: 3.x / Backlog


 I want include profiles from profiles ... a example ... please tell me if 
 this is nonsense :-)
 profiles
 !-- my default-profile ... this profile defines properties  so i try 
 to include other property-triggered-profiles --
 profile
   iddefault/id
   activation
 activeByDefaulttrue/activeByDefault
   /activation
   properties
 !-- include profile tomcat6 --
 tomcat6/tomcat
 !-- include profile myfaces12 --
 jsfmyfaces12/jsf
!-- include profile richfaces --
 richfacestrue/richfaces
!-- don't include profile seam --
 seamfalse/seam
   /properties
 /profile
 profile
   !-- 
 JBoss Seam JSF framework : -Dseam=yes 
   --
   idseam/id
   activation
 activeByDefaultfalse/activeByDefault
 property
   nameseam/name
   valuetrue/value
 /property
   /activation
   ...
 /profile
 profile
   !-- 
 JBoss Richfaces Component Lib for JSF : -Drichfaces=true 
   --
   idrichfaces/id
   activation
 activeByDefaultfalse/activeByDefault
 property
   namerichfaces/name
   valuetrue/value
 /property
   /activation
   ...

[jira] Issue Comment Edited: (MNG-3309) Is it possible to trigger profiles from profiles


[ 
http://jira.codehaus.org/browse/MNG-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237147#action_237147
 ] 

Vladimir Konkov edited comment on MNG-3309 at 10/1/10 9:26 AM:
---

Current implementation with properties (MNG-2276) is useles in real projects. 
Below the simple example:
from pom.xml:

profiles
profile
iddb-mysql/id
activation
property
namedb.type/name
valuemysql/value
/property
/activation
properties
db.driverMySQL/db.driver
/properties
/profile
profile
iddb-postgre/id
activation
property
namedb.type/name
valuepostgresql/value
/property
/activation
properties
db.hostPostgreSQL/db.host
/properties
/profile
profile
idprod/id
properties
db.typepostgresql/db.type
server.typetomcat/server.type
/properties
/profile
/profiles

$ mvn3 package -P prod 

Property db.host are'nt set.

I can't move that logic into settings because it's project scope. I've minimum 
3 dimensions of profiles (db,app server,data dir) in my projects and as now is 
no way to implement effective buid process with maven.

Maven is near it 3 version but missed some critical future: profile activation 
by other profile. It's so simple and so essential future...

PS: Is there any questions why big multienviroment projects (Alfresco, Liferay 
etc) not moved to maven until now?


  was (Author: vladimirfx):
Current implementation with properties is useles in real projects. Below 
the simple example:
from pom.xml:

profiles
profile
iddb-mysql/id
activation
property
namedb.type/name
valuemysql/value
/property
/activation
properties
db.driverMySQL/db.driver
/properties
/profile
profile
iddb-postgre/id
activation
property
namedb.type/name
valuepostgresql/value
/property
/activation
properties
db.hostPostgreSQL/db.host
/properties
/profile
profile
idprod/id
properties
db.typepostgresql/db.type
server.typetomcat/server.type
/properties
/profile
/profiles

$ mvn3 package -P prod 

Property db.host are'nt set.

I can't move that logic into settings because it's project scope. I've minimum 
3 dimensions of profiles (db,app server,data dir) in my projects and as now is 
no way to implement effective buid process with maven.

Maven is near it 3 version but missed some critical future: profile activation 
by other profile. It's so simple and so essential future...

PS: Is there any questions why big multienviroment projects (Alfresco, Liferay 
etc) not moved to maven until now?

  
 Is it possible to trigger profiles from profiles
 

 Key: MNG-3309
 URL: http://jira.codehaus.org/browse/MNG-3309
 Project: Maven 2  3
  Issue Type: New Feature
Affects Versions: 2.0.7
Reporter: Andreas Höhmann
 Fix For: 3.x / Backlog


 I want include profiles from profiles ... a example ... please tell me if 
 this is nonsense :-)
 profiles
 !-- my default-profile ... this profile defines properties  so i try 
 to include other property-triggered-profiles --
 profile
   iddefault/id
   activation
 activeByDefaulttrue/activeByDefault
   /activation
   properties
 !-- include profile tomcat6 --
 tomcat6/tomcat
 !-- include profile myfaces12 --
 jsfmyfaces12/jsf
!-- include profile richfaces --
 richfacestrue/richfaces
!-- don't include profile seam --
 seamfalse/seam
   /properties
 /profile
 profile
   !-- 
 JBoss Seam JSF framework : -Dseam=yes 
   --
   idseam/id
   activation
 activeByDefaultfalse/activeByDefault
 property
   nameseam/name
   valuetrue/value
 /property
   /activation
   ...
 /profile
 profile
   !-- 
 JBoss Richfaces Component Lib for JSF : -Drichfaces=true 
   --
   idrichfaces/id
   activation
 activeByDefaultfalse/activeByDefault
 property
   namerichfaces/name
   valuetrue/value
 /property
   /activation
   ...

[jira] Commented: (MAVENUPLOAD-2776) Version 2.3-jdk15 of UISpec4J

2010-10-01 Thread Marcin Zajaczkowski (JIRA)


[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237153#action_237153
 ] 

Marcin Zajaczkowski commented on MAVENUPLOAD-2776:
--

Is there any problem with that upload? I cannot find version 2.3 in any repo 
(codehaus and central).

 Version 2.3-jdk15 of UISpec4J
 -

 Key: MAVENUPLOAD-2776
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2776
 Project: Maven Upload Requests
  Issue Type: New Feature
Reporter: Pascal Pratmarty

 UISpec4J is an Open Source functional and/or unit testing library for 
 Swing-based Java applications, built on top of the JUnit and TestNG test 
 harnesses.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MPIR-205) Add the license information for each dependency

2010-10-01 Thread Matthew Smith (JIRA)

Add the license information for each dependency
---

 Key: MPIR-205
 URL: http://jira.codehaus.org/browse/MPIR-205
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: New Feature
Affects Versions: 2.1
Reporter: Matthew Smith
 Attachments: patch

The current Dependency report includes tables for the dependencies that include 
GroupId,ArtifactId, Version, Classifier,Type.  This patch will include a 
License column to the tables.  The License will also be a link making it easier 
to relate licenses to atrifacts.  The License section of the document is 
affected.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MANTRUN-155) Encoding issue with created build-main.xml

2010-10-01 Thread Anders Hammar (JIRA)


 [ 
http://jira.codehaus.org/browse/MANTRUN-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anders Hammar updated MANTRUN-155:
--

Attachment: mantrun-155.zip

Attached a test project that reproduces this issue on MacOS 10.6.4, with Mac 
Java 1.6.0 and Maven 3.0-RC3. I haven't tested, but it should also reproduce on 
Windows.

 Encoding issue with created build-main.xml
 --

 Key: MANTRUN-155
 URL: http://jira.codehaus.org/browse/MANTRUN-155
 Project: Maven 2.x Antrun Plugin
  Issue Type: Bug
Affects Versions: 1.5
 Environment: Windows XP SP2
 Sun JDK 1.6.0_16
 Maven 3.0-RC2
Reporter: Anders Hammar
 Attachments: antrun_error.log, mantrun-155.zip


 Having non-ASCII chars in the antrun configuration breaks the build. The 
 reason seems to be that the created build-main.xml is in the os default 
 encoding, while the project is configured with another encoding. It works 
 with m-antrun-p v1.4.
 I've attached a log of the error message.
 Could this issue be related to the refactoring done in MANTRUN-142?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MANTRUN-152) Embedded task attachartifact does not work without classifier


 [ 
http://jira.codehaus.org/browse/MANTRUN-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Gier closed MANTRUN-152.
-

   Resolution: Fixed
Fix Version/s: 1.6
 Assignee: Paul Gier

Patch applied in 
[r1003618|http://svn.apache.org/viewvc?view=revisionrevision=1003618].  Thanks!

 Embedded task attachartifact does not work without classifier
 ---

 Key: MANTRUN-152
 URL: http://jira.codehaus.org/browse/MANTRUN-152
 Project: Maven 2.x Antrun Plugin
  Issue Type: Bug
Affects Versions: 1.3, 1.4, 1.5
 Environment: Java 5, Maven 2.2.1
Reporter: Petr Kozelka
Assignee: Paul Gier
 Fix For: 1.6

 Attachments: MANTRUN-attachartifact-unclassified.patch


 cause: use this task without specifying classifier attribute
 symptom: your file will not be copied to local repo during install phase
 h4. the bug
 The reason apparently is that this case has special handling in 
 AttachArtifactTask.java, and this handling has following problems:
 - uses {{mavenProject.getArtifact().setFile( file );}} which apparently does 
 not result in the artifact being considered the project artifact, neither 
 being attached
 - even if it worked, this implementation would not work for multiple 
 unclassified artifacts (the latest would always win)
 - the name attachartifact implies attaching, not declaring project artifact
 h4. a workarround
 Before this gets fixed, the workarround is to use 
 http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html 
 as a subsequent mojo execution
 h4. the fix, patch contents
 The attached patch includes:
 # fix in code that just removes the conditionality for {{classifier==null}}
 -- _compatibility is IMHO not a problem, because this part was not working 
 anyway_
 # integration test enhancement - to check the attachartifact functionality 
 without classifier
 To see the incorrect behavior, just use the pom from integration test 
 {{src/it/attach-artifact-test/pom.xml}} and remove the classifier artifact; 
 the build log of that test will then show that the zip is really not copied 
 by install mojo.
 h4. attached vs. Project artifact
 Concerning the (nonfunctional) attempt to declare the file as project 
 artifact: IMHO it is not a good thing at all.
 Even if the abovementioned problem with overriding was solved, I would expect 
 the task to do what its name indicates, and nothing else.
 Well, I am not aware of any important differences between having project 
 artifact and having the same artifact as attached (I should read something 
 about it...), but in any case, I would prefer to have some control over this 
 different behavior.
 For instance, adding attribute {{projectArtifact=true}} can indicate that 
 setting project artifact is the desired action.
 Another approach, maybe even cleaner, would be to define a separate task (or 
 better, configuration param) just for this purpose.
 h4. thoughts on merging build-helper approach
 What I really like about the embedded attachartifact task is, I don't need to 
 *invoke separate mojo* (build-helper:attach-artifact).
 For me, creating something with ant piece and attaching it to project is the 
 most common usecase of antrun plugin.
 Therefore I have the feeling that it should be treated specially - I mean, 
 the way used in build-helper:attach-artifact mojo.
 Really, the attaching action is something different from normal tasks; it 
 does not do anything visible to subsequent tasks, just enhances the 
 internal declaration of the project... but we have POM for such things, right 
 ?
 So, wouldn't it be better to *copy the functionality of 
 build-helper:attach-artifact here ?* Perhaps the anttask attachartifact 
 should still exist, for some rare cases like conditional/parameterized 
 attachments; but the preferred way would be the (declarative) maven way - 
 maybe this is worth separate issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MINSTALL-79) install:install should remove leftovers from local repository


 [ 
http://jira.codehaus.org/browse/MINSTALL-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Gier closed MINSTALL-79.
-

Resolution: Duplicate

 install:install should remove leftovers from local repository
 -

 Key: MINSTALL-79
 URL: http://jira.codehaus.org/browse/MINSTALL-79
 Project: Maven 2.x Install Plugin
  Issue Type: Bug
Reporter: Petr Kozelka
 Attachments: pom.xml


 It happens that we need to change the set of output artifacts. When this 
 happens, the install mojo does not bother to remove older artifacts that are 
 no longer produced by this module.
 The bad effect is, that other modules depending on the obsolete artifacts can 
 still use it. Much better behavior in this situation would be, to remove the 
 obsolete files from the local repository's directory dedicated for given 
 module.
 h4. reproducing the problem
 # download the sample pom to an empty directory
 # execute {{mvn clean install -Dc=obsolete-demo}} - this represents the 
 older version of a module
 # execute {{mvn clean install}} - this represents the newer version of a 
 module, after changing the classifier
 # now, look in the local repo using {{ls -1 
 $HOME/.m2/repository/demo/sample-zip-module/1-SNAPSHOT}} - you will see this:
 {quote}
 maven-metadata-local.xml
 sample-zip-module-1-SNAPSHOT-demo.zip
 {color:red}sample-zip-module-1-SNAPSHOT-obsolete-demo.zip{color}
 sample-zip-module-1-SNAPSHOT.pom
 {quote}
 h4. possible solutions
 I see two approaches
 # *drop the installdir first* - straightforward
 # *list installdir, install, drop leftovers* - slightly more complicated but 
 maximizes the time of installed module existence

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Moved: (MINSTALL-79) install:install should remove leftovers from local repository


 [ 
http://jira.codehaus.org/browse/MINSTALL-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Gier moved MANTRUN-153 to MINSTALL-79:
---

Affects Version/s: (was: 1.5)
  Key: MINSTALL-79  (was: MANTRUN-153)
  Project: Maven 2.x Install Plugin  (was: Maven 2.x Antrun Plugin)

 install:install should remove leftovers from local repository
 -

 Key: MINSTALL-79
 URL: http://jira.codehaus.org/browse/MINSTALL-79
 Project: Maven 2.x Install Plugin
  Issue Type: Bug
Reporter: Petr Kozelka
 Attachments: pom.xml


 It happens that we need to change the set of output artifacts. When this 
 happens, the install mojo does not bother to remove older artifacts that are 
 no longer produced by this module.
 The bad effect is, that other modules depending on the obsolete artifacts can 
 still use it. Much better behavior in this situation would be, to remove the 
 obsolete files from the local repository's directory dedicated for given 
 module.
 h4. reproducing the problem
 # download the sample pom to an empty directory
 # execute {{mvn clean install -Dc=obsolete-demo}} - this represents the 
 older version of a module
 # execute {{mvn clean install}} - this represents the newer version of a 
 module, after changing the classifier
 # now, look in the local repo using {{ls -1 
 $HOME/.m2/repository/demo/sample-zip-module/1-SNAPSHOT}} - you will see this:
 {quote}
 maven-metadata-local.xml
 sample-zip-module-1-SNAPSHOT-demo.zip
 {color:red}sample-zip-module-1-SNAPSHOT-obsolete-demo.zip{color}
 sample-zip-module-1-SNAPSHOT.pom
 {quote}
 h4. possible solutions
 I see two approaches
 # *drop the installdir first* - straightforward
 # *list installdir, install, drop leftovers* - slightly more complicated but 
 maximizes the time of installed module existence

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Reopened: (MINSTALL-79) install:install should remove leftovers from local repository