[jira] (MCOMPILER-157) Maven Compiler Plugin should add to compileSourceRoots for next plugins to consider as source directory for generated files

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/MCOMPILER-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey reassigned MCOMPILER-157:


Assignee: John Casey

 Maven Compiler Plugin should add to compileSourceRoots for next plugins to 
 consider as source directory for generated files 
 

 Key: MCOMPILER-157
 URL: https://jira.codehaus.org/browse/MCOMPILER-157
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 2.3.2
 Environment: Java 6
Reporter: Zoran Regvart
Assignee: John Casey
 Fix For: 3.2

 Attachments: failing-test-example.zip, 
 maven-compiler-plugin-add-compileSourceRoots.patch, 
 maven-compiler-plugin-addToSourcePathAsWell.patch, TestCase2.zip, 
 test-case.zip


 Maven Compiler Plugin by relying on javac by default, on Java 6 platform 
 includes annotation processors in it's processing, these in end could 
 generate sources that are placed by default in 
 target/generated-sources/annotations. The later should be added to 
 compileSourceRoots so that next plugin in execution would consider those 
 sources.
 Please, see the attached test case and consider the attached patch in the 
 next release of maven-compiler-plugin.
 thanks,
 Zoran



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCOMPILER-157) Maven Compiler Plugin should add to compileSourceRoots for next plugins to consider as source directory for generated files

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/MCOMPILER-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey closed MCOMPILER-157.


Resolution: Fixed

adapted failing test case. It's now using a plugin to try to read the generated 
file from the annotation processor execution. It doesn't make sense that text 
files in the source roots would be accessible via the JUnit test classpath...

Thanks for the patch and base test case!

 Maven Compiler Plugin should add to compileSourceRoots for next plugins to 
 consider as source directory for generated files 
 

 Key: MCOMPILER-157
 URL: https://jira.codehaus.org/browse/MCOMPILER-157
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 2.3.2
 Environment: Java 6
Reporter: Zoran Regvart
Assignee: John Casey
 Fix For: 3.2

 Attachments: failing-test-example.zip, 
 maven-compiler-plugin-add-compileSourceRoots.patch, 
 maven-compiler-plugin-addToSourcePathAsWell.patch, TestCase2.zip, 
 test-case.zip


 Maven Compiler Plugin by relying on javac by default, on Java 6 platform 
 includes annotation processors in it's processing, these in end could 
 generate sources that are placed by default in 
 target/generated-sources/annotations. The later should be added to 
 compileSourceRoots so that next plugin in execution would consider those 
 sources.
 Please, see the attached test case and consider the attached patch in the 
 next release of maven-compiler-plugin.
 thanks,
 Zoran



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCOMPILER-159) generatedSourcesDirectory should be included in list provided by org.apache.maven.project.MavenProject.getCompileClasspathElements()

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/MCOMPILER-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey reassigned MCOMPILER-159:


Assignee: John Casey

 generatedSourcesDirectory should be included in list provided by 
 org.apache.maven.project.MavenProject.getCompileClasspathElements()
 

 Key: MCOMPILER-159
 URL: https://jira.codehaus.org/browse/MCOMPILER-159
 Project: Maven Compiler Plugin
  Issue Type: Improvement
Affects Versions: 2.3.2
Reporter: Andrew Green
Assignee: John Casey
Priority: Minor
 Fix For: 3.2


 I'm using a plugin (gwt-maven-plugin) that needs to know where all of my 
 project's source code is, including generated sources. The standard compiler 
 plugin (maven-compiler-plugin, v2.3.2) generates the sources correctly (from 
 anntotations) and uses the generated code fine when compiling my project. But 
 to get the gwt-maven-plugin to find the generated sources, I have to use the 
 build-helper-maven-plugin to add the generated sources directory, as shown 
 here:
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-compiler-plugin/artifactId
 version2.3.2/version
 configuration
   source1.6/source
   target1.6/target
   
 generatedSourcesDirectory${project.build.directory}/generated-sources/apt/generatedSourcesDirectory
 /configuration
   /plugin
   plugin
   groupIdorg.codehaus.mojo/groupId
   artifactIdbuild-helper-maven-plugin/artifactId
   version1.5/version
   executions
   execution
   idadd-source/id
   phasegenerate-sources/phase
   goals
   goaladd-source/goal
   /goals
   configuration
   sources
   
 source${project.build.directory}/generated-sources/apt/source
   /sources
   /configuration
   /execution
   /executions
   /plugin
 It shouldn't be necessary to use build-helper-maven-plugin here; the 
 generated sources should automatically be on the classpath. As far as I can 
 tell, this is a Maven issue, or perhaps a maven-compiler-plugin issue, and is 
 not the fault of gwt-maven-plugin.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey closed MCOMPILER-224.


Resolution: Fixed

fixed plexus-compiler-api (PR#24) in order to clean up message text in 
CompilerMessage instances, and adjusted integration test to make sure 
everything is working.

 Maven compiler plugin does not properly consume plexus compiler output
 --

 Key: MCOMPILER-224
 URL: https://jira.codehaus.org/browse/MCOMPILER-224
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 3.0, 3.1
Reporter: David M. Lloyd
Assignee: John Casey
 Fix For: 3.2

 Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip


 Maven compiler plugin does not properly read the output from the plexus 
 compiler.  All CompilerMessages are logged at warning or error level, even if 
 they are not warnings or errors.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCOMPILER-159) generatedSourcesDirectory should be included in list provided by org.apache.maven.project.MavenProject.getCompileClasspathElements()

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/MCOMPILER-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey closed MCOMPILER-159.


Resolution: Fixed

See MCOMPILER-157 for details

 generatedSourcesDirectory should be included in list provided by 
 org.apache.maven.project.MavenProject.getCompileClasspathElements()
 

 Key: MCOMPILER-159
 URL: https://jira.codehaus.org/browse/MCOMPILER-159
 Project: Maven Compiler Plugin
  Issue Type: Improvement
Affects Versions: 2.3.2
Reporter: Andrew Green
Assignee: John Casey
Priority: Minor
 Fix For: 3.2


 I'm using a plugin (gwt-maven-plugin) that needs to know where all of my 
 project's source code is, including generated sources. The standard compiler 
 plugin (maven-compiler-plugin, v2.3.2) generates the sources correctly (from 
 anntotations) and uses the generated code fine when compiling my project. But 
 to get the gwt-maven-plugin to find the generated sources, I have to use the 
 build-helper-maven-plugin to add the generated sources directory, as shown 
 here:
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-compiler-plugin/artifactId
 version2.3.2/version
 configuration
   source1.6/source
   target1.6/target
   
 generatedSourcesDirectory${project.build.directory}/generated-sources/apt/generatedSourcesDirectory
 /configuration
   /plugin
   plugin
   groupIdorg.codehaus.mojo/groupId
   artifactIdbuild-helper-maven-plugin/artifactId
   version1.5/version
   executions
   execution
   idadd-source/id
   phasegenerate-sources/phase
   goals
   goaladd-source/goal
   /goals
   configuration
   sources
   
 source${project.build.directory}/generated-sources/apt/source
   /sources
   /configuration
   /execution
   /executions
   /plugin
 It shouldn't be necessary to use build-helper-maven-plugin here; the 
 generated sources should automatically be on the classpath. As far as I can 
 tell, this is a Maven issue, or perhaps a maven-compiler-plugin issue, and is 
 not the fault of gwt-maven-plugin.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353629#comment-353629
 ] 

John Casey commented on MCOMPILER-224:
--

Sorry for the delay, I'm picking this back up. If the fix is already in, I'll 
simply verify that fact and close.

 Maven compiler plugin does not properly consume plexus compiler output
 --

 Key: MCOMPILER-224
 URL: https://jira.codehaus.org/browse/MCOMPILER-224
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 3.0, 3.1
Reporter: David M. Lloyd
Assignee: John Casey
 Fix For: 3.2

 Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip


 Maven compiler plugin does not properly read the output from the plexus 
 compiler.  All CompilerMessages are logged at warning or error level, even if 
 they are not warnings or errors.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353633#comment-353633
 ] 

John Casey commented on MCOMPILER-224:
--

*sigh* apparently email sync doesn't work, so rewriting my comment here...

I thought I peeked at the source some time ago, and a little elf (Herve?) had 
been in there fixing up the JDK 6 handling... ;-D

I'll verify and adjust as needed. 

 Maven compiler plugin does not properly consume plexus compiler output
 --

 Key: MCOMPILER-224
 URL: https://jira.codehaus.org/browse/MCOMPILER-224
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 3.0, 3.1
Reporter: David M. Lloyd
Assignee: John Casey
 Fix For: 3.2

 Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip


 Maven compiler plugin does not properly read the output from the plexus 
 compiler.  All CompilerMessages are logged at warning or error level, even if 
 they are not warnings or errors.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353638#comment-353638
 ] 

John Casey commented on MCOMPILER-224:
--

I've added a cleanup step to the construction of CompilerMessage in 
plexus-compiler-api to address the JDK 6 message prefix problem causing the IT 
for this issue to fail.

The PR for plexus-compiler is: 
https://github.com/sonatype/plexus-compiler/pull/24

 Maven compiler plugin does not properly consume plexus compiler output
 --

 Key: MCOMPILER-224
 URL: https://jira.codehaus.org/browse/MCOMPILER-224
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 3.0, 3.1
Reporter: David M. Lloyd
Assignee: John Casey
 Fix For: 3.2

 Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip


 Maven compiler plugin does not properly read the output from the plexus 
 compiler.  All CompilerMessages are logged at warning or error level, even if 
 they are not warnings or errors.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey closed MCOMPILER-224.


   Resolution: Fixed
Fix Version/s: 3.2
 Assignee: John Casey

Added IT and verified fix.

 Maven compiler plugin does not properly consume plexus compiler output
 --

 Key: MCOMPILER-224
 URL: https://jira.codehaus.org/browse/MCOMPILER-224
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 3.0, 3.1
Reporter: David M. Lloyd
Assignee: John Casey
 Fix For: 3.2

 Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip


 Maven compiler plugin does not properly read the output from the plexus 
 compiler.  All CompilerMessages are logged at warning or error level, even if 
 they are not warnings or errors.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey updated MCOMPILER-224:
-

Attachment: MCOMPILER-224.zip

proposed integration test

 Maven compiler plugin does not properly consume plexus compiler output
 --

 Key: MCOMPILER-224
 URL: https://jira.codehaus.org/browse/MCOMPILER-224
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 3.0, 3.1
Reporter: David M. Lloyd
 Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip


 Maven compiler plugin does not properly read the output from the plexus 
 compiler.  All CompilerMessages are logged at warning or error level, even if 
 they are not warnings or errors.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=346714#comment-346714
 ] 

John Casey commented on MCOMPILER-224:
--

I've checked the patch against the integration test I just attached, and using 
a build of plexus-compiler snapshots from last Friday...it doesn't work.

I've debugged this down to the DiagnosticCollector class from the JDK, and it 
doesn't seem to collect those NOTE | OTHER | WARNING messages...only 
MANDATORY_WARNING and ERROR. I feel like I'm missing something here, since I 
had heard that a code fix was applied to plexus-compilers for this.

 Maven compiler plugin does not properly consume plexus compiler output
 --

 Key: MCOMPILER-224
 URL: https://jira.codehaus.org/browse/MCOMPILER-224
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 3.0, 3.1
Reporter: David M. Lloyd
 Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip


 Maven compiler plugin does not properly read the output from the plexus 
 compiler.  All CompilerMessages are logged at warning or error level, even if 
 they are not warnings or errors.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=346722#comment-346722
 ] 

John Casey edited comment on MCOMPILER-224 at 5/19/14 11:28 AM:


 plexusCompilerVersion2.4-SNAPSHOT/plexusCompilerVersion

and the build of that is from 03c0a61ed3f3fcdd73c41d34593dac8d03a6b4be on the 
master branch of:

https://github.com/sonatype/plexus-compiler.git


was (Author: jdcasey):
 {{{   plexusCompilerVersion2.4-SNAPSHOT/plexusCompilerVersion }}}

and the build of that is from 03c0a61ed3f3fcdd73c41d34593dac8d03a6b4be on the 
master branch of:

https://github.com/sonatype/plexus-compiler.git

 Maven compiler plugin does not properly consume plexus compiler output
 --

 Key: MCOMPILER-224
 URL: https://jira.codehaus.org/browse/MCOMPILER-224
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 3.0, 3.1
Reporter: David M. Lloyd
 Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip


 Maven compiler plugin does not properly read the output from the plexus 
 compiler.  All CompilerMessages are logged at warning or error level, even if 
 they are not warnings or errors.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MCOMPILER-224) Maven compiler plugin does not properly consume plexus compiler output

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MCOMPILER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=346722#comment-346722
 ] 

John Casey commented on MCOMPILER-224:
--

 {{{   plexusCompilerVersion2.4-SNAPSHOT/plexusCompilerVersion }}}

and the build of that is from 03c0a61ed3f3fcdd73c41d34593dac8d03a6b4be on the 
master branch of:

https://github.com/sonatype/plexus-compiler.git

 Maven compiler plugin does not properly consume plexus compiler output
 --

 Key: MCOMPILER-224
 URL: https://jira.codehaus.org/browse/MCOMPILER-224
 Project: Maven Compiler Plugin
  Issue Type: Bug
Affects Versions: 3.0, 3.1
Reporter: David M. Lloyd
 Attachments: MCOMPILER-224.patch, MCOMPILER-224.zip


 Maven compiler plugin does not properly read the output from the plexus 
 compiler.  All CompilerMessages are logged at warning or error level, even if 
 they are not warnings or errors.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MSHADE-167) [PATCH] When individual classes are renamed, they are not debuggable

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/MSHADE-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey closed MSHADE-167.
-

   Resolution: Fixed
Fix Version/s: 2.3
 Assignee: John Casey

Applied with small modifications to new unit test code to adjust to ASM 5 apis.

 [PATCH] When individual classes are renamed, they are not debuggable
 

 Key: MSHADE-167
 URL: https://jira.codehaus.org/browse/MSHADE-167
 Project: Maven Shade Plugin
  Issue Type: Improvement
Affects Versions: 2.2
Reporter: Matt Benson
Assignee: John Casey
 Fix For: 2.3

 Attachments: shade-srcfile.patch.txt


 One can rename a given class using, e.g.:
 {code}
 relocation
   patterncom.example.foo./pattern
   shadedPatterncom.uber._foo.__/shadedPattern
 /relocation
 {code}
 Using the above relocation, {{com.example.foo.Bar}} will be relocated to 
 {{com.uber.\_foo.\_\_Bar}} and this is fine. If the source jar is generated, 
 the {{.java}} file will be moved accordingly. The proposed patch changes the 
 source information in the relocated class to use the new basename of the Java 
 source file, making it possible to debug again. My Apache ICLA is on file, 
 rights are granted, and a test of the functionality is included.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MJAVADOC-389) managed dependencies not used when resolving dependency sources

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/MJAVADOC-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey reassigned MJAVADOC-389:
---

Assignee: John Casey

 managed dependencies not used when resolving dependency sources
 ---

 Key: MJAVADOC-389
 URL: https://jira.codehaus.org/browse/MJAVADOC-389
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.9.1
Reporter: John Casey
Assignee: John Casey

 I have a managed dependency in my POM that modifies a transitive dependency. 
 When I build, and even when I use dependency:tree, the output is as I expect 
 it to be. 
 However, when I run the javadoc report with includeDependencySources=true it 
 tries to download sources for the unmodified transitive dependency version, 
 not my managed one.
 The problem is in ResourceResolver at line 346, where the 
 resolveTransitively() call doesn't pass in the managed-version map from the 
 project. I'll attach a failing test case as soon as I can set one up.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MJAVADOC-389) managed dependencies not used when resolving dependency sources

[John Casey (JIRA)]

John Casey created MJAVADOC-389:
---

 Summary: managed dependencies not used when resolving dependency 
sources
 Key: MJAVADOC-389
 URL: https://jira.codehaus.org/browse/MJAVADOC-389
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.9.1
Reporter: John Casey


I have a managed dependency in my POM that modifies a transitive dependency. 
When I build, and even when I use dependency:tree, the output is as I expect it 
to be. 

However, when I run the javadoc report with includeDependencySources=true it 
tries to download sources for the unmodified transitive dependency version, not 
my managed one.

The problem is in ResourceResolver at line 346, where the resolveTransitively() 
call doesn't pass in the managed-version map from the project. I'll attach a 
failing test case as soon as I can set one up.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MJAVADOC-338) When includeDependencySources=true the javadoc plugin should not download the internet every time it is run

[John Casey (JIRA)]

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

John Casey reassigned MJAVADOC-338:
---

Assignee: John Casey

 When includeDependencySources=true the javadoc plugin should not download the 
 internet every time it is run
 ---

 Key: MJAVADOC-338
 URL: https://jira.codehaus.org/browse/MJAVADOC-338
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Geoffrey De Smet
Assignee: John Casey

 This is my configuration:
 {code}
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-javadoc-plugin/artifactId
 executions
   execution
 phasepackage/phase
 goals
   goaljavadoc/goal
 /goals
   /execution
 /executions
 configuration
   includeDependencySourcestrue/includeDependencySources
   
 includeTransitiveDependencySourcestrue/includeTransitiveDependencySources
   dependencySourceIncludes
 dependencySourceIncludeorg.drools:*/dependencySourceInclude
   /dependencySourceIncludes
 /configuration
   /plugin
 {code}
 the javadoc plugins downloads a very long list of dependencies every time it 
 is run:
 {code}
 gdesmet@gdesmetRedHat2010 droolsjbpm-uber-distribution [master *] $ mvn 
 javadoc:javadoc
 [INFO] Scanning for projects...
 [INFO]
  
 [INFO] 
 
 [INFO] Building Drools and jBPM uber distribution 5.4.0-SNAPSHOT
 [INFO] 
 
 [INFO] 
 [INFO]  maven-javadoc-plugin:2.8:javadoc (default-cli) @ 
 droolsjbpm-uber-distribution 
 [INFO] 
 [INFO] --- maven-enforcer-plugin:1.0:enforce (default) @ 
 droolsjbpm-uber-distribution ---
 [INFO] 
 [INFO]  maven-javadoc-plugin:2.8:javadoc (default-cli) @ 
 droolsjbpm-uber-distribution 
 [INFO] 
 [INFO] --- maven-javadoc-plugin:2.8:javadoc (default-cli) @ 
 droolsjbpm-uber-distribution ---
 [WARNING] Missing POM for stax:stax-ri:jar:1.0
 [WARNING] Missing POM for javax.ejb:ejb:jar:3.0
 [WARNING] Missing POM for com.sun:tools:jar:javadoc-resources:1.5.0
 [WARNING] Missing POM for woodstox:wstx-asl:jar:3.2.2
 [WARNING] Missing POM for 
 org.springframework.osgi:log4j.osgi:jar:1.2.15-SNAPSHOT
 [WARNING] Missing POM for javax.servlet.jsp.jstl:jstl:jar:1.2
 Downloading: 
 http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
 Downloading: 
 https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
 Downloading: 
 http://repo1.maven.org/maven2/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
 [WARNING] Missing POM for 
 org.springframework:org.springframework.beans:jar:javadoc-resources:3.0.0.RELEASE
 Downloading: 
 http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
 Downloading: 
 https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
 Downloading: 
 http://repo1.maven.org/maven2/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
 [WARNING] Missing POM for 
 org.springframework:org.springframework.asm:jar:javadoc-resources:3.0.0.RELEASE
 Downloading: 
 http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.core/3.0.0.RELEASE/org.springframework.core-3.0.0.RELEASE.pom
 Downloading: 
 https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.core/3.0.0.RELEASE/org.springframework.core-3.0.0.RELEASE.pom
 Downloading: 
 http://repo1.maven.org/maven2/org/springframework/org.springframework.core/3.0.0.RELEASE/org.springframework.core-3.0.0.RELEASE.pom
 [WARNING] Missing POM for 
 org.springframework:org.springframework.core:jar:javadoc-resources:3.0.0.RELEASE
 Downloading: 
 http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.aop/3.0.0.RELEASE/org.springframework.aop-3.0.0.RELEASE.pom
 Downloading: 
 https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.aop/3.0.0.RELEASE/org.springframework.aop-3.0.0.RELEASE.pom
 Downloading: 
 

[jira] (MJAVADOC-338) When includeDependencySources=true the javadoc plugin should not download the internet every time it is run

[John Casey (JIRA)]

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

John Casey reassigned MJAVADOC-338:
---

Assignee: (was: John Casey)

 When includeDependencySources=true the javadoc plugin should not download the 
 internet every time it is run
 ---

 Key: MJAVADOC-338
 URL: https://jira.codehaus.org/browse/MJAVADOC-338
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Geoffrey De Smet

 This is my configuration:
 {code}
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-javadoc-plugin/artifactId
 executions
   execution
 phasepackage/phase
 goals
   goaljavadoc/goal
 /goals
   /execution
 /executions
 configuration
   includeDependencySourcestrue/includeDependencySources
   
 includeTransitiveDependencySourcestrue/includeTransitiveDependencySources
   dependencySourceIncludes
 dependencySourceIncludeorg.drools:*/dependencySourceInclude
   /dependencySourceIncludes
 /configuration
   /plugin
 {code}
 the javadoc plugins downloads a very long list of dependencies every time it 
 is run:
 {code}
 gdesmet@gdesmetRedHat2010 droolsjbpm-uber-distribution [master *] $ mvn 
 javadoc:javadoc
 [INFO] Scanning for projects...
 [INFO]
  
 [INFO] 
 
 [INFO] Building Drools and jBPM uber distribution 5.4.0-SNAPSHOT
 [INFO] 
 
 [INFO] 
 [INFO]  maven-javadoc-plugin:2.8:javadoc (default-cli) @ 
 droolsjbpm-uber-distribution 
 [INFO] 
 [INFO] --- maven-enforcer-plugin:1.0:enforce (default) @ 
 droolsjbpm-uber-distribution ---
 [INFO] 
 [INFO]  maven-javadoc-plugin:2.8:javadoc (default-cli) @ 
 droolsjbpm-uber-distribution 
 [INFO] 
 [INFO] --- maven-javadoc-plugin:2.8:javadoc (default-cli) @ 
 droolsjbpm-uber-distribution ---
 [WARNING] Missing POM for stax:stax-ri:jar:1.0
 [WARNING] Missing POM for javax.ejb:ejb:jar:3.0
 [WARNING] Missing POM for com.sun:tools:jar:javadoc-resources:1.5.0
 [WARNING] Missing POM for woodstox:wstx-asl:jar:3.2.2
 [WARNING] Missing POM for 
 org.springframework.osgi:log4j.osgi:jar:1.2.15-SNAPSHOT
 [WARNING] Missing POM for javax.servlet.jsp.jstl:jstl:jar:1.2
 Downloading: 
 http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
 Downloading: 
 https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
 Downloading: 
 http://repo1.maven.org/maven2/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
 [WARNING] Missing POM for 
 org.springframework:org.springframework.beans:jar:javadoc-resources:3.0.0.RELEASE
 Downloading: 
 http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
 Downloading: 
 https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
 Downloading: 
 http://repo1.maven.org/maven2/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
 [WARNING] Missing POM for 
 org.springframework:org.springframework.asm:jar:javadoc-resources:3.0.0.RELEASE
 Downloading: 
 http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.core/3.0.0.RELEASE/org.springframework.core-3.0.0.RELEASE.pom
 Downloading: 
 https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.core/3.0.0.RELEASE/org.springframework.core-3.0.0.RELEASE.pom
 Downloading: 
 http://repo1.maven.org/maven2/org/springframework/org.springframework.core/3.0.0.RELEASE/org.springframework.core-3.0.0.RELEASE.pom
 [WARNING] Missing POM for 
 org.springframework:org.springframework.core:jar:javadoc-resources:3.0.0.RELEASE
 Downloading: 
 http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.aop/3.0.0.RELEASE/org.springframework.aop-3.0.0.RELEASE.pom
 Downloading: 
 https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.aop/3.0.0.RELEASE/org.springframework.aop-3.0.0.RELEASE.pom
 Downloading: 
 

[jira] (MJAVADOC-338) When includeDependencySources=true the javadoc plugin should not download the internet every time it is run

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MJAVADOC-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=343789#comment-343789
 ] 

John Casey commented on MJAVADOC-338:
-

It looks like it's doing what you asked it to do: trying to resolve 
javadoc-resources bundles for all transitive drools dependencies. I suppose you 
might be able to refine the configuration better if you had a set of 
includes/excludes configurations specific to javadoc-resources, particularly 
since these aren't all that common. But the log you posted is just a long list 
of 404's, right? So, they're probably coming back fairly quickly, and IIRC the 
404 result should be stored in your local repository (unless you're using -U to 
bypass that result caching).

 When includeDependencySources=true the javadoc plugin should not download the 
 internet every time it is run
 ---

 Key: MJAVADOC-338
 URL: https://jira.codehaus.org/browse/MJAVADOC-338
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Geoffrey De Smet

 This is my configuration:
 {code}
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-javadoc-plugin/artifactId
 executions
   execution
 phasepackage/phase
 goals
   goaljavadoc/goal
 /goals
   /execution
 /executions
 configuration
   includeDependencySourcestrue/includeDependencySources
   
 includeTransitiveDependencySourcestrue/includeTransitiveDependencySources
   dependencySourceIncludes
 dependencySourceIncludeorg.drools:*/dependencySourceInclude
   /dependencySourceIncludes
 /configuration
   /plugin
 {code}
 the javadoc plugins downloads a very long list of dependencies every time it 
 is run:
 {code}
 gdesmet@gdesmetRedHat2010 droolsjbpm-uber-distribution [master *] $ mvn 
 javadoc:javadoc
 [INFO] Scanning for projects...
 [INFO]
  
 [INFO] 
 
 [INFO] Building Drools and jBPM uber distribution 5.4.0-SNAPSHOT
 [INFO] 
 
 [INFO] 
 [INFO]  maven-javadoc-plugin:2.8:javadoc (default-cli) @ 
 droolsjbpm-uber-distribution 
 [INFO] 
 [INFO] --- maven-enforcer-plugin:1.0:enforce (default) @ 
 droolsjbpm-uber-distribution ---
 [INFO] 
 [INFO]  maven-javadoc-plugin:2.8:javadoc (default-cli) @ 
 droolsjbpm-uber-distribution 
 [INFO] 
 [INFO] --- maven-javadoc-plugin:2.8:javadoc (default-cli) @ 
 droolsjbpm-uber-distribution ---
 [WARNING] Missing POM for stax:stax-ri:jar:1.0
 [WARNING] Missing POM for javax.ejb:ejb:jar:3.0
 [WARNING] Missing POM for com.sun:tools:jar:javadoc-resources:1.5.0
 [WARNING] Missing POM for woodstox:wstx-asl:jar:3.2.2
 [WARNING] Missing POM for 
 org.springframework.osgi:log4j.osgi:jar:1.2.15-SNAPSHOT
 [WARNING] Missing POM for javax.servlet.jsp.jstl:jstl:jar:1.2
 Downloading: 
 http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
 Downloading: 
 https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
 Downloading: 
 http://repo1.maven.org/maven2/org/springframework/org.springframework.beans/3.0.0.RELEASE/org.springframework.beans-3.0.0.RELEASE.pom
 [WARNING] Missing POM for 
 org.springframework:org.springframework.beans:jar:javadoc-resources:3.0.0.RELEASE
 Downloading: 
 http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
 Downloading: 
 https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
 Downloading: 
 http://repo1.maven.org/maven2/org/springframework/org.springframework.asm/3.0.0.RELEASE/org.springframework.asm-3.0.0.RELEASE.pom
 [WARNING] Missing POM for 
 org.springframework:org.springframework.asm:jar:javadoc-resources:3.0.0.RELEASE
 Downloading: 
 http://repository.jboss.org/nexus/content/groups/public/org/springframework/org.springframework.core/3.0.0.RELEASE/org.springframework.core-3.0.0.RELEASE.pom
 Downloading: 
 https://repository.jboss.org/nexus/content/repositories/deprecated/org/springframework/org.springframework.core/3.0.0.RELEASE/org.springframework.core-3.0.0.RELEASE.pom
 Downloading: 
 

[jira] (MRELEASE-812) prepare does not commit before tagging and therefore deploys snapshot instead of release

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey updated MRELEASE-812:


Affects Version/s: 2.3.2

I've seen this happening in version 2.3.2 also.

I'm just adding this to help others searching for solutions to this. It's a 
VERY difficult problem to understand until you sift through the debug console 
output...and even then, you have to know what to look for.

If you're using Maven 3.1.1, this behavior will crop up if you don't have a 
version specified for the release plugin in your pom.xml, since it seems to be 
the default version.

 prepare does not commit before tagging and therefore deploys snapshot 
 instead of release
 --

 Key: MRELEASE-812
 URL: https://jira.codehaus.org/browse/MRELEASE-812
 Project: Maven Release Plugin
  Issue Type: Bug
  Components: Git
Affects Versions: 2.3.2, 2.4
Reporter: Andrei Pozolotin
Assignee: Robert Scholte
Priority: Critical
 Fix For: 2.5

 Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt


 thank you very much for new release!
 http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E
 it seems we need an emergency fix:
 attached are 2 logs:
 1) mvn-2.3.2.txt invocation that works fine with 2.3.2
 2) mvn-2.4.0.txt invocation that fails with 2.4
 problem:
 perform does not commit tags, deploys snapshot instead of release
 here is project parent:
 http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom
 build is invoked both times with this:
 mvn --define resume=false release:prepare
 mvn --define resume=false release:perform



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MRELEASE-812) prepare does not commit before tagging and therefore deploys snapshot instead of release

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=341842#comment-341842
 ] 

John Casey edited comment on MRELEASE-812 at 2/21/14 12:19 PM:
---

I've seen this happening in version 2.3.2 also.

I'm just adding this to help others searching for solutions to this. It's a 
VERY difficult problem to understand until you sift through the debug console 
output...and even then, you have to know what to look for.

If you're using Maven 3.1.1, this behavior will crop up if you don't have a 
version specified for the release plugin in your pom.xml, since it seems to be 
the default version.

From an execution using Maven 3.1.1 and release 2.3.2:

{noformat}
[DEBUG] On branch master
[DEBUG] Your branch is up-to-date with 'origin/master'.
[DEBUG] 
[DEBUG] Changes to be committed:
[DEBUG]   (use git reset HEAD file... to unstage)
[DEBUG] 
[DEBUG] modified:   pom.xml
[DEBUG] 
[DEBUG] Untracked files:
[DEBUG]   (use git add file... to include in what will be committed)
[DEBUG] 
[DEBUG] pom.xml.releaseBackup
[DEBUG] prepare.log
[DEBUG] release.properties
[DEBUG] 
[INFO] Tagging release with the label buildmetadata-maven-plugin-1.3.1...
{noformat}


was (Author: jdcasey):
I've seen this happening in version 2.3.2 also.

I'm just adding this to help others searching for solutions to this. It's a 
VERY difficult problem to understand until you sift through the debug console 
output...and even then, you have to know what to look for.

If you're using Maven 3.1.1, this behavior will crop up if you don't have a 
version specified for the release plugin in your pom.xml, since it seems to be 
the default version.

 prepare does not commit before tagging and therefore deploys snapshot 
 instead of release
 --

 Key: MRELEASE-812
 URL: https://jira.codehaus.org/browse/MRELEASE-812
 Project: Maven Release Plugin
  Issue Type: Bug
  Components: Git
Affects Versions: 2.3.2, 2.4
Reporter: Andrei Pozolotin
Assignee: Robert Scholte
Priority: Critical
 Fix For: 2.5

 Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt


 thank you very much for new release!
 http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E
 it seems we need an emergency fix:
 attached are 2 logs:
 1) mvn-2.3.2.txt invocation that works fine with 2.3.2
 2) mvn-2.4.0.txt invocation that fails with 2.4
 problem:
 perform does not commit tags, deploys snapshot instead of release
 here is project parent:
 http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom
 build is invoked both times with this:
 mvn --define resume=false release:prepare
 mvn --define resume=false release:perform



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-5475) [REGRESSION] repo and pluginRepo with different id's prevent resolution of common parent POM

[John Casey (JIRA)]

John Casey created MNG-5475:
---

 Summary: [REGRESSION] repo and pluginRepo with different id's 
prevent resolution of common parent POM 
 Key: MNG-5475
 URL: https://jira.codehaus.org/browse/MNG-5475
 Project: Maven 2  3
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 3.0.5, 3.0.4, 3.1.0-alpha-1
 Environment: OS X (10.8.3), JDK 1.6
Reporter: John Casey
Priority: Critical
 Attachments: repo-id-squash.zip

I have a settings.xml file with an activated profile that lists one repository 
and one pluginRepository, both pointing at the same repo (on disk) BUT using 
different repository id's.

In this repository, I have deployed a parent POM and a plugin. The plugin lists 
the parent POM as its parent.

I also have another jar project that uses the parent POM as its parent, and 
uses the plugin during its build.

NOW:

When building with Maven 3.0.3, the jar project build completes correctly. But, 
when I build with ANY VERSION AFTER 3.0.3 (3.0.4, 3.0.5, 3.1.0-alpha-1 from 
March 30th, io.tesla.maven.apache-maven 3.1.2...even though that's not part of 
Apache Maven at all) IT FAILS.

The specific failure is that it cannot find the common parent POM as it's 
trying to resolve the plugin. Looking closely at the build logs, you can see 
Maven resolve the parent POM using the non-plugin repository, and update 
_maven.repository (I've verified that this non-plugin repository's id is stored 
here). Then, Maven tries to resolve the plugin POM, sees that the parent POM is 
in the local repository and isn't set to be updated yet. So, it tries to verify 
that that parent POM is available via the plugin repositories it knows 
about...which is where _maven.repository seems to come in. It has the wrong 
value, and causes Maven to discard the locally cached parent POM.

So, Maven won't update this parent POM in the local repo, but refuses to use 
the one that's there because it came from the wrong place.

It seems like Aether is not smart enough to understand that the two 
repositories are the same, even though the repository-id is different. I 
suspect this could lead to VERY strange-seeming errors if two projects 
referenced the same parent POM and repository URL but with different repo-id's.

I'm attaching a test case. It contains the repository with the parent POM and 
the plugin, along with the source projects for each. It also contains the jar 
project (bar-child) which has a settings.xml file in it. Finally, in the 
bar-child/ directory you'll find build-*.log files corresponding to each 
attempt I made with different Maven versions. The root directory is: 

repo-id-squash/

NOTE: If you want to run the test case, you'll need to modify the paths in the 
bar-child/settings.xml since they're currently specific to my filesystem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MDEP-391) Unpack fails on linux with large archives

[John Casey (JIRA)]

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

John Casey closed MDEP-391.
---

   Resolution: Fixed
Fix Version/s: 2.7
 Assignee: Brian Fox

Seems like this was fixed by Brian Fox and Robert Scholte. Marking resolved so 
we can retry the vote for 2.7

 Unpack fails on linux with large archives
 -

 Key: MDEP-391
 URL: https://jira.codehaus.org/browse/MDEP-391
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: unpack
Affects Versions: 2.6
 Environment: Ubuntu 10.04 LTS
Reporter: Benoit Montuelle
Assignee: Brian Fox
 Fix For: 2.7

 Attachments: lsof.txt


 When unpacking large  archives with numerous files (more than 1024 on this 
 os) I got the following error trace
 [INFO] Expanding 
 /var/lib/deploy/.m2/repository/com/aprilwaf/wafservice/ihm-packaging-ecg/3.9-finsouscription-SNAPSHOT/ihm-packaging-ecg-3.9-finsouscription-SNAPSHOT-distribution-php.tar.gz
  to /tmp/tmp5620480517649479513.tar
 [INFO] Expanding: /tmp/tmp5620480517649479513.tar into 
 /var/lib/deploy/build-deploy/ecg/target/classes
 org.codehaus.plexus.archiver.ArchiverException: Error while executing chmod.
   at 
 org.codehaus.plexus.archiver.util.ArchiveEntryUtils.chmod(ArchiveEntryUtils.java:64)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.extractFile(AbstractZipUnArchiver.java:236)
   at 
 org.codehaus.plexus.archiver.tar.TarUnArchiver.execute(TarUnArchiver.java:92)
   at 
 org.codehaus.plexus.archiver.tar.TarGZipUnArchiver.execute(TarGZipUnArchiver.java:76)
   at 
 org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:108)
   at 
 org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:260)
   at 
 org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:122)
   at 
 org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:95)
   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 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.codehaus.plexus.util.cli.CommandLineException: Error while 
 executing process.
   at 
 org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:652)
   at 
 org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:102)
   at 
 org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89)
   at 
 org.codehaus.plexus.archiver.util.ArchiveEntryUtils.chmod(ArchiveEntryUtils.java:45)
   ... 26 more
 Caused by: java.io.IOException: Cannot run program /bin/sh (in directory 
 /var/lib/deploy/build-deploy/ecg/target/classes/symfony-1.4/lib/plugins/sfDoctrinePlugin/test/unit/record):
  java.io.IOException: error=24, Too many open files
   at java.lang.ProcessBuilder.start(ProcessBuilder.java:460)
   at java.lang.Runtime.exec(Runtime.java:593)
   at 
 org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:647)
   ... 29 more
 Caused by: java.io.IOException: java.io.IOException: error=24, Too many open 
 files
   at 

[jira] (MDEP-401) Support include/exclude of artifactId/groupId in resolve-plugins

[John Casey (JIRA)]

John Casey created MDEP-401:
---

 Summary: Support include/exclude of artifactId/groupId in 
resolve-plugins
 Key: MDEP-401
 URL: https://jira.codehaus.org/browse/MDEP-401
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: resolve-plugins
Affects Versions: 2.6
Reporter: John Casey


exclude* and include* (for dealing with artifact coordinates) are mentioned in 
the docs for resolve-plugins, but only because they're present as parameters in 
an abstract superclass. It would be very useful to actually support these in 
the resolve-plugins mojo's functionality.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MDEP-402) Allow resolve-plugins to exclude plugins in the current reactor

[John Casey (JIRA)]

John Casey created MDEP-402:
---

 Summary: Allow resolve-plugins to exclude plugins in the current 
reactor
 Key: MDEP-402
 URL: https://jira.codehaus.org/browse/MDEP-402
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: resolve-plugins
Affects Versions: 2.6
Reporter: John Casey


plugins that are built and then used all in the same build should not be in the 
list of plugins to be resolved during the resolve-plugins mojo run.

We need a new parameter excludeReactor to allow exclusion of these plugins.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MDEP-402) Allow resolve-plugins to exclude plugins in the current reactor

[John Casey (JIRA)]

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

John Casey reassigned MDEP-402:
---

Assignee: John Casey

 Allow resolve-plugins to exclude plugins in the current reactor
 ---

 Key: MDEP-402
 URL: https://jira.codehaus.org/browse/MDEP-402
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: resolve-plugins
Affects Versions: 2.6
Reporter: John Casey
Assignee: John Casey

 plugins that are built and then used all in the same build should not be in 
 the list of plugins to be resolved during the resolve-plugins mojo run.
 We need a new parameter excludeReactor to allow exclusion of these plugins.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MDEP-401) Support include/exclude of artifactId/groupId in resolve-plugins

[John Casey (JIRA)]

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

John Casey reassigned MDEP-401:
---

Assignee: John Casey

 Support include/exclude of artifactId/groupId in resolve-plugins
 

 Key: MDEP-401
 URL: https://jira.codehaus.org/browse/MDEP-401
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: resolve-plugins
Affects Versions: 2.6
Reporter: John Casey
Assignee: John Casey

 exclude* and include* (for dealing with artifact coordinates) are mentioned 
 in the docs for resolve-plugins, but only because they're present as 
 parameters in an abstract superclass. It would be very useful to actually 
 support these in the resolve-plugins mojo's functionality.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MDEP-402) Allow resolve-plugins to exclude plugins in the current reactor

[John Casey (JIRA)]

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

John Casey closed MDEP-402.
---

   Resolution: Fixed
Fix Version/s: 2.7

Implemented in revId 1448351

 Allow resolve-plugins to exclude plugins in the current reactor
 ---

 Key: MDEP-402
 URL: https://jira.codehaus.org/browse/MDEP-402
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: resolve-plugins
Affects Versions: 2.6
Reporter: John Casey
Assignee: John Casey
 Fix For: 2.7


 plugins that are built and then used all in the same build should not be in 
 the list of plugins to be resolved during the resolve-plugins mojo run.
 We need a new parameter excludeReactor to allow exclusion of these plugins.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MDEP-401) Support include/exclude of artifactId/groupId in resolve-plugins

[John Casey (JIRA)]

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

John Casey closed MDEP-401.
---

   Resolution: Fixed
Fix Version/s: 2.7

Implemented in revId 1448351

 Support include/exclude of artifactId/groupId in resolve-plugins
 

 Key: MDEP-401
 URL: https://jira.codehaus.org/browse/MDEP-401
 Project: Maven 2.x Dependency Plugin
  Issue Type: Bug
  Components: resolve-plugins
Affects Versions: 2.6
Reporter: John Casey
Assignee: John Casey
 Fix For: 2.7


 exclude* and include* (for dealing with artifact coordinates) are mentioned 
 in the docs for resolve-plugins, but only because they're present as 
 parameters in an abstract superclass. It would be very useful to actually 
 support these in the resolve-plugins mojo's functionality.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5390) mvn -rf (no argument) results in NPE

[John Casey (JIRA)]

John Casey created MNG-5390:
---

 Summary: mvn -rf (no argument) results in NPE
 Key: MNG-5390
 URL: https://jira.codehaus.org/browse/MNG-5390
 Project: Maven 2  3
  Issue Type: Bug
  Components: Command Line
Affects Versions: 3.1.0
Reporter: John Casey
Priority: Minor


Does NOT affect version 3.0.4.

Try:

mvn clean install -rf

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5177) Maven adds tests dependecies into depgraph even when skipping tests

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-5177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311981#comment-311981
 ] 

John Casey commented on MNG-5177:
-

IMO this is a dangerous thing to add without warning. Any plugin can specify 
'@RequiresDependencResolution test' and get tripped up with this patch, it's 
not only those that respond to maven.test.skip. In fact, I can think of use 
cases off the top of my head (creating a standalone buildable archive of a 
project using the assembly plugin being one) where test scope is needed, but 
have nothing at all to do with compiling/executing tests directly.

 Maven adds tests dependecies into depgraph even when skipping tests
 ---

 Key: MNG-5177
 URL: https://jira.codehaus.org/browse/MNG-5177
 Project: Maven 2  3
  Issue Type: Bug
Affects Versions: 3.0.3
Reporter: Stanislav Ochotnicky
Priority: Minor
 Attachments: 0001-Fix-text-scope-skipping-with-maven.test.skip.patch


 Maven 3.x adds test dependencies into dependency graph even when we use 
 -Dmaven.test.skip=true. This means unnecessary downloading of artifacts and 
 failure of build if the repository with test dependencies is offline. 
 I was able to solve this by patching maven in following way:
  1. add new DependencySelector implementation that looks at environment 
 variables and omits test dependencies when maven.test.skip property is found
  2. modify maven-compat as well so that old code paths work the same way.
 Maybe a better way to do part 1 would be to modify ScopeDependencySelector, 
 and if that's the preferred way I can rework the patch that way.
 I had several issues with the implementation: 
  1. For some reason I wasn't able to get property definition from 
 MavenSession so I used System.getProperty directly. Any idea what might be 
 the reason?
  2. Is there perhaps a better way to figure out that tests are being skipped 
 instead of looking for maven.test.skip property? 
  3. I had to copy non-test artifacts of dependencies in 
 DefaultArtifactResolver because original implementation didn't provide 
 remove method. Not a big deal I guess, but worth a note.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5177) Maven adds tests dependecies into depgraph even when skipping tests

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-5177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311981#comment-311981
 ] 

John Casey edited comment on MNG-5177 at 10/22/12 2:57 PM:
---

IMO this is a dangerous thing to add without warning. Any plugin can specify 
'@RequiresDependencResolution test' and get tripped up with this patch, it's 
not only those that respond to maven.test.skip. In fact, I can think of use 
cases off the top of my head (creating a standalone buildable archive of a 
project using the assembly plugin being one) where test scope is needed, but 
have nothing at all to do with compiling/executing tests directly.

If you want to avoid downloading test dependencies, you can move them into a 
profile that is activated when maven.test.skip == false. This works; I've used 
the technique.

  was (Author: jdcasey):
IMO this is a dangerous thing to add without warning. Any plugin can 
specify '@RequiresDependencResolution test' and get tripped up with this patch, 
it's not only those that respond to maven.test.skip. In fact, I can think of 
use cases off the top of my head (creating a standalone buildable archive of a 
project using the assembly plugin being one) where test scope is needed, but 
have nothing at all to do with compiling/executing tests directly.
  
 Maven adds tests dependecies into depgraph even when skipping tests
 ---

 Key: MNG-5177
 URL: https://jira.codehaus.org/browse/MNG-5177
 Project: Maven 2  3
  Issue Type: Bug
Affects Versions: 3.0.3
Reporter: Stanislav Ochotnicky
Priority: Minor
 Attachments: 0001-Fix-text-scope-skipping-with-maven.test.skip.patch


 Maven 3.x adds test dependencies into dependency graph even when we use 
 -Dmaven.test.skip=true. This means unnecessary downloading of artifacts and 
 failure of build if the repository with test dependencies is offline. 
 I was able to solve this by patching maven in following way:
  1. add new DependencySelector implementation that looks at environment 
 variables and omits test dependencies when maven.test.skip property is found
  2. modify maven-compat as well so that old code paths work the same way.
 Maybe a better way to do part 1 would be to modify ScopeDependencySelector, 
 and if that's the preferred way I can rework the patch that way.
 I had several issues with the implementation: 
  1. For some reason I wasn't able to get property definition from 
 MavenSession so I used System.getProperty directly. Any idea what might be 
 the reason?
  2. Is there perhaps a better way to figure out that tests are being skipped 
 instead of looking for maven.test.skip property? 
  3. I had to copy non-test artifacts of dependencies in 
 DefaultArtifactResolver because original implementation didn't provide 
 remove method. Not a big deal I guess, but worth a note.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5177) Maven adds tests dependecies into depgraph even when skipping tests

[John Casey (JIRA)]

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

John Casey closed MNG-5177.
---

Resolution: Won't Fix
  Assignee: John Casey

This changes the behavior of core Maven for all plugins that may require 
test-scoped dependencies. It's a mistake to think only of those that compile or 
execute tests, or that respond to maven.test.skip. There are less invasive ways 
to achieve the stated goal with Maven as-is.

 Maven adds tests dependecies into depgraph even when skipping tests
 ---

 Key: MNG-5177
 URL: https://jira.codehaus.org/browse/MNG-5177
 Project: Maven 2  3
  Issue Type: Bug
Affects Versions: 3.0.3
Reporter: Stanislav Ochotnicky
Assignee: John Casey
Priority: Minor
 Attachments: 0001-Fix-text-scope-skipping-with-maven.test.skip.patch


 Maven 3.x adds test dependencies into dependency graph even when we use 
 -Dmaven.test.skip=true. This means unnecessary downloading of artifacts and 
 failure of build if the repository with test dependencies is offline. 
 I was able to solve this by patching maven in following way:
  1. add new DependencySelector implementation that looks at environment 
 variables and omits test dependencies when maven.test.skip property is found
  2. modify maven-compat as well so that old code paths work the same way.
 Maybe a better way to do part 1 would be to modify ScopeDependencySelector, 
 and if that's the preferred way I can rework the patch that way.
 I had several issues with the implementation: 
  1. For some reason I wasn't able to get property definition from 
 MavenSession so I used System.getProperty directly. Any idea what might be 
 the reason?
  2. Is there perhaps a better way to figure out that tests are being skipped 
 instead of looking for maven.test.skip property? 
  3. I had to copy non-test artifacts of dependencies in 
 DefaultArtifactResolver because original implementation didn't provide 
 remove method. Not a big deal I guess, but worth a note.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5361) dependencyManagement should manage OVERRIDDEN plugin dependencies

[John Casey (JIRA)]

John Casey created MNG-5361:
---

 Summary: dependencyManagement should manage OVERRIDDEN plugin 
dependencies
 Key: MNG-5361
 URL: https://jira.codehaus.org/browse/MNG-5361
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies, Plugins and Lifecycle
Affects Versions: 3.0.4
Reporter: John Casey


In some ways this is a rehash of MNG-2496 with a different twist.

We're managing enormous sets of interrelated projects, and producing a coherent 
product (actually many) from these. We're using a cleanroom environment for 
builds, which means we're trying to limit the number of versions of any given 
project in that environment to the ones we're actually trying to ship.

To prevent a situation where a single project version upgrade triggers a 
massive cascade of rebuilds, we're using dependencyManagement extensively to 
help us manage the versions of things that go in the product(s).

In unusual cases, projects require a particular plugin-level dependency to 
enable extra functionality (antrun, for example), or to bring in an artifact 
handler / archiver (assembly plugin).

These cases represent a leak of our managed dependency set, where version 
information escapes into individual projects and requires that they be rebuilt 
each time the dependency version changes...putting us part of the way back into 
the cascading-updates hell.

It may be unreasonable to allow dependencyManagement to control the NORMAL set 
of dependencies in the plugin's depgraph...I agree with the conclusion in 
MNG-2496 100%. HOWEVER, in cases where the project overrides or introduces 
extra dependencies via plugindependencies/, we SHOULD allow Maven to manage 
those dependencies.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-4893) [regression] Version x.y.z.SNAPSHOT does not deploy correctly

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301909#comment-301909
 ] 

John Casey commented on MNG-4893:
-

Still, it's interesting that Maven 3.0.4 isn't treating this as either a 
release OR a snapshot:

{noformat}
[DEBUG] Using connector WagonRepositoryConnector with priority 0 for 
http://localhost/aprox/api/1.0/group/cs-repo
Downloading: 
http://localhost/aprox/api/1.0/group/cs-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.SNAPSHOT/maven-metadata.xml
[WARNING] Checksum validation failed, expected 
fadf64d6a63432658605c71565e8fe9db63b992d but is 
6b15d68e9afb51aee13d0f2f25a0730bdd883d42 for 
http://localhost/aprox/api/1.0/group/cs-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.SNAPSHOT/maven-metadata.xml
[WARNING] Checksum validation failed, expected 
fadf64d6a63432658605c71565e8fe9db63b992d but is 
6b15d68e9afb51aee13d0f2f25a0730bdd883d42 for 
http://localhost/aprox/api/1.0/group/cs-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.SNAPSHOT/maven-metadata.xml
Downloaded: 
http://localhost/aprox/api/1.0/group/cs-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.SNAPSHOT/maven-metadata.xml
 (251 B at 0.0 KB/sec)
[DEBUG] Writing resolution tracking file 
/Users/jdcasey/workspace/redhat/temp/it-poc/local-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.SNAPSHOT/resolver-status.properties
[DEBUG] Using connector WagonRepositoryConnector with priority 0 for 
http://localhost/aprox/api/1.0/group/cs-repo
Downloading: 
http://localhost/aprox/api/1.0/group/cs-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.20110720.215608-33/user-rest-client-java-1.0.0.20110720.215608-33.pom
[DEBUG] Writing resolution tracking file 
/Users/jdcasey/workspace/redhat/temp/it-poc/local-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.20110720.215608-33/user-rest-client-java-1.0.0.20110720.215608-33.pom.lastUpdated
[WARNING] The POM for 
com.redhat.services.rest.user:user-rest-client-java:jar:1.0.0.20110720.215608-33
 is missing, no dependency information available
{noformat}

You'll notice that it's grabbing the maven-metadata.xml from the 1.0.0.SNAPSHOT 
version dir, then using that to formulate a new URL (just as it would for a 
snapshot). The problem is, it's formatting the URL incorrectly. So, it appears 
we have a half-baked snapshot implementation where .SNAPSHOT is concerned.

Whether or not we choose to support .SNAPSHOT, this is broken.

 [regression] Version x.y.z.SNAPSHOT does not deploy correctly
 -

 Key: MNG-4893
 URL: https://jira.codehaus.org/browse/MNG-4893
 Project: Maven 2  3
  Issue Type: Bug
  Components: Deployment
Affects Versions: 3.0
Reporter: Paul Gier
Assignee: Benjamin Bentmann
Priority: Critical

 When using a version that ends with .SNAPSHOT instead of the usual 
 -SNAPSHOT, Maven 3.0 changes the project version to the timestamped 
 version.  So 5.2.0.SNAPSHOT becomes something like 
 5.2.0.20101109.215833-1.  A Nexus snapshot repository will reject this 
 deployment because the version in the directory name does not end with 
 SNAPSHOT.
 I tested that this works in Maven 2.2.1 and Maven 3.0-beta-1, but does not 
 work in Maven 3.0.  The build returns an HTTP 400 error when deploying to 
 Nexus.
 Error from Nexus log
 {noformat}
 2010-11-09 22:02:23 INFO [1298122354-2147] - o.s.n.p.m.m.M2Repos~ - Storing 
 of item snapshots:/org/drools
 /drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is 
 forbidden by Maven Repository 
 policy. Because snapshots is a SNAPSHOT repository
 2010-11-09 22:02:23 ERROR [1298122354-2147] - o.s.n.r.ContentPlex~ - Got 
 exception during processing 
 request PUT 
 http://repository.jboss.org/nexus/content/repositories/snapshots/org/drools/drools
 /5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom: Storing of 
 item snapshots:/org/drools
 /drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is 
 forbidden by Maven Repository 
 policy. Because snapshots is a SNAPSHOT repository 
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-4893) [regression] Version x.y.z.SNAPSHOT does not deploy correctly

[John Casey (JIRA)]

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

John Casey reopened MNG-4893:
-


It's still broken, even if we suppose that .SNAPSHOT isn't supported. If that's 
true, then x.y.z.SNAPSHOT should be treated as a release version (not 
interpreted at all)...and it's not. See my comment just above this one.

 [regression] Version x.y.z.SNAPSHOT does not deploy correctly
 -

 Key: MNG-4893
 URL: https://jira.codehaus.org/browse/MNG-4893
 Project: Maven 2  3
  Issue Type: Bug
  Components: Deployment
Affects Versions: 3.0
Reporter: Paul Gier
Assignee: Benjamin Bentmann
Priority: Critical

 When using a version that ends with .SNAPSHOT instead of the usual 
 -SNAPSHOT, Maven 3.0 changes the project version to the timestamped 
 version.  So 5.2.0.SNAPSHOT becomes something like 
 5.2.0.20101109.215833-1.  A Nexus snapshot repository will reject this 
 deployment because the version in the directory name does not end with 
 SNAPSHOT.
 I tested that this works in Maven 2.2.1 and Maven 3.0-beta-1, but does not 
 work in Maven 3.0.  The build returns an HTTP 400 error when deploying to 
 Nexus.
 Error from Nexus log
 {noformat}
 2010-11-09 22:02:23 INFO [1298122354-2147] - o.s.n.p.m.m.M2Repos~ - Storing 
 of item snapshots:/org/drools
 /drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is 
 forbidden by Maven Repository 
 policy. Because snapshots is a SNAPSHOT repository
 2010-11-09 22:02:23 ERROR [1298122354-2147] - o.s.n.r.ContentPlex~ - Got 
 exception during processing 
 request PUT 
 http://repository.jboss.org/nexus/content/repositories/snapshots/org/drools/drools
 /5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom: Storing of 
 item snapshots:/org/drools
 /drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is 
 forbidden by Maven Repository 
 policy. Because snapshots is a SNAPSHOT repository 
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-4893) [regression] Version x.y.z.SNAPSHOT does not deploy correctly

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301909#comment-301909
 ] 

John Casey edited comment on MNG-4893 at 6/26/12 10:50 AM:
---

Still, it's interesting that Maven 3.0.4 isn't treating this as either a 
release OR a snapshot:

{noformat}
[DEBUG] Using connector WagonRepositoryConnector with priority 0 for 
http://localhost/aprox/api/1.0/group/cs-repo
Downloading: 
http://localhost/aprox/api/1.0/group/cs-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.SNAPSHOT/maven-metadata.xml
[...]
Downloading: 
http://localhost/aprox/api/1.0/group/cs-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.20110720.215608-33/user-rest-client-java-1.0.0.20110720.215608-33.pom
[...]
[WARNING] The POM for 
com.redhat.services.rest.user:user-rest-client-java:jar:1.0.0.20110720.215608-33
 is missing, no dependency information available
{noformat}

You'll notice that it's grabbing the maven-metadata.xml from the 1.0.0.SNAPSHOT 
version dir, then using that to formulate a new URL (just as it would for a 
snapshot). The problem is, it's formatting the URL incorrectly. So, it appears 
we have a half-baked snapshot implementation where .SNAPSHOT is concerned.

Whether or not we choose to support .SNAPSHOT, this is broken.

  was (Author: jdcasey):
Still, it's interesting that Maven 3.0.4 isn't treating this as either a 
release OR a snapshot:

{noformat}
[DEBUG] Using connector WagonRepositoryConnector with priority 0 for 
http://localhost/aprox/api/1.0/group/cs-repo
Downloading: 
http://localhost/aprox/api/1.0/group/cs-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.SNAPSHOT/maven-metadata.xml
[WARNING] Checksum validation failed, expected 
fadf64d6a63432658605c71565e8fe9db63b992d but is 
6b15d68e9afb51aee13d0f2f25a0730bdd883d42 for 
http://localhost/aprox/api/1.0/group/cs-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.SNAPSHOT/maven-metadata.xml
[WARNING] Checksum validation failed, expected 
fadf64d6a63432658605c71565e8fe9db63b992d but is 
6b15d68e9afb51aee13d0f2f25a0730bdd883d42 for 
http://localhost/aprox/api/1.0/group/cs-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.SNAPSHOT/maven-metadata.xml
Downloaded: 
http://localhost/aprox/api/1.0/group/cs-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.SNAPSHOT/maven-metadata.xml
 (251 B at 0.0 KB/sec)
[DEBUG] Writing resolution tracking file 
/Users/jdcasey/workspace/redhat/temp/it-poc/local-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.SNAPSHOT/resolver-status.properties
[DEBUG] Using connector WagonRepositoryConnector with priority 0 for 
http://localhost/aprox/api/1.0/group/cs-repo
Downloading: 
http://localhost/aprox/api/1.0/group/cs-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.20110720.215608-33/user-rest-client-java-1.0.0.20110720.215608-33.pom
[DEBUG] Writing resolution tracking file 
/Users/jdcasey/workspace/redhat/temp/it-poc/local-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.20110720.215608-33/user-rest-client-java-1.0.0.20110720.215608-33.pom.lastUpdated
[WARNING] The POM for 
com.redhat.services.rest.user:user-rest-client-java:jar:1.0.0.20110720.215608-33
 is missing, no dependency information available
{noformat}

You'll notice that it's grabbing the maven-metadata.xml from the 1.0.0.SNAPSHOT 
version dir, then using that to formulate a new URL (just as it would for a 
snapshot). The problem is, it's formatting the URL incorrectly. So, it appears 
we have a half-baked snapshot implementation where .SNAPSHOT is concerned.

Whether or not we choose to support .SNAPSHOT, this is broken.
  
 [regression] Version x.y.z.SNAPSHOT does not deploy correctly
 -

 Key: MNG-4893
 URL: https://jira.codehaus.org/browse/MNG-4893
 Project: Maven 2  3
  Issue Type: Bug
  Components: Deployment
Affects Versions: 3.0
Reporter: Paul Gier
Assignee: Benjamin Bentmann
Priority: Critical

 When using a version that ends with .SNAPSHOT instead of the usual 
 -SNAPSHOT, Maven 3.0 changes the project version to the timestamped 
 version.  So 5.2.0.SNAPSHOT becomes something like 
 5.2.0.20101109.215833-1.  A Nexus snapshot repository will reject this 
 deployment because the version in the directory name does not end with 
 SNAPSHOT.
 I tested that this works in Maven 2.2.1 and Maven 3.0-beta-1, but does not 
 work in Maven 3.0.  The build returns an HTTP 400 error when deploying to 
 Nexus.
 Error from Nexus log
 {noformat}
 2010-11-09 22:02:23 INFO [1298122354-2147] - o.s.n.p.m.m.M2Repos~ - Storing 
 of item snapshots:/org/drools
 /drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is 
 

[jira] (MNG-4893) [regression] Version x.y.z.SNAPSHOT resolution/deployment not handled correctly

[John Casey (JIRA)]

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

John Casey updated MNG-4893:


Summary: [regression] Version x.y.z.SNAPSHOT resolution/deployment not 
handled correctly  (was: [regression] Version x.y.z.SNAPSHOT does not deploy 
correctly)

 [regression] Version x.y.z.SNAPSHOT resolution/deployment not handled 
 correctly
 ---

 Key: MNG-4893
 URL: https://jira.codehaus.org/browse/MNG-4893
 Project: Maven 2  3
  Issue Type: Bug
  Components: Deployment
Affects Versions: 3.0
Reporter: Paul Gier
Assignee: Benjamin Bentmann
Priority: Critical

 When using a version that ends with .SNAPSHOT instead of the usual 
 -SNAPSHOT, Maven 3.0 changes the project version to the timestamped 
 version.  So 5.2.0.SNAPSHOT becomes something like 
 5.2.0.20101109.215833-1.  A Nexus snapshot repository will reject this 
 deployment because the version in the directory name does not end with 
 SNAPSHOT.
 I tested that this works in Maven 2.2.1 and Maven 3.0-beta-1, but does not 
 work in Maven 3.0.  The build returns an HTTP 400 error when deploying to 
 Nexus.
 Error from Nexus log
 {noformat}
 2010-11-09 22:02:23 INFO [1298122354-2147] - o.s.n.p.m.m.M2Repos~ - Storing 
 of item snapshots:/org/drools
 /drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is 
 forbidden by Maven Repository 
 policy. Because snapshots is a SNAPSHOT repository
 2010-11-09 22:02:23 ERROR [1298122354-2147] - o.s.n.r.ContentPlex~ - Got 
 exception during processing 
 request PUT 
 http://repository.jboss.org/nexus/content/repositories/snapshots/org/drools/drools
 /5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom: Storing of 
 item snapshots:/org/drools
 /drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is 
 forbidden by Maven Repository 
 policy. Because snapshots is a SNAPSHOT repository 
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-828) testng test need a excludedGroups element to not fail

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/SUREFIRE-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=290707#comment-290707
 ] 

John Casey commented on SUREFIRE-828:
-

In my rush to complete the expressions feature, I forgot to code in a check for 
empty strings in groups/excludedGroups. It looks like that's what's causing 
problems here.

 testng test need a excludedGroups element to not fail
 -

 Key: SUREFIRE-828
 URL: https://jira.codehaus.org/browse/SUREFIRE-828
 Project: Maven Surefire
  Issue Type: Bug
  Components: TestNG support
Affects Versions: 2.12
Reporter: Olivier Lamy
Assignee: John Casey
Priority: Critical

 excludedGroups looks to be mandatory now.
 If not surefire fail :
 {code}
 Running TestSuite
 org.apache.maven.surefire.util.SurefireReflectionException: 
 java.lang.reflect.InvocationTargetException; nested exception is 
 java.lang.reflect.InvocationTargetException: null
 java.lang.reflect.InvocationTargetException
   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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
   at 
 org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
   at 
 org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
   at 
 org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
   at 
 org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
 Caused by: org.apache.maven.surefire.testset.TestSetFailedException: null; 
 nested exception is java.lang.reflect.InvocationTargetException: null
   at 
 org.apache.maven.surefire.testng.TestNGExecutor.applyGroupMatching(TestNGExecutor.java:164)
   at 
 org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:65)
   at 
 org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:161)
   at 
 org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:101)
   at 
 org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:115)
   ... 9 more
 Caused by: java.lang.reflect.InvocationTargetException
   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.apache.maven.surefire.testng.TestNGExecutor.applyGroupMatching(TestNGExecutor.java:140)
   ... 13 more
 Caused by: java.lang.IllegalArgumentException: Cannot parse group 
 includes/excludes expression(s):
 Includes: null
 Excludes: 
   at 
 org.apache.maven.surefire.testng.utils.GroupMatcherMethodSelector.setGroups(GroupMatcherMethodSelector.java:82)
   ... 18 more
 Caused by: org.apache.maven.surefire.group.parse.ParseException: Encountered 
  at line 0, column 0.
 Was expecting one of:
 
   at 
 org.apache.maven.surefire.group.parse.GroupMatcherParser.generateParseException(GroupMatcherParser.java:633)
   at 
 org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_consume_token(GroupMatcherParser.java:518)
   at 
 org.apache.maven.surefire.group.parse.GroupMatcherParser.expr(GroupMatcherParser.java:68)
   at 
 org.apache.maven.surefire.group.parse.GroupMatcherParser.parse(GroupMatcherParser.java:56)
   at 
 org.apache.maven.surefire.testng.utils.GroupMatcherMethodSelector.setGroups(GroupMatcherMethodSelector.java:68)
   ... 18 more
 Results :
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-828) testng test need a excludedGroups element to not fail

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/SUREFIRE-828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey closed SUREFIRE-828.
---

   Resolution: Fixed
Fix Version/s: 2.13

see revIds: 1240241  1240242.

 testng test need a excludedGroups element to not fail
 -

 Key: SUREFIRE-828
 URL: https://jira.codehaus.org/browse/SUREFIRE-828
 Project: Maven Surefire
  Issue Type: Bug
  Components: TestNG support
Affects Versions: 2.12
Reporter: Olivier Lamy
Assignee: John Casey
Priority: Critical
 Fix For: 2.13


 excludedGroups looks to be mandatory now.
 If not surefire fail :
 {code}
 Running TestSuite
 org.apache.maven.surefire.util.SurefireReflectionException: 
 java.lang.reflect.InvocationTargetException; nested exception is 
 java.lang.reflect.InvocationTargetException: null
 java.lang.reflect.InvocationTargetException
   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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
   at 
 org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
   at 
 org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
   at 
 org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
   at 
 org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
 Caused by: org.apache.maven.surefire.testset.TestSetFailedException: null; 
 nested exception is java.lang.reflect.InvocationTargetException: null
   at 
 org.apache.maven.surefire.testng.TestNGExecutor.applyGroupMatching(TestNGExecutor.java:164)
   at 
 org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:65)
   at 
 org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:161)
   at 
 org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:101)
   at 
 org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:115)
   ... 9 more
 Caused by: java.lang.reflect.InvocationTargetException
   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.apache.maven.surefire.testng.TestNGExecutor.applyGroupMatching(TestNGExecutor.java:140)
   ... 13 more
 Caused by: java.lang.IllegalArgumentException: Cannot parse group 
 includes/excludes expression(s):
 Includes: null
 Excludes: 
   at 
 org.apache.maven.surefire.testng.utils.GroupMatcherMethodSelector.setGroups(GroupMatcherMethodSelector.java:82)
   ... 18 more
 Caused by: org.apache.maven.surefire.group.parse.ParseException: Encountered 
  at line 0, column 0.
 Was expecting one of:
 
   at 
 org.apache.maven.surefire.group.parse.GroupMatcherParser.generateParseException(GroupMatcherParser.java:633)
   at 
 org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_consume_token(GroupMatcherParser.java:518)
   at 
 org.apache.maven.surefire.group.parse.GroupMatcherParser.expr(GroupMatcherParser.java:68)
   at 
 org.apache.maven.surefire.group.parse.GroupMatcherParser.parse(GroupMatcherParser.java:56)
   at 
 org.apache.maven.surefire.testng.utils.GroupMatcherMethodSelector.setGroups(GroupMatcherMethodSelector.java:68)
   ... 18 more
 Results :
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-809) Implement boolean expression to define test group to be run.

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=289646#comment-289646
 ] 

John Casey commented on SUREFIRE-809:
-

In revId 1235805:

Just added tests to verify the grouping expressions work both in JUnit and 
TestNG. The implementation for TestNG offends my design sensibilities, but I 
didn't have many options for injecting the group-expression matcher logic.

In the end, I had to split out the group-expression support into a separate 
module, and handle it much the same way the testng-utils artifact is 
handled...injected directly into the test classpath for testng tests. There was 
a tad more fine tuning related to the new integration tests too, but it's 
pretty minor.

This feature should be complete now.

 Implement boolean expression to define test group to be run.
 

 Key: SUREFIRE-809
 URL: https://jira.codehaus.org/browse/SUREFIRE-809
 Project: Maven Surefire
  Issue Type: New Feature
  Components: Junit 4.x support, TestNG support
Affects Versions: 2.11
Reporter: Ondrej Zizka
 Fix For: 2.12

 Attachments: BooleanExpression.g, category-expression.jj


 This is an alternative to SUREFIRE-808.
 Instead of having hard-coded filtering structure combining two lists.
 an expression could be parsed and evaluated for each test.
 Each test would be tagged using 
 {code}
 @Categories({ MyCateg1.class, MyCateg2.class, ... })
 {code}
 Surefire's `group` config param would be an expression like:
 {code}
 groups( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )groups
 {code}
 Presence of a category of given name would be evaluated as true, absence of 
 it as false.
 Interface inheritance would be taken into account.
 This mechanism would provide unlimited possibilities of grouping tests, and 
 would be very beneficial for huge testuites counting thousands of tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-809) Implement boolean expression to define test group to be run.

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey updated SUREFIRE-809:


  Component/s: TestNG support
Fix Version/s: 2.12
 Assignee: John Casey

 Implement boolean expression to define test group to be run.
 

 Key: SUREFIRE-809
 URL: https://jira.codehaus.org/browse/SUREFIRE-809
 Project: Maven Surefire
  Issue Type: New Feature
  Components: Junit 4.x support, TestNG support
Affects Versions: 2.11
Reporter: Ondrej Zizka
Assignee: John Casey
 Fix For: 2.12

 Attachments: BooleanExpression.g, category-expression.jj


 This is an alternative to SUREFIRE-808.
 Instead of having hard-coded filtering structure combining two lists.
 an expression could be parsed and evaluated for each test.
 Each test would be tagged using 
 {code}
 @Categories({ MyCateg1.class, MyCateg2.class, ... })
 {code}
 Surefire's `group` config param would be an expression like:
 {code}
 groups( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )groups
 {code}
 Presence of a category of given name would be evaluated as true, absence of 
 it as false.
 Interface inheritance would be taken into account.
 This mechanism would provide unlimited possibilities of grouping tests, and 
 would be very beneficial for huge testuites counting thousands of tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-809) Implement boolean expression to define test group to be run.

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey closed SUREFIRE-809.
---

Resolution: Fixed

Ready to go into the next release attempt for 2.12.

 Implement boolean expression to define test group to be run.
 

 Key: SUREFIRE-809
 URL: https://jira.codehaus.org/browse/SUREFIRE-809
 Project: Maven Surefire
  Issue Type: New Feature
  Components: Junit 4.x support, TestNG support
Affects Versions: 2.11
Reporter: Ondrej Zizka
Assignee: John Casey
 Fix For: 2.12

 Attachments: BooleanExpression.g, category-expression.jj


 This is an alternative to SUREFIRE-808.
 Instead of having hard-coded filtering structure combining two lists.
 an expression could be parsed and evaluated for each test.
 Each test would be tagged using 
 {code}
 @Categories({ MyCateg1.class, MyCateg2.class, ... })
 {code}
 Surefire's `group` config param would be an expression like:
 {code}
 groups( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )groups
 {code}
 Presence of a category of given name would be evaluated as true, absence of 
 it as false.
 Interface inheritance would be taken into account.
 This mechanism would provide unlimited possibilities of grouping tests, and 
 would be very beneficial for huge testuites counting thousands of tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-808) Selectable grouping mode for test groups - UNION or INTERSECTION.

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/SUREFIRE-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey closed SUREFIRE-808.
---

Resolution: Won't Fix
  Assignee: John Casey

Implemented SUREFIRE-809 instead, to provide a richer set of options for 
selecting groups...also has the advantage of not introducing new parameters to 
a plugin that already has a nest of them.

 Selectable grouping mode for test groups - UNION or INTERSECTION.
 ---

 Key: SUREFIRE-808
 URL: https://jira.codehaus.org/browse/SUREFIRE-808
 Project: Maven Surefire
  Issue Type: New Feature
  Components: Junit 4.7+ (parallel) support, Junit 4.x support
Affects Versions: 2.10, 2.11
Reporter: Ondrej Zizka
Assignee: John Casey

 Currently, the `groups` and `excludedGroups` work like:
 {code}
 ( include1 OR include2 ... ) AND NOT ( exclude1 OR exclude2 OR ... )
 {code}
 This doesn't cover many usecases. For instance, if the groups overlap.
 Example: user needs to run only EJB tests under security manager, while only 
 some EJB tests can run under security manager.
 In such case, this is needed:
 {code}
 ( EJB AND SecurityManager )
 {code}
 The suggestion is to introduce two new params:
 {code}
 groupingMode = union|intersection
 excludeGroupingMode = union|intersection
 {code}
 They would switch AND and OR behavior.
 Union would be the default (preserving current behavior).
 Would be implemented in a filter, see:
 https://github.com/apache/maven-surefire/blob/trunk/surefire-providers/common-junit48/src/main/java/org/apache/maven/surefire/common/junit48/FilterFactory.java#L115

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-809) Implement boolean expression to define test group to be run.

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=289558#comment-289558
 ] 

John Casey commented on SUREFIRE-809:
-

Applied in revIds: 1235412-1235416

All existing tests are passing; now I need to add a few new tests to verify the 
extra expression combination features.

 Implement boolean expression to define test group to be run.
 

 Key: SUREFIRE-809
 URL: https://jira.codehaus.org/browse/SUREFIRE-809
 Project: Maven Surefire
  Issue Type: New Feature
  Components: Junit 4.x support
Affects Versions: 2.11
Reporter: Ondrej Zizka
 Attachments: BooleanExpression.g, category-expression.jj


 This is an alternative to SUREFIRE-808.
 Instead of having hard-coded filtering structure combining two lists.
 an expression could be parsed and evaluated for each test.
 Each test would be tagged using 
 {code}
 @Categories({ MyCateg1.class, MyCateg2.class, ... })
 {code}
 Surefire's `group` config param would be an expression like:
 {code}
 groups( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )groups
 {code}
 Presence of a category of given name would be evaluated as true, absence of 
 it as false.
 Interface inheritance would be taken into account.
 This mechanism would provide unlimited possibilities of grouping tests, and 
 would be very beneficial for huge testuites counting thousands of tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-809) Implement boolean expression to define test group to be run.

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=289558#comment-289558
 ] 

John Casey edited comment on SUREFIRE-809 at 1/24/12 1:35 PM:
--

Applied in revIds: 1235412-1235416

All existing tests are passing; now I need to add a few new tests to verify the 
extra expression combination features.

BTW, the mechanisms used to introduce these matchers into JUnit and TestNG are:

JUnit: Modified FilterFactory to parse the group expressions, combine them into 
a single matcher object (with the excludes matcher section inverted). Then, 
wrapped the matcher in a JUnit Filter implementation, and passed back in place 
of the old comma-separated listing of Filter instances.

TestNG: Modified AbstractDirectConfigurator to parse group expressions in much 
the same way as above (with JUnit), then set the matcher instance STATICALLY on 
a new IMethodSelector implementation. This static setter is my workaround for 
the fact that TestNG classloads / instantiates method selectors, rather than 
allowing instances to be injected directly. I didn't want to use a file-based 
approach, in case multiple TestNG processes ran simultaneously in a build (the 
selector would have to know the file name). The old groups / excludeGroups 
settings are commented out in favor of the new method selector.

These implementations may be controversial / flawed. If so, please provide some 
guidance as to a preferred alternative mechanism, since I'm relatively 
unfamiliar with the deep workings of these test frameworks.

  was (Author: jdcasey):
Applied in revIds: 1235412-1235416

All existing tests are passing; now I need to add a few new tests to verify the 
extra expression combination features.
  
 Implement boolean expression to define test group to be run.
 

 Key: SUREFIRE-809
 URL: https://jira.codehaus.org/browse/SUREFIRE-809
 Project: Maven Surefire
  Issue Type: New Feature
  Components: Junit 4.x support
Affects Versions: 2.11
Reporter: Ondrej Zizka
 Attachments: BooleanExpression.g, category-expression.jj


 This is an alternative to SUREFIRE-808.
 Instead of having hard-coded filtering structure combining two lists.
 an expression could be parsed and evaluated for each test.
 Each test would be tagged using 
 {code}
 @Categories({ MyCateg1.class, MyCateg2.class, ... })
 {code}
 Surefire's `group` config param would be an expression like:
 {code}
 groups( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )groups
 {code}
 Presence of a category of given name would be evaluated as true, absence of 
 it as false.
 Interface inheritance would be taken into account.
 This mechanism would provide unlimited possibilities of grouping tests, and 
 would be very beneficial for huge testuites counting thousands of tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-809) Implement boolean expression to define test group to be run.

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=289558#comment-289558
 ] 

John Casey edited comment on SUREFIRE-809 at 1/24/12 1:36 PM:
--

Applied in revIds: 1235412-1235416

All existing tests are passing; now I need to add a few new tests to verify the 
extra expression combination features.

BTW, the mechanisms used to introduce these matchers into JUnit and TestNG are:

*JUnit:*

Modified FilterFactory to parse the group expressions, combine them into a 
single matcher object (with the excludes matcher section inverted). Then, 
wrapped the matcher in a JUnit Filter implementation, and passed back in place 
of the old comma-separated listing of Filter instances.

*TestNG:*

Modified AbstractDirectConfigurator to parse group expressions in much the same 
way as above (with JUnit), then set the matcher instance STATICALLY on a new 
IMethodSelector implementation. This static setter is my workaround for the 
fact that TestNG classloads / instantiates method selectors, rather than 
allowing instances to be injected directly. I didn't want to use a file-based 
approach, in case multiple TestNG processes ran simultaneously in a build (the 
selector would have to know the file name). The old groups / excludeGroups 
settings are commented out in favor of the new method selector.

These implementations may be controversial / flawed. If so, please provide some 
guidance as to a preferred alternative mechanism, since I'm relatively 
unfamiliar with the deep workings of these test frameworks.

  was (Author: jdcasey):
Applied in revIds: 1235412-1235416

All existing tests are passing; now I need to add a few new tests to verify the 
extra expression combination features.

BTW, the mechanisms used to introduce these matchers into JUnit and TestNG are:

JUnit: Modified FilterFactory to parse the group expressions, combine them into 
a single matcher object (with the excludes matcher section inverted). Then, 
wrapped the matcher in a JUnit Filter implementation, and passed back in place 
of the old comma-separated listing of Filter instances.

TestNG: Modified AbstractDirectConfigurator to parse group expressions in much 
the same way as above (with JUnit), then set the matcher instance STATICALLY on 
a new IMethodSelector implementation. This static setter is my workaround for 
the fact that TestNG classloads / instantiates method selectors, rather than 
allowing instances to be injected directly. I didn't want to use a file-based 
approach, in case multiple TestNG processes ran simultaneously in a build (the 
selector would have to know the file name). The old groups / excludeGroups 
settings are commented out in favor of the new method selector.

These implementations may be controversial / flawed. If so, please provide some 
guidance as to a preferred alternative mechanism, since I'm relatively 
unfamiliar with the deep workings of these test frameworks.
  
 Implement boolean expression to define test group to be run.
 

 Key: SUREFIRE-809
 URL: https://jira.codehaus.org/browse/SUREFIRE-809
 Project: Maven Surefire
  Issue Type: New Feature
  Components: Junit 4.x support
Affects Versions: 2.11
Reporter: Ondrej Zizka
 Attachments: BooleanExpression.g, category-expression.jj


 This is an alternative to SUREFIRE-808.
 Instead of having hard-coded filtering structure combining two lists.
 an expression could be parsed and evaluated for each test.
 Each test would be tagged using 
 {code}
 @Categories({ MyCateg1.class, MyCateg2.class, ... })
 {code}
 Surefire's `group` config param would be an expression like:
 {code}
 groups( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )groups
 {code}
 Presence of a category of given name would be evaluated as true, absence of 
 it as false.
 Interface inheritance would be taken into account.
 This mechanism would provide unlimited possibilities of grouping tests, and 
 would be very beneficial for huge testuites counting thousands of tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-809) Implement boolean expression to define test group to be run.

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey updated SUREFIRE-809:


Attachment: category-expression.jj

javacc grammar for parsing category statements.

 Implement boolean expression to define test group to be run.
 

 Key: SUREFIRE-809
 URL: https://jira.codehaus.org/browse/SUREFIRE-809
 Project: Maven Surefire
  Issue Type: New Feature
  Components: Junit 4.x support
Affects Versions: 2.11
Reporter: Ondrej Zizka
 Attachments: BooleanExpression.g, category-expression.jj


 This is an alternative to SUREFIRE-808.
 Instead of having hard-coded filtering structure combining two lists.
 an expression could be parsed and evaluated for each test.
 Each test would be tagged using 
 {code}
 @Categories({ MyCateg1.class, MyCateg2.class, ... })
 {code}
 Surefire's `group` config param would be an expression like:
 {code}
 groups( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )groups
 {code}
 Presence of a category of given name would be evaluated as true, absence of 
 it as false.
 Interface inheritance would be taken into account.
 This mechanism would provide unlimited possibilities of grouping tests, and 
 would be very beneficial for huge testuites counting thousands of tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-809) Implement boolean expression to define test group to be run.

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=288974#comment-288974
 ] 

John Casey commented on SUREFIRE-809:
-

I've (approximately) rewritten the attached grammar so it'll work with javacc, 
and created a series of matcher classes that will help me evaluate a category 
statement. I'm currently working on integrating this work into the junit and 
testng providers. The advantage of javacc here is that it generates a 
self-contained set classes, so we're not adding any new dependencies.

I haven't committed the grammar to trunk yet, so I'll attach it here. It's my 
first javacc grammar, so it could use some peer review!

 Implement boolean expression to define test group to be run.
 

 Key: SUREFIRE-809
 URL: https://jira.codehaus.org/browse/SUREFIRE-809
 Project: Maven Surefire
  Issue Type: New Feature
  Components: Junit 4.x support
Affects Versions: 2.11
Reporter: Ondrej Zizka
 Attachments: BooleanExpression.g, category-expression.jj


 This is an alternative to SUREFIRE-808.
 Instead of having hard-coded filtering structure combining two lists.
 an expression could be parsed and evaluated for each test.
 Each test would be tagged using 
 {code}
 @Categories({ MyCateg1.class, MyCateg2.class, ... })
 {code}
 Surefire's `group` config param would be an expression like:
 {code}
 groups( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )groups
 {code}
 Presence of a category of given name would be evaluated as true, absence of 
 it as false.
 Interface inheritance would be taken into account.
 This mechanism would provide unlimited possibilities of grouping tests, and 
 would be very beneficial for huge testuites counting thousands of tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-803) Multiple Surefire executions - FAILURE in an execution prevents successive from running.

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/SUREFIRE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey closed SUREFIRE-803.
---

   Resolution: Fixed
Fix Version/s: 2.12

Added code to store/check a token in the plugin context to determine whether 
the failsafe summary already on disk is from a previous execution in the 
current build vs. output from a previous build.

Then, modified to accumulate test results in the failsafe summary instead of 
overwriting (overwrite still happens if the existing output is not from the 
current build). This allows multiple failsafe executions in a build without 
coping with different output locations for the summaries.

See revIds 1232091 and 1233522.

 Multiple Surefire executions - FAILURE in an execution prevents successive 
 from running.
 

 Key: SUREFIRE-803
 URL: https://jira.codehaus.org/browse/SUREFIRE-803
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Surefire Plugin
Affects Versions: 2.10
Reporter: Ondrej Zizka
Assignee: John Casey
 Fix For: 2.12

 Attachments: surefire-803-failure-prevents-subsequent-executions.zip


 Let's have multiple Surefire executions in a single module (different config 
 needed).
 A failure of a test in one of these executions prevents running the 
 successive.
 Surefire's testFailureIgnore is not an option because it makes a run with 
 failures succeed.
 This behavior is undocumented.
 Also, it is undesired - the module as a whole should fail, but all it's tests 
 should run.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-803) Multiple Failsafe executions - FAILURE in an execution prevents successive from running.

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/SUREFIRE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey updated SUREFIRE-803:


Component/s: (was: Maven Surefire Plugin)
 Maven Failsafe Plugin
Summary: Multiple Failsafe executions - FAILURE in an execution 
prevents successive from running.  (was: Multiple Surefire executions - FAILURE 
in an execution prevents successive from running.)

NOTE: NOT fixing this for the surefire plugin, only modifying the failsafe 
plugin a little bit. This is because the failsafe plugin is better equipped to 
handle the non-fail-fast use case.

 Multiple Failsafe executions - FAILURE in an execution prevents successive 
 from running.
 

 Key: SUREFIRE-803
 URL: https://jira.codehaus.org/browse/SUREFIRE-803
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Failsafe Plugin
Affects Versions: 2.10
Reporter: Ondrej Zizka
Assignee: John Casey
 Fix For: 2.12

 Attachments: surefire-803-failure-prevents-subsequent-executions.zip


 Let's have multiple Surefire executions in a single module (different config 
 needed).
 A failure of a test in one of these executions prevents running the 
 successive.
 Surefire's testFailureIgnore is not an option because it makes a run with 
 failures succeed.
 This behavior is undocumented.
 Also, it is undesired - the module as a whole should fail, but all it's tests 
 should run.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-806) Make ignoring of includes and excludes on -Dtest=... optional (for multiple Surefire executions)

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/SUREFIRE-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey closed SUREFIRE-806.
---

   Resolution: Fixed
Fix Version/s: 2.12

Created failIfNoSpecifiedTests parameter (-Dsurefire.failIfNoSpecifiedTests and 
-Dit.failIfNoSpecifiedTests when used from the CLI), which will determine 
whether test-execution blocks that don't contain one of the tests specified on 
the command line should fail the build or not. Default is to fail the build.

Also, in cases where there are multiple test execution blocks, to avoid running 
a specified test in the wrong block, the existing includes/excludes are now 
honored...the specified tests now act as a refining filter on these 
includes/excludes. This means that in cases where there are multiple 
test-execution blocks, you cannot run a test that wouldn't ordinarily be run by 
just using -Dtest=... any more.

In cases where there is only a single test-execution block, the specified tests 
should override the includes as before.

I also added three new integration tests to verify all of this behavior.

 Make ignoring of includes and excludes on -Dtest=... optional (for 
 multiple Surefire executions)
 

 Key: SUREFIRE-806
 URL: https://jira.codehaus.org/browse/SUREFIRE-806
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Surefire Plugin
Affects Versions: 2.11
Reporter: Ondrej Zizka
Assignee: John Casey
 Fix For: 2.12

 Attachments: surefire-806-testParam-hits-all-executions.zip


 Let's have a single module with multiple Surefire executions (e.g. with 
 different Arquillian configs)
 Tests are divided to run in either one, using includes and excludes.
 Then, if you use -Dtest=..., the specified test(s) is run twice - once for 
 each execution (and usually fails in one of them in our scenario).
 My suggestion is to introduce a Surefire config property which would make 
 this behavior optional:
 {code}
 configuration
   ignoreIncludesOnSingleTestfalse/ignoreIncludesOnSingleTest
 /configuration
 {code}
 This would cause Surefire to run the intersection of the two sets -
 one created by the mask from -Dtest=...,
 second created by the includes and excludes of the respective execution.
 Current description from 
 http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html :
 {quote}
 Specify this parameter to run individual tests by file name, overriding the 
 includes/excludes parameters. Each pattern you specify here will be used to 
 create an include pattern formatted like **/${test}.java, so you can just 
 type -Dtest=MyTest to run a single test called foo/MyTest.java.
 This parameter overrides the includes/excludes parameters, and the TestNG 
 suiteXmlFiles parameter.
 {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MJAVADOC-336) Reports contain temporary files due to usage of 'File.deleteOnExit'.

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MJAVADOC-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=288568#comment-288568
 ] 

John Casey commented on MJAVADOC-336:
-

revId 1232525 fwiw

 Reports contain temporary files due to usage of 'File.deleteOnExit'.
 

 Key: MJAVADOC-336
 URL: https://jira.codehaus.org/browse/MJAVADOC-336
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Christian Schulte
Assignee: John Casey
Priority: Minor
 Fix For: 2.8.1

 Attachments: MJAVADOC-336.patch


 The plugin creates temporary command line argument files (@file) in the 
 output directory without removing them prior to e.g. site deployment. Please 
 replace 'File.deleteOnExit' with 'File.delete'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MJAVADOC-336) Reports contain temporary files due to usage of 'File.deleteOnExit'.

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/MJAVADOC-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey closed MJAVADOC-336.
---

   Resolution: Fixed
Fix Version/s: 2.8.1
 Assignee: John Casey

applied. Thanks!

 Reports contain temporary files due to usage of 'File.deleteOnExit'.
 

 Key: MJAVADOC-336
 URL: https://jira.codehaus.org/browse/MJAVADOC-336
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Christian Schulte
Assignee: John Casey
Priority: Minor
 Fix For: 2.8.1

 Attachments: MJAVADOC-336.patch


 The plugin creates temporary command line argument files (@file) in the 
 output directory without removing them prior to e.g. site deployment. Please 
 replace 'File.deleteOnExit' with 'File.delete'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5218) Allow properties containing ${basedir} to retain same value in sub-modules.

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MNG-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=286029#comment-286029
 ] 

John Casey commented on MNG-5218:
-

The problem is that it would require complete overhaul of the way maven 
computes the effective pom for use in a module build. Model inheritance is 
collapsed, then interpolation takes place. So, this notion of resolve == here 
vs. resolve == everytime would have no meaning. Here is literally the module 
directory that inherits it.

What you might be talking about is traversing the parent structure that's on 
disk to the lowest (highest) level, and setting a property to that directory. 
I'm not sure it's really necessary to bake this into the core, though...you 
could accomplish this via something like the buildnumber-maven-plugin.

 Allow properties containing ${basedir} to retain same value in sub-modules.
 ---

 Key: MNG-5218
 URL: https://jira.codehaus.org/browse/MNG-5218
 Project: Maven 2  3
  Issue Type: Improvement
Reporter: Ondrej Zizka

 Currently, if a property contains ${basedir}, it's value in a submodule 
 contains submodule's base dir.
 I.e., each submodule has this value different.
 While it's handy for some cases (it allows nice recursive solution for some 
 tasks),
 there's no way to have the property with ${basedir} set in the parent module 
 and using it unchanged in submodules.
 That's quite crucial for e.g. complex testsuites.
 The current behavior is surely relied on in many projects, so I'd suggest 
 something like:
 {code}
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-806) Make ignoring of includes and excludes on -Dtest=... optional (for multiple Surefire executions)

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/SUREFIRE-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285947#comment-285947
 ] 

John Casey commented on SUREFIRE-806:
-

Oh, also, following up on SUREFIRE-778 ...if -DfilterCLITests=true and -Dtest= 
is supplied, then failIfNoTests should be set to false automatically (unless 
specifically overridden?)

 Make ignoring of includes and excludes on -Dtest=... optional (for 
 multiple Surefire executions)
 

 Key: SUREFIRE-806
 URL: https://jira.codehaus.org/browse/SUREFIRE-806
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Surefire Plugin
Affects Versions: 2.11
Reporter: Ondrej Zizka
Assignee: John Casey
 Attachments: surefire-806-testParam-hits-all-executions.zip


 Let's have a single module with multiple Surefire executions (e.g. with 
 different Arquillian configs)
 Tests are divided to run in either one, using includes and excludes.
 Then, if you use -Dtest=..., the specified test(s) is run twice - once for 
 each execution (and usually fails in one of them in our scenario).
 My suggestion is to introduce a Surefire config property which would make 
 this behavior optional:
 {code}
 configuration
   ignoreIncludesOnSingleTestfalse/ignoreIncludesOnSingleTest
 /configuration
 {code}
 This would cause Surefire to run the intersection of the two sets -
 one created by the mask from -Dtest=...,
 second created by the includes and excludes of the respective execution.
 Current description from 
 http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html :
 {quote}
 Specify this parameter to run individual tests by file name, overriding the 
 includes/excludes parameters. Each pattern you specify here will be used to 
 create an include pattern formatted like **/${test}.java, so you can just 
 type -Dtest=MyTest to run a single test called foo/MyTest.java.
 This parameter overrides the includes/excludes parameters, and the TestNG 
 suiteXmlFiles parameter.
 {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-806) Make ignoring of includes and excludes on -Dtest=... optional (for multiple Surefire executions)

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/SUREFIRE-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285946#comment-285946
 ] 

John Casey commented on SUREFIRE-806:
-

I've been looking at the code, and it seems like the most elegant solution 
might be to create a new implementation of ScannerFilter that would wrap any 
provider-specific filters in the event -Dtest= is specified on the command 
line. Then, rather than including the -Dtest= classes in the includes for the 
scanner, they would be managed via a separate property list, and populate the 
new filter. When the DirectoryScanner filters the classes it finds based on 
includes/excludes, the new ScannerFilter would first make sure (a) the tests 
list is empty, or (b) the class matches something in the tests list...if it did 
match, it would pass the class on to the provider-specific filter for ultimate 
acceptance.

This requires three basic changes:

1. Alter the handling of -Dtest= so the enumerated tests are serialized in a 
different list of properties (not in the includes list)
2. Read the new property list for -Dtest=, and use it to construct a new 
ScannerFilter that wraps the provider-specific one. If -Dtest= is specified, 
only allow classes that match that property list (subject to the 
provider-specific filter's acceptance).
3. Provide a flag to turn on/off this test-vs-includes separation. When off, 
the -Dtest= properties would be used as includes, and everything acts as it 
does today. Otherwise, steps 1 and 2 are executed.

As far as the flag used to turn on this option, I'm less sure...maybe something 
like filterCLITeststrue|false/filterCLITests?

 Make ignoring of includes and excludes on -Dtest=... optional (for 
 multiple Surefire executions)
 

 Key: SUREFIRE-806
 URL: https://jira.codehaus.org/browse/SUREFIRE-806
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Surefire Plugin
Affects Versions: 2.11
Reporter: Ondrej Zizka
Assignee: John Casey
 Attachments: surefire-806-testParam-hits-all-executions.zip


 Let's have a single module with multiple Surefire executions (e.g. with 
 different Arquillian configs)
 Tests are divided to run in either one, using includes and excludes.
 Then, if you use -Dtest=..., the specified test(s) is run twice - once for 
 each execution (and usually fails in one of them in our scenario).
 My suggestion is to introduce a Surefire config property which would make 
 this behavior optional:
 {code}
 configuration
   ignoreIncludesOnSingleTestfalse/ignoreIncludesOnSingleTest
 /configuration
 {code}
 This would cause Surefire to run the intersection of the two sets -
 one created by the mask from -Dtest=...,
 second created by the includes and excludes of the respective execution.
 Current description from 
 http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html :
 {quote}
 Specify this parameter to run individual tests by file name, overriding the 
 includes/excludes parameters. Each pattern you specify here will be used to 
 create an include pattern formatted like **/${test}.java, so you can just 
 type -Dtest=MyTest to run a single test called foo/MyTest.java.
 This parameter overrides the includes/excludes parameters, and the TestNG 
 suiteXmlFiles parameter.
 {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (SUREFIRE-803) Multiple Surefire executions - FAILURE in an execution prevents successive from running.

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/SUREFIRE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285659#comment-285659
 ] 

John Casey commented on SUREFIRE-803:
-

Do we have other cases where we're using the pluginContext for this sort of 
state? I know that's the point of the context, but it used to be broken once 
upon a time, and I'd be interested in seeing some prior art. Otherwise, I 
suppose we could try that and fall back to a file if it doesn't work.

I'm fine with changing the default behavior, since I think it's unlikely most 
people will really be able to tell. But does that mean the 'test' phase will 
actually run both surefire:test and surefire:verify, or would surefire:test 
actually run somewhere earlier (where, that it won't interfere with setting up 
the test classes?)...or, would users need to know that running `mvn clean test` 
no longer verifies the outcome of the surefire tests?

Or...are we hoping to pin verification to the end of the list of executions, 
using the pluginContext to detect that end? In effect, making it still be 
built into the surefire:test goal rather than splitting it into a 
surefire:verify goal?

 Multiple Surefire executions - FAILURE in an execution prevents successive 
 from running.
 

 Key: SUREFIRE-803
 URL: https://jira.codehaus.org/browse/SUREFIRE-803
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Surefire Plugin
Affects Versions: 2.10
Reporter: Ondrej Zizka
Assignee: John Casey
 Attachments: surefire-803-failure-prevents-subsequent-executions.zip


 Let's have multiple Surefire executions in a single module (different config 
 needed).
 A failure of a test in one of these executions prevents running the 
 successive.
 Surefire's testFailureIgnore is not an option because it makes a run with 
 failures succeed.
 This behavior is undocumented.
 Also, it is undesired - the module as a whole should fail, but all it's tests 
 should run.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (SUREFIRE-806) Make ignoring of includes and excludes on -Dtest=... optional (for multiple Surefire executions)

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/SUREFIRE-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey updated SUREFIRE-806:


Attachment: surefire-806-testParam-hits-all-executions.zip

This is a minimal test case that illustrates the problem. 

Follow instructions in README.txt.

 Make ignoring of includes and excludes on -Dtest=... optional (for 
 multiple Surefire executions)
 

 Key: SUREFIRE-806
 URL: https://jira.codehaus.org/browse/SUREFIRE-806
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.11
Reporter: Ondrej Zizka
 Attachments: surefire-806-testParam-hits-all-executions.zip


 Let's have a single module with multiple Surefire executions (e.g. with 
 different Arquillian configs)
 Tests are divided to run in either one, using includes and excludes.
 Then, if you use -Dtest=..., the specified test(s) is run twice - once for 
 each execution (and usually fails in one of them in our scenario).
 My suggestion is to introduce a Surefire config property which would make 
 this behavior optional:
 {code}
 configuration
   ignoreIncludesOnSingleTestfalse/ignoreIncludesOnSingleTest
 /configuration
 {code}
 This would cause Surefire to run the intersection of the two sets -
 one created by the mask from -Dtest=...,
 second created by the includes and excludes of the respective execution.
 Current description from 
 http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html :
 {quote}
 Specify this parameter to run individual tests by file name, overriding the 
 includes/excludes parameters. Each pattern you specify here will be used to 
 create an include pattern formatted like **/${test}.java, so you can just 
 type -Dtest=MyTest to run a single test called foo/MyTest.java.
 This parameter overrides the includes/excludes parameters, and the TestNG 
 suiteXmlFiles parameter.
 {quote}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (SUREFIRE-803) Multiple Surefire executions - FAILURE in an execution prevents successive from running.

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/SUREFIRE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285348#comment-285348
 ] 

John Casey commented on SUREFIRE-803:
-

My big question would be where in the build lifecycle the tests execute, vs. 
where they get verified.

Also, would this be a mode of operation that we turn on, or would users with 
the simpler use case experience a different build plan as a result of this 
change?

 Multiple Surefire executions - FAILURE in an execution prevents successive 
 from running.
 

 Key: SUREFIRE-803
 URL: https://jira.codehaus.org/browse/SUREFIRE-803
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.10
Reporter: Ondrej Zizka
Priority: Critical
 Attachments: surefire-803-failure-prevents-subsequent-executions.zip


 Let's have multiple Surefire executions in a single module (different config 
 needed).
 A failure of a test in one of these executions prevents running the 
 successive.
 Surefire's testFailureIgnore is not an option because it makes a run with 
 failures succeed.
 This behavior is undocumented.
 Also, it is undesired - the module as a whole should fail, but all it's tests 
 should run.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (SUREFIRE-803) Multiple Surefire executions - FAILURE in an execution prevents successive from running.

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/SUREFIRE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285241#comment-285241
 ] 

John Casey commented on SUREFIRE-803:
-

Something akin to what the failsafe plugin does might work, but it'd require a 
surefire mojo executing later in the build process to read the reports and 
trigger the build failure...which means running `mvn clean test

 Multiple Surefire executions - FAILURE in an execution prevents successive 
 from running.
 

 Key: SUREFIRE-803
 URL: https://jira.codehaus.org/browse/SUREFIRE-803
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.10
Reporter: Ondrej Zizka
Priority: Critical

 Let's have multiple Surefire executions in a single module (different config 
 needed).
 A failure of a test in one of these executions prevents running the 
 successive.
 Surefire's testFailureIgnore is not an option because it makes a run with 
 failures succeed.
 This behavior is undocumented.
 Also, it is undesired - the module as a whole should fail, but all it's tests 
 should run.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Issue Comment Edited: (SUREFIRE-803) Multiple Surefire executions - FAILURE in an execution prevents successive from running.

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/SUREFIRE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285241#comment-285241
 ] 

John Casey edited comment on SUREFIRE-803 at 12/8/11 11:39 AM:
---

Something akin to what the failsafe plugin does might work, but it'd require a 
surefire mojo executing later in the build process to read the reports and 
trigger the build failure...which means running `mvn clean test` might not cut 
it without re-shuffling the surefire executions to some earlier phase.

There might be other ways to detect whether the current execution is the last 
(and therefore whether it's okay to fail the build now), but I'm not sure off 
the top of my head.

  was (Author: jdcasey):
Something akin to what the failsafe plugin does might work, but it'd 
require a surefire mojo executing later in the build process to read the 
reports and trigger the build failure...which means running `mvn clean test
  
 Multiple Surefire executions - FAILURE in an execution prevents successive 
 from running.
 

 Key: SUREFIRE-803
 URL: https://jira.codehaus.org/browse/SUREFIRE-803
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.10
Reporter: Ondrej Zizka
Priority: Critical

 Let's have multiple Surefire executions in a single module (different config 
 needed).
 A failure of a test in one of these executions prevents running the 
 successive.
 Surefire's testFailureIgnore is not an option because it makes a run with 
 failures succeed.
 This behavior is undocumented.
 Also, it is undesired - the module as a whole should fail, but all it's tests 
 should run.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (SUREFIRE-803) Multiple Surefire executions - FAILURE in an execution prevents successive from running.

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/SUREFIRE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey updated SUREFIRE-803:


Attachment: surefire-803-failure-prevents-subsequent-executions.zip

I believe this is the basic test case that distills the issue. Of course, 
multimodule builds may also exhibit the symptom found here, but they also 
obscure the essential bug, IMO. Fix this test case, and the multimodule case 
will be fixed as well.

 Multiple Surefire executions - FAILURE in an execution prevents successive 
 from running.
 

 Key: SUREFIRE-803
 URL: https://jira.codehaus.org/browse/SUREFIRE-803
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.10
Reporter: Ondrej Zizka
Priority: Critical
 Attachments: surefire-803-failure-prevents-subsequent-executions.zip


 Let's have multiple Surefire executions in a single module (different config 
 needed).
 A failure of a test in one of these executions prevents running the 
 successive.
 Surefire's testFailureIgnore is not an option because it makes a run with 
 failures succeed.
 This behavior is undocumented.
 Also, it is undesired - the module as a whole should fail, but all it's tests 
 should run.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MASSEMBLY-581) Allow formats in configuration to override descriptor

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MASSEMBLY-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=284436#comment-284436
 ] 

John Casey commented on MASSEMBLY-581:
--

It seems like a reasonable enough thing, especially since the calculation of 
the assembly contents is meant to be format-agnostic as much as possible. I 
still think it's a good idea to have a default set of formats specified in 
the assembly itself, but overriding with a format subset (or even something 
completely separate) via plugin configuration makes sense, especially when 
reusing standard descriptors.

 Allow formats in configuration to override descriptor
 -

 Key: MASSEMBLY-581
 URL: https://jira.codehaus.org/browse/MASSEMBLY-581
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Benson Margulies

 I constantly find myself creating families of several descriptors that differ 
 only in 'formats'. I claim that it makes sense to treat formats as not part 
 of the spec of the assembly, but rather of how the spec is applied. 
 If no one objects, I'll write the code so that the configuration can contain 
 formats that override the descriptor.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MASSEMBLY-249) Crashing file name that is using special chars

[John Casey (JIRA)]

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

John Casey closed MASSEMBLY-249.


Resolution: Cannot Reproduce
  Assignee: John Casey

 Crashing file name that is using special chars
 --

 Key: MASSEMBLY-249
 URL: https://jira.codehaus.org/browse/MASSEMBLY-249
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-1
Reporter: Endrigo Antonini
Assignee: John Casey
 Attachments: example.rar


 I was using this plugin to zip. But when I have a file name that uses special 
 chars, like ç, it crashs when zipping.
 Attached is an example of it.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MSHARED-205) wildcard in middle of artifact-coordinate segment not recognized in Pattern*ArtifactFilter

[John Casey (JIRA)]

 [ 
https://jira.codehaus.org/browse/MSHARED-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey closed MSHARED-205.
--

   Resolution: Fixed
Fix Version/s: maven-common-artifact-filters-1.4
 Assignee: John Casey

Added tests and implementation.

 wildcard in middle of artifact-coordinate segment not recognized in 
 Pattern*ArtifactFilter
 --

 Key: MSHARED-205
 URL: https://jira.codehaus.org/browse/MSHARED-205
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-common-artifact-filters
Affects Versions: maven-common-artifact-filters-1.3
Reporter: John Casey
Assignee: John Casey
 Fix For: maven-common-artifact-filters-1.4


 This works:
 {code:xml}includeorg.apache.maven.plugins:*-plugin/include{code}
 As does this:
 {code:xml}includeorg.apache.maven.plugins:maven-*/include{code}
 But NOT this:
 {code:xml}includeorg.apache.maven.plugins:maven*plugin/include{code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MASSEMBLY-570) dependency includes filters don't match wildcard (*) in middle of coordinate segment

[John Casey (JIRA)]

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

John Casey closed MASSEMBLY-570.


Resolution: Fixed
  Assignee: John Casey

fixed in maven-common-artifact-filters, and added an integration test in the 
assembly plugin to verify the fix.

 dependency includes filters don't match wildcard (*) in middle of coordinate 
 segment
 

 Key: MASSEMBLY-570
 URL: https://jira.codehaus.org/browse/MASSEMBLY-570
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2.1
Reporter: John Casey
Assignee: John Casey
 Fix For: 2.3


 This works:
 {code:xml}includeorg.apache.maven.plugins:*-plugin/include{code}
 As does this:
 {code:xml}includeorg.apache.maven.plugins:maven-*/include{code}
 But NOT this:
 {code:xml}includeorg.apache.maven.plugins:maven*plugin/include{code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MASSEMBLY-531) Define finalName for each assembly

[John Casey (JIRA)]

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

John Casey closed MASSEMBLY-531.


Resolution: Won't Fix
  Assignee: John Casey

You can set this per-execution in the plugin definition, and assign each 
assembly descriptor to a separate execution section to separate the finalNames.

You don't need the ability to configure it in the assembly descriptor.

 Define finalName for each assembly
 --

 Key: MASSEMBLY-531
 URL: https://jira.codehaus.org/browse/MASSEMBLY-531
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
Affects Versions: 2.2
Reporter: Thomas Champagne
Assignee: John Casey

 In my project, I would like to create some archives. 
 For example, I must generate an archive for SQL Script (bases.xml) and an 
 archive for static web file (images, css, js...) (static.xml). 
 In the pom, I declare the assembly plugin with two assemblies descriptor :
 {code}
 plugins
   plugin
 artifactIdmaven-assembly-plugin/artifactId
 version2.2/version
 executions
   execution
 idpackage-hawai/id
 phasepackage/phase
 goals
   goalsingle/goal
 /goals
   /execution
 /executions
 configuration
   appendAssemblyIdtrue/appendAssemblyId
   descriptors
 descriptorsrc/main/assemblies/static.xml/descriptor
 descriptorsrc/main/assemblies/bases.xml/descriptor
   /descriptors
 /configuration
   /plugin
 /plugins
 {code}
 So, assembly plugin generate two archives : 
 [INFO] Building tar : [...]\target\myproject-1.0-SNAPSHOT-static.tar.gz
 [INFO] Building tar : [...]\target\myproject-1.0-SNAPSHOT-bases.tar.gz
 But, It would be nice if the assembly plugin generates archivers named as the 
 assembly ID.
 [INFO] Building tar : [...]\target\static.tar.gz
 [INFO] Building tar : [...]\target\bases.tar.gz
 A solution could be to define the finalName property like this : 
 finalName${assembly.id}/finalName
 Thomas

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MASSEMBLY-324) DependencySet scope runtime includes jars that are scope provided

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MASSEMBLY-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=277581#comment-277581
 ] 

John Casey commented on MASSEMBLY-324:
--

Does anyone know if this is still happening in maven-assembly-plugin version 
2.2.1?

 DependencySet scope runtime includes jars that are scope provided
 -

 Key: MASSEMBLY-324
 URL: https://jira.codehaus.org/browse/MASSEMBLY-324
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-2
Reporter: Michael Mattox

 I use some jars in provided scope:
   dependency
   groupIdjavax.servlet/groupId
   artifactIdservlet-api/artifactId
   version2.5/version
   scopeprovided/scope
   /dependency
 in my assembly, I specify scope as runtime:
   dependencySet
   outputDirectoryWEB-INF/lib/outputDirectory
   unpackfalse/unpack
   scoperuntime/scope
   /dependencySet
 Yet I still find the servlet-api-2.5.jar in my WAR.  SInce the servlet-api is 
 scope provided, it should be provided by the container and not included in 
 the WAR.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MASSEMBLY-175) MANIFEST entries are not preserved during assemby

[John Casey (JIRA)]

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

John Casey closed MASSEMBLY-175.


Resolution: Won't Fix
  Assignee: John Casey

I don't think there's a reasonable way to specify the merging rules for 
manifests...which assembly constituent gets preference in a collision? Also, I 
don't think it's reasonable to assume that manifest entries for an assembly 
will be the same as for the original project jar.

Is there a reason you can't use the same archive configuration subsection 
that you'd use in the jar plugin, and specify the manifest that way?

If someone is willing to submit a patch that contains integration tests showing 
how to specify merge rules for colliding manifest attributes, how to turn off 
manifest merging, and so forth, then we can reopen...but it seems like 
automatic merging is one of those places that could lead to a lot of 
consternation about what the plugin is doing, and why.

 MANIFEST entries are not preserved during assemby
 -

 Key: MASSEMBLY-175
 URL: https://jira.codehaus.org/browse/MASSEMBLY-175
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Tomasz Pik
Assignee: John Casey
 Fix For: 2.3


 jar-with-dependencies assembly should preserve MANIFEST entries from 
 project main result (so configuration for this will be inherited from 
 maven-jar-plugin).
 This is especially important in case for mainClass parameter.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MASSEMBLY-570) dependency includes filters don't match wildcard (*) in middle of coordinate segment

[John Casey (JIRA)]

dependency includes filters don't match wildcard (*) in middle of coordinate 
segment


 Key: MASSEMBLY-570
 URL: https://jira.codehaus.org/browse/MASSEMBLY-570
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2.1
Reporter: John Casey


This works:

{code:xml}includeorg.apache.maven.plugins:*-plugin/include{code}

As does this:

{code:xml}includeorg.apache.maven.plugins:maven-*/include{code}

But NOT this:

{code:xml}includeorg.apache.maven.plugins:maven*plugin/include{code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-570) dependency includes filters don't match wildcard (*) in middle of coordinate segment

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-570:
-

Fix Version/s: 2.3

 dependency includes filters don't match wildcard (*) in middle of coordinate 
 segment
 

 Key: MASSEMBLY-570
 URL: https://jira.codehaus.org/browse/MASSEMBLY-570
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2.1
Reporter: John Casey
 Fix For: 2.3


 This works:
 {code:xml}includeorg.apache.maven.plugins:*-plugin/include{code}
 As does this:
 {code:xml}includeorg.apache.maven.plugins:maven-*/include{code}
 But NOT this:
 {code:xml}includeorg.apache.maven.plugins:maven*plugin/include{code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MSHARED-205) wildcard in middle of artifact-coordinate segment not recognized in Pattern*ArtifactFilter

[John Casey (JIRA)]

wildcard in middle of artifact-coordinate segment not recognized in 
Pattern*ArtifactFilter
--

 Key: MSHARED-205
 URL: https://jira.codehaus.org/browse/MSHARED-205
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-common-artifact-filters
Affects Versions: maven-common-artifact-filters-1.3
Reporter: John Casey


This works:

{code:xml}includeorg.apache.maven.plugins:*-plugin/include{code}

As does this:

{code:xml}includeorg.apache.maven.plugins:maven-*/include{code}

But NOT this:

{code:xml}includeorg.apache.maven.plugins:maven*plugin/include{code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MASSEMBLY-561) Encoding is broken when filtering is enabled

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MASSEMBLY-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274147#comment-274147
 ] 

John Casey commented on MASSEMBLY-561:
--

Hi Julien,

It seems like the ISO-8859-1 test you added in your patch doesn't work, at 
least not on my machine (OS X 10.6.8, US English [default?] language settings). 
The output from the verification script is:

iso88591.config was not filtered with correct encoding

I'll try to poke around some more later, but for now I just wanted to let you 
know.

 Encoding is broken when filtering is enabled
 

 Key: MASSEMBLY-561
 URL: https://jira.codehaus.org/browse/MASSEMBLY-561
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Julien HENRY
Priority: Critical
 Attachments: MASSEMBLY-561.patch


 My resources are encoded in ISO-8859-1. I have specified encoding in the pom: 
 {code}project.build.sourceEncodingISO-8859-1/project.build.sourceEncoding{code}
 I have written a custom assembly file and I am using resource filtering.
 {code}...
 fileSet
   directory${project.basedir}/src/main/resources//directory
   outputDirectory//outputDirectory
   filteredtrue/filtered
 /fileSet
 ...{code}
 As a result all the french characters are broken in the resulting zip 
 assembly. My platform is Linux so the default platform encoding is UTF-8.
 I have checked plugin code and I think I found the issue. This is in 
 FileFormatter.java, method doFileFilter():
 {code}
 configSource.getMavenFileFilter().copyFile( source, target, true, 
 configSource.getProject(),
 configSource.getFilters(), isPropertiesFile, null, 
 configSource.getMavenSession() );
 {code}
 You can see that enconding is set to null, so I think it means using default 
 platform encoding... Would it be possible to use value of 
 project.build.sourceEncoding instead?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MASSEMBLY-494) No way to set the directory mode for the base directory nor any implicitly created directory for zip assemblies

[John Casey (JIRA)]

[ 
https://jira.codehaus.org/browse/MASSEMBLY-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=273236#comment-273236
 ] 

John Casey commented on MASSEMBLY-494:
--

Try the following assembly plugin configuration, in your pom.xml:

{code:xml}
archiverConfig
  defaultDirectoryMode0755/defaultDirectoryMode
/archiverConfig
{code}

I've verified that this provides the ability to manage the default directory 
mode for automatically created / implied directories.

 No way to set the directory mode for the base directory nor any implicitly 
 created directory for zip assemblies
 ---

 Key: MASSEMBLY-494
 URL: https://jira.codehaus.org/browse/MASSEMBLY-494
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-5
 Environment: Debian GNU/Linux
Reporter: Arnaud de Bossoreille
 Attachments: assembly-test.zip


 A sample maven project is attached to reproduce everything. I am trying to 
 generate a zip file with correct permissions (i.e. directories not writable 
 by everyone which I would say should not be too difficult).
 If you run `mvn assembly:assembly` as is, you will have:
 drwxrwxrwx ... assembly-test-1.0.0/
 drwxrwxrwx ... assembly-test-1.0.0/bin/
 -rw-r--r-- ... assembly-test-1.0.0/bin/assembly-test-1.0.0.jar
 -rw-r--r-- ... assembly-test-1.0.0/bin/commons-lang-2.4.jar
 drwxr-xr-x ... assembly-test-1.0.0/copyofsubdir/
 -rw-r--r-- ... assembly-test-1.0.0/copyofsubdir/file
 I found no way to set the first two directories permissions. If you add the 
 two directoryMode tags, you will have:
 drwxrwxrwx ... assembly-test-1.0.0/
 drwxrwxrwx ... assembly-test-1.0.0/bin/
 -rw-r--r-- ... assembly-test-1.0.0/bin/assembly-test-1.0.0.jar
 -rw-r--r-- ... assembly-test-1.0.0/bin/commons-lang-2.4.jar
 drwxr-xr-x ... assembly-test-1.0.0/copyofsubdir/
 -rwxrwxrwx ... assembly-test-1.0.0/copyofsubdir/file*
 ... which is pretty much what I did NOT expect (a cut'n paste issue in the 
 code?). If you add both directoryMode and fileMode, you will have the same 
 results as the first iteration (see above).
 Unfortunately I still cannot change the permissions of:
 - the base directory (assembly-test-1.0.0)
 - any directory that is not present on the file system (bin)
 I looked a bit at the code and, as far as I can see, it may be linked to the 
 plexus zip archiver (although it may not be responsible for the bug) which 
 automatically adds parent directories but most probably with incorrect 
 permissions due to bad configuration.
 I did not test with other assembly formats.
 PS: yes I can do a simple tarball, and I will probably do that while waiting 
 for a patch. But I think it is important that you are aware of something 
 which may annoy more than one single user in the world.
 Regards.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MASSEMBLY-494) No way to set the directory mode for the base directory nor any implicitly created directory for zip assemblies

[John Casey (JIRA)]

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

John Casey closed MASSEMBLY-494.


Resolution: Not A Bug
  Assignee: John Casey

 No way to set the directory mode for the base directory nor any implicitly 
 created directory for zip assemblies
 ---

 Key: MASSEMBLY-494
 URL: https://jira.codehaus.org/browse/MASSEMBLY-494
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-5
 Environment: Debian GNU/Linux
Reporter: Arnaud de Bossoreille
Assignee: John Casey
 Attachments: assembly-test.zip


 A sample maven project is attached to reproduce everything. I am trying to 
 generate a zip file with correct permissions (i.e. directories not writable 
 by everyone which I would say should not be too difficult).
 If you run `mvn assembly:assembly` as is, you will have:
 drwxrwxrwx ... assembly-test-1.0.0/
 drwxrwxrwx ... assembly-test-1.0.0/bin/
 -rw-r--r-- ... assembly-test-1.0.0/bin/assembly-test-1.0.0.jar
 -rw-r--r-- ... assembly-test-1.0.0/bin/commons-lang-2.4.jar
 drwxr-xr-x ... assembly-test-1.0.0/copyofsubdir/
 -rw-r--r-- ... assembly-test-1.0.0/copyofsubdir/file
 I found no way to set the first two directories permissions. If you add the 
 two directoryMode tags, you will have:
 drwxrwxrwx ... assembly-test-1.0.0/
 drwxrwxrwx ... assembly-test-1.0.0/bin/
 -rw-r--r-- ... assembly-test-1.0.0/bin/assembly-test-1.0.0.jar
 -rw-r--r-- ... assembly-test-1.0.0/bin/commons-lang-2.4.jar
 drwxr-xr-x ... assembly-test-1.0.0/copyofsubdir/
 -rwxrwxrwx ... assembly-test-1.0.0/copyofsubdir/file*
 ... which is pretty much what I did NOT expect (a cut'n paste issue in the 
 code?). If you add both directoryMode and fileMode, you will have the same 
 results as the first iteration (see above).
 Unfortunately I still cannot change the permissions of:
 - the base directory (assembly-test-1.0.0)
 - any directory that is not present on the file system (bin)
 I looked a bit at the code and, as far as I can see, it may be linked to the 
 plexus zip archiver (although it may not be responsible for the bug) which 
 automatically adds parent directories but most probably with incorrect 
 permissions due to bad configuration.
 I did not test with other assembly formats.
 PS: yes I can do a simple tarball, and I will probably do that while waiting 
 for a patch. But I think it is important that you are aware of something 
 which may annoy more than one single user in the world.
 Regards.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MASSEMBLY-556) mvn assembly:assembly NPEs with install:install-file'd artifacts

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-556:
-

Fix Version/s: 2.3
 Assignee: John Casey

 mvn assembly:assembly NPEs with install:install-file'd artifacts
 

 Key: MASSEMBLY-556
 URL: http://jira.codehaus.org/browse/MASSEMBLY-556
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-5
 Environment: Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+) on Win 
 7 x64, Sun Java 6u24 x64.
Reporter: Chris West (Faux)
Assignee: John Casey
 Fix For: 2.3

 Attachments: build.log, pom.xml, repository.xml


 I have 3rd-party jars installed via. {{mvn install:install-file}}.  This 
 causes {{mvn assembly:assembly}} to NPE around:
 {code}
 Caused by: java.lang.NullPointerException
   at 
 org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:61)
   at 
 org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
 ...
 {code}
 To reproduce, first, install:install-file a random file:
 {code}
 mvn install:install-file -Dfile=pom.xml -DgroupId=com.goeswhere.test 
 -DartifactId=a -Dversion=0 -Dpackaging=jar
 {code}
 Then, create pom.xml (attached):
 {code:xml}
 project 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/maven-4.0.0.xsd;
   modelVersion4.0.0/modelVersion
   groupIdcom.goeswhere.test/groupId
   artifactIdb/artifactId
   version1.0-SNAPSHOT/version
   packagingjar/packaging
   dependencies
   dependency
   groupIdcom.goeswhere.test/groupId
   artifactIda/artifactId
   version0/version
   /dependency
   /dependencies
   build
   plugins
   plugin
   artifactIdmaven-assembly-plugin/artifactId
   configuration
   descriptors
   
 descriptor./repository.xml/descriptor
   /descriptors
   /configuration
   /plugin
   /plugins
   /build
 /project
 {code}
 and repository.xml (attached):
 {code:xml}
 assembly
   
 xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2;
   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   
 xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
  http://maven.apache.org/xsd/assembly-1.1.2.xsd;
   idrepository/id
   formats
   formatjar/format
   /formats
   repositories
   repository
   includeMetadatatrue/includeMetadata
   outputDirectorymaven2/outputDirectory
   /repository
   /repositories
 /assembly
 {code}
 And run {{mvn assembly:assembly}}.  See attached build.log.

-- 
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: (MINSTALL-83) The install should also conatin a goal to install directory of external jar files into the repository.

[John Casey (JIRA)]

[ 
http://jira.codehaus.org/browse/MINSTALL-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263573#action_263573
 ] 

John Casey commented on MINSTALL-83:


You can attach a patch to the plugin here, and we'll review it. If everything 
looks ok, we'll commit the code and it'll get picked up in the next release.

 The install should also conatin a goal to install directory of external jar 
 files into the repository.
 --

 Key: MINSTALL-83
 URL: http://jira.codehaus.org/browse/MINSTALL-83
 Project: Maven 2.x Install Plugin
  Issue Type: Improvement
Reporter: Gaurav Mutreja

 The install should conatin a goal to install directory of jar files into the 
 repository.
 It is quite painful to install each jar file one by one(say if we have 100 
 jar files).It would be great if we provide the directory in which jar files 
 are kept to a single command to install all of the files.
 I have worked on it and created a new plug-in which which installs in 
 repository the whole directory at once.The code basically modifies the 
 existing installFile mojo source to support the installation of full 
 directory.
 How can I get it reviewed?So,that I can go ahead and commit the code.
 Thanks
 Gaurav

-- 
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: (MINSTALL-83) The install should also conatin a goal to install directory of external jar files into the repository.

[John Casey (JIRA)]

[ 
http://jira.codehaus.org/browse/MINSTALL-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263575#action_263575
 ] 

John Casey commented on MINSTALL-83:


...But please be sure your patch includes tests, and conforms to the source 
formatting guidelines at:

http://maven.apache.org/developers/conventions/code.html

 The install should also conatin a goal to install directory of external jar 
 files into the repository.
 --

 Key: MINSTALL-83
 URL: http://jira.codehaus.org/browse/MINSTALL-83
 Project: Maven 2.x Install Plugin
  Issue Type: Improvement
Reporter: Gaurav Mutreja

 The install should conatin a goal to install directory of jar files into the 
 repository.
 It is quite painful to install each jar file one by one(say if we have 100 
 jar files).It would be great if we provide the directory in which jar files 
 are kept to a single command to install all of the files.
 I have worked on it and created a new plug-in which which installs in 
 repository the whole directory at once.The code basically modifies the 
 existing installFile mojo source to support the installation of full 
 directory.
 How can I get it reviewed?So,that I can go ahead and commit the code.
 Thanks
 Gaurav

-- 
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-555) Need a better solution than packaging == pom for distribution modules whose output is an assembly

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-555:
-

Fix Version/s: 2.3

 Need a better solution than packaging == pom for distribution modules whose 
 output is an assembly
 -

 Key: MASSEMBLY-555
 URL: http://jira.codehaus.org/browse/MASSEMBLY-555
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
Affects Versions: 2.2.1
Reporter: John Casey
Assignee: John Casey
 Fix For: 2.3


 It's common practice to use a purpose-built module to create a distribution 
 assembly for a project. However, there is no packaging that accommodates 
 this. We need one or more packagings added to the assembly plugin that will 
 allow a proper non-pom packaging.
 Currently, this is an issue if someone tries to create one assembly from a 
 purpose-built module - say, for an examples aggregation - and then use it in 
 another assembly via moduleSet/binaries. Since the packaging is 'pom', the 
 project is NOT included in the moduleSet, because POMs are assumed not to 
 have binaries. Or, if they do, they're assumed to have binaries that are 
 addressable via some classifier...which I'm still not sure would even work 
 with the assembly plugin.
 Bottom line is, we need a better solution than abusing the pom packaging for 
 assembly modules.

-- 
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: (MASSEMBLY-555) Need a better solution than packaging == pom for distribution modules whose output is an assembly

[John Casey (JIRA)]

Need a better solution than packaging == pom for distribution modules whose 
output is an assembly
-

 Key: MASSEMBLY-555
 URL: http://jira.codehaus.org/browse/MASSEMBLY-555
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
Affects Versions: 2.2.1
Reporter: John Casey


It's common practice to use a purpose-built module to create a distribution 
assembly for a project. However, there is no packaging that accommodates this. 
We need one or more packagings added to the assembly plugin that will allow a 
proper non-pom packaging.

Currently, this is an issue if someone tries to create one assembly from a 
purpose-built module - say, for an examples aggregation - and then use it in 
another assembly via moduleSet/binaries. Since the packaging is 'pom', the 
project is NOT included in the moduleSet, because POMs are assumed not to have 
binaries. Or, if they do, they're assumed to have binaries that are addressable 
via some classifier...which I'm still not sure would even work with the 
assembly plugin.

Bottom line is, we need a better solution than abusing the pom packaging for 
assembly modules.

-- 
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-553) Assembly plugin ignores attached assemblies

[John Casey (JIRA)]

[ 
http://jira.codehaus.org/browse/MASSEMBLY-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263595#action_263595
 ] 

John Casey commented on MASSEMBLY-553:
--

Please add some test project, or at least a URL, where this is occurring. 
Without this, it's just a vague description of the problem, and it leaves us 
without a definitive confirmation that we've replicated the problem in a test 
case.

 Assembly plugin ignores attached assemblies
 ---

 Key: MASSEMBLY-553
 URL: http://jira.codehaus.org/browse/MASSEMBLY-553
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2, 2.2.1
Reporter: SebbASF
Assignee: John Casey
Priority: Critical
 Fix For: 2.3

 Attachments: assembly-bug.zip


 This used to work in 2.2-beta-5, but both 2.2 and 2.2.1 seem to ignore 
 attached descriptors in mvn install
 Sample project to follow.
 This works:
 mvn -Dass.vers=2.2-beta-5 install -Prc
 This does not:
 mvn -Dass.vers=2.2.1 install -Prc
 If you compare the ouput from the two runs, you will see that the following 
 is missing from 2.2.1:
 [INFO] [assembly:attached {execution: default}]
 [INFO] Reading assembly descriptor: src/assembly/bin.xml
 [INFO] Reading assembly descriptor: src/assembly/src.xml
 [INFO] Building zip: 
 D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-bin.zip
 [INFO] Building zip: 
 D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-src.zip
 Apache Commons cannot use 2.2 or 2.2.1 as a result of this bug

-- 
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-553) Assembly plugin ignores attached assemblies

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-553:
-

Fix Version/s: 2.3

 Assembly plugin ignores attached assemblies
 ---

 Key: MASSEMBLY-553
 URL: http://jira.codehaus.org/browse/MASSEMBLY-553
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2, 2.2.1
Reporter: SebbASF
Assignee: John Casey
Priority: Critical
 Fix For: 2.3

 Attachments: assembly-bug.zip


 This used to work in 2.2-beta-5, but both 2.2 and 2.2.1 seem to ignore 
 attached descriptors in mvn install
 Sample project to follow.
 This works:
 mvn -Dass.vers=2.2-beta-5 install -Prc
 This does not:
 mvn -Dass.vers=2.2.1 install -Prc
 If you compare the ouput from the two runs, you will see that the following 
 is missing from 2.2.1:
 [INFO] [assembly:attached {execution: default}]
 [INFO] Reading assembly descriptor: src/assembly/bin.xml
 [INFO] Reading assembly descriptor: src/assembly/src.xml
 [INFO] Building zip: 
 D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-bin.zip
 [INFO] Building zip: 
 D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-src.zip
 Apache Commons cannot use 2.2 or 2.2.1 as a result of this bug

-- 
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: (MASSEMBLY-551) dependencySet with useTransitiveDependencies == false does not process relocations

[John Casey (JIRA)]

dependencySet with useTransitiveDependencies == false does not process 
relocations
--

 Key: MASSEMBLY-551
 URL: http://jira.codehaus.org/browse/MASSEMBLY-551
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2.1, 2.2
Reporter: John Casey


relocations processing happens in the dependency collector in Maven, which is 
used to create the full list of transitive dependencies during the resolution 
process. When the assembly plugin processes a dependencySet non-transitively it 
bypasses this dependency collector, and relocations are never processed.



-- 
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-551) dependencySet with useTransitiveDependencies == false does not process relocations

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-551:
-

Fix Version/s: 2.3
 Assignee: John Casey

 dependencySet with useTransitiveDependencies == false does not process 
 relocations
 --

 Key: MASSEMBLY-551
 URL: http://jira.codehaus.org/browse/MASSEMBLY-551
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2, 2.2.1
Reporter: John Casey
Assignee: John Casey
 Fix For: 2.3


 relocations processing happens in the dependency collector in Maven, which is 
 used to create the full list of transitive dependencies during the resolution 
 process. When the assembly plugin processes a dependencySet non-transitively 
 it bypasses this dependency collector, and relocations are never processed.

-- 
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: (MJAVADOC-275) Creation of Javadoc attachments fails in multi-module project where modules have never been installed/deployed

[John Casey (JIRA)]

[ 
http://jira.codehaus.org/browse/MJAVADOC-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=260932#action_260932
 ] 

John Casey commented on MJAVADOC-275:
-

what about 2.8? can we close this issue now that MJAVADOC-284 is closed? I 
haven't seen it, unless you're talking about the case where the javadoc plugin 
forks a new build in order to produce javadocs for dependencies...for which 
there is a flag to skip that, and I'm assuming MJAVADOC-284 has fixed in a more 
permanent way.

 Creation of Javadoc attachments fails in multi-module project where modules 
 have never been installed/deployed
 --

 Key: MJAVADOC-275
 URL: http://jira.codehaus.org/browse/MJAVADOC-275
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.6.1
Reporter: Benjamin Bentmann
Assignee: John Casey
Priority: Critical
 Fix For: 2.7

 Attachments: MJAVADOC-275.zip


 Running the commands
 {noformat}
 mvn clean
 mvn verify
 {noformat}
 will fail on the attached demo project with
 {noformat}
 [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.6.1:javadoc'
   has not be previously called for the project: 
 'org.apache.maven.its.javadoc:mod-b:jar:0.1'.
   Trying to invoke it...
 [ERROR] MavenInvocationException: Error when invoking Maven, consult the 
 invoker log file:
   M:\MJAVADOC\mod-a\target\invoker\maven-javadoc-plugin625147587.txt
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] MavenReportException: Error while creating archive:
   Error when invoking Maven, consult the invoker log file: 
   M:\MJAVADOC\mod-a\target\invoker\maven-javadoc-plugin625147587.txt
 {noformat}
 The command {{mvn clean verify}} as usually used during releases will also 
 fail, but starts working after repeated invocations. 

-- 
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: (MASSEMBLY-547) The class CommandLineUtils doesn't have an Apache license

[John Casey (JIRA)]

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

John Casey closed MASSEMBLY-547.


   Resolution: Fixed
Fix Version/s: 2.3
 Assignee: John Casey

Fixed in revId 1074695...removed and reverted to using plexus-utils version of 
the class.

Verified that ITs still pass, and also that the Maven prerequisite is more 
recent than the version where the plexus-utils version was compatible (which 
was in maven versions after 2.0.5).

 The class CommandLineUtils doesn't have an Apache license
 -

 Key: MASSEMBLY-547
 URL: http://jira.codehaus.org/browse/MASSEMBLY-547
 Project: Maven 2.x Assembly Plugin
  Issue Type: Task
Affects Versions: 2.2
Reporter: Dennis Lundberg
Assignee: John Casey
 Fix For: 2.3


 The class was copied from plexus-utils in r518992 with this commit message:
 Adding utility from plexus-utils 1.4 so I can revert the dep on plexus-utils 
 to 1.1 for maven 2.0.x compat.
 The correct was to solve this is to remove the class and use the one that is 
 in plexus-utils, now that we are able to do so.

-- 
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-510) leading period ('.') added to directory names

[John Casey (JIRA)]

[ 
http://jira.codehaus.org/browse/MASSEMBLY-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=257513#action_257513
 ] 

John Casey commented on MASSEMBLY-510:
--

working on it right now. Hopefully, it's fixed, but the ITs will tell... :-)

 leading period ('.') added to directory names
 -

 Key: MASSEMBLY-510
 URL: http://jira.codehaus.org/browse/MASSEMBLY-510
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2
 Environment: Windows XP, SP3
 Maven 2.2.1
 Maven Assembly 2.2
Reporter: KP
Assignee: John Casey
 Fix For: 2.2.1

 Attachments: dist.xml, pom.xml


 $ cat dist.xml
 assembly 
 xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
  http://maven.apache.org/xsd/assembly-1.1.0.xsd;
   iddist/id
   formats
 formatzip/format
   /formats
   
   
   fileSets
  fileSet
 directory${project.basedir}/../paper/directory
  /fileSet
  fileSet
 directory${project.basedir}/../boots/directory
  /fileSet
   /fileSets
 
 /assembly
 $ mvn clean assembly:assembly
 [INFO] Scanning for projects...
 [INFO] 
 
 [INFO] Building oracle-sql-assembly
 [INFO]task-segment: [clean]
 [INFO] 
 
 [INFO] [clean:clean {execution: default-clean}]
 [INFO] Deleting directory F:\test-assembly\target
 [INFO] 
 
 [INFO] Building oracle-sql-assembly
 [INFO]task-segment: [assembly:assembly] (aggregator-style)
 [INFO] 
 
 [INFO] Preparing assembly:assembly
 [INFO] 
 
 [INFO] Building oracle-sql-assembly
 [INFO] 
 
 [INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
 [INFO] [assembly:assembly {execution: default-cli}]
 [INFO] Reading assembly descriptor: src/main/assembly/dist.xml
 [INFO] Building zip: 
 F:\test-assembly\target\test-assembly-3.1-SNAPSHOT-dist.zip
 [INFO] 
 
 [INFO] BUILD SUCCESSFUL
 [INFO] 
 
 [INFO] Total time: 2 seconds
 [INFO] Finished at: Mon Oct 11 15:34:37 EDT 2010
 [INFO] Final Memory: 18M/45M
 [INFO] 
 
 $ unzip -l target/test-assembly-dist.zip 
 Archive:  target/test-assembly-dist.zip
   Length  DateTimeName
 -  -- -   
 0  10-11-2010 15:34   test-assembly/
 0  10-11-2010 15:27   test-assembly/.paper/
 0  10-11-2010 15:27   test-assembly/.paper/random.txt
 0  10-11-2010 15:27   test-assembly/.boots/
 0  10-11-2010 15:27   test-assembly/.boots/boots.txt
 - ---
 0 5 files
 Do you notice the '.paper' and '.boots' directories?  It should just be 
 'paper' and 'boots', if I'm understanding it correctly.
 I tried other versions of the plugin (e.g., beta-4), I tried removing 
 ${project.basedir}/.
 No go. :(
 P.S. If someone points me in the right direction, like a class name, I'll 
 write a test case.

-- 
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: (MASSEMBLY-510) leading period ('.') added to directory names

[John Casey (JIRA)]

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

John Casey closed MASSEMBLY-510.


Resolution: Fixed

Fixed. Unit tests in place to verify that handling of . and .. are handled 
correctly. See AssemblyFormatUtilsTest.testFixRelativePathRefs_*

 leading period ('.') added to directory names
 -

 Key: MASSEMBLY-510
 URL: http://jira.codehaus.org/browse/MASSEMBLY-510
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2
 Environment: Windows XP, SP3
 Maven 2.2.1
 Maven Assembly 2.2
Reporter: KP
Assignee: John Casey
 Fix For: 2.2.1

 Attachments: dist.xml, pom.xml


 $ cat dist.xml
 assembly 
 xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
  http://maven.apache.org/xsd/assembly-1.1.0.xsd;
   iddist/id
   formats
 formatzip/format
   /formats
   
   
   fileSets
  fileSet
 directory${project.basedir}/../paper/directory
  /fileSet
  fileSet
 directory${project.basedir}/../boots/directory
  /fileSet
   /fileSets
 
 /assembly
 $ mvn clean assembly:assembly
 [INFO] Scanning for projects...
 [INFO] 
 
 [INFO] Building oracle-sql-assembly
 [INFO]task-segment: [clean]
 [INFO] 
 
 [INFO] [clean:clean {execution: default-clean}]
 [INFO] Deleting directory F:\test-assembly\target
 [INFO] 
 
 [INFO] Building oracle-sql-assembly
 [INFO]task-segment: [assembly:assembly] (aggregator-style)
 [INFO] 
 
 [INFO] Preparing assembly:assembly
 [INFO] 
 
 [INFO] Building oracle-sql-assembly
 [INFO] 
 
 [INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
 [INFO] [assembly:assembly {execution: default-cli}]
 [INFO] Reading assembly descriptor: src/main/assembly/dist.xml
 [INFO] Building zip: 
 F:\test-assembly\target\test-assembly-3.1-SNAPSHOT-dist.zip
 [INFO] 
 
 [INFO] BUILD SUCCESSFUL
 [INFO] 
 
 [INFO] Total time: 2 seconds
 [INFO] Finished at: Mon Oct 11 15:34:37 EDT 2010
 [INFO] Final Memory: 18M/45M
 [INFO] 
 
 $ unzip -l target/test-assembly-dist.zip 
 Archive:  target/test-assembly-dist.zip
   Length  DateTimeName
 -  -- -   
 0  10-11-2010 15:34   test-assembly/
 0  10-11-2010 15:27   test-assembly/.paper/
 0  10-11-2010 15:27   test-assembly/.paper/random.txt
 0  10-11-2010 15:27   test-assembly/.boots/
 0  10-11-2010 15:27   test-assembly/.boots/boots.txt
 - ---
 0 5 files
 Do you notice the '.paper' and '.boots' directories?  It should just be 
 'paper' and 'boots', if I'm understanding it correctly.
 I tried other versions of the plugin (e.g., beta-4), I tried removing 
 ${project.basedir}/.
 No go. :(
 P.S. If someone points me in the right direction, like a class name, I'll 
 write a test case.

-- 
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: (MASSEMBLY-500) Embedded error: Unrecognised tag: 'files' (position: START_TAG seen .../includeBaseDirectory\n\n\nfiles... @9:8)

[John Casey (JIRA)]

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

John Casey closed MASSEMBLY-500.


Resolution: Cannot Reproduce
  Assignee: John Casey

 Embedded error: Unrecognised tag: 'files' (position: START_TAG seen 
 .../includeBaseDirectory\n\n\nfiles... @9:8)
 

 Key: MASSEMBLY-500
 URL: http://jira.codehaus.org/browse/MASSEMBLY-500
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Reporter: Dayashankar
Assignee: John Casey
 Attachments: assembly.xml


 Hi team,
 I'm using attached assembly.xml file and while doing mvn assembly:assembly is 
 resulting in following error:
 [INFO] Error reading descriptor
 Embedded error: Unrecognised tag: 'files' (position: START_TAG seen 
 .../includeBaseDirectory\n\n\nfiles... @9:8)
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: Error reading 
 descriptor
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
 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: Error reading 
 descriptor
 at 
 org.apache.maven.plugin.assembly.AssemblyMojo.readAssembly(AssemblyMojo.java:238)
 at 
 org.apache.maven.plugin.assembly.AssemblyMojo.execute(AssemblyMojo.java:144)
 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.codehaus.plexus.util.xml.pull.XmlPullParserException: 
 Unrecognised tag: 'files' (position: START_TAG seen 
 .../includeBaseDirectory\n\n\nfiles... @9:8)
 at 
 org.apache.maven.plugins.assembly.model.io.xpp3.AssemblyXpp3Reader.parseAssembly(AssemblyXpp3Reader.java:371)
 at 
 org.apache.maven.plugins.assembly.model.io.xpp3.AssemblyXpp3Reader.read(AssemblyXpp3Reader.java:982)
 at 
 org.apache.maven.plugin.assembly.AssemblyMojo.readAssembly(AssemblyMojo.java:230)

-- 
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-510) leading period ('.') added to directory names

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-510:
-

Fix Version/s: 2.2.1
 Assignee: John Casey

This should be a relatively simple fix. Time permitting I'll try to get it done 
for 2.2.1 release.

 leading period ('.') added to directory names
 -

 Key: MASSEMBLY-510
 URL: http://jira.codehaus.org/browse/MASSEMBLY-510
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2
 Environment: Windows XP, SP3
 Maven 2.2.1
 Maven Assembly 2.2
Reporter: KP
Assignee: John Casey
 Fix For: 2.2.1

 Attachments: dist.xml, pom.xml


 $ cat dist.xml
 assembly 
 xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
  http://maven.apache.org/xsd/assembly-1.1.0.xsd;
   iddist/id
   formats
 formatzip/format
   /formats
   
   
   fileSets
  fileSet
 directory${project.basedir}/../paper/directory
  /fileSet
  fileSet
 directory${project.basedir}/../boots/directory
  /fileSet
   /fileSets
 
 /assembly
 $ mvn clean assembly:assembly
 [INFO] Scanning for projects...
 [INFO] 
 
 [INFO] Building oracle-sql-assembly
 [INFO]task-segment: [clean]
 [INFO] 
 
 [INFO] [clean:clean {execution: default-clean}]
 [INFO] Deleting directory F:\test-assembly\target
 [INFO] 
 
 [INFO] Building oracle-sql-assembly
 [INFO]task-segment: [assembly:assembly] (aggregator-style)
 [INFO] 
 
 [INFO] Preparing assembly:assembly
 [INFO] 
 
 [INFO] Building oracle-sql-assembly
 [INFO] 
 
 [INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
 [INFO] [assembly:assembly {execution: default-cli}]
 [INFO] Reading assembly descriptor: src/main/assembly/dist.xml
 [INFO] Building zip: 
 F:\test-assembly\target\test-assembly-3.1-SNAPSHOT-dist.zip
 [INFO] 
 
 [INFO] BUILD SUCCESSFUL
 [INFO] 
 
 [INFO] Total time: 2 seconds
 [INFO] Finished at: Mon Oct 11 15:34:37 EDT 2010
 [INFO] Final Memory: 18M/45M
 [INFO] 
 
 $ unzip -l target/test-assembly-dist.zip 
 Archive:  target/test-assembly-dist.zip
   Length  DateTimeName
 -  -- -   
 0  10-11-2010 15:34   test-assembly/
 0  10-11-2010 15:27   test-assembly/.paper/
 0  10-11-2010 15:27   test-assembly/.paper/random.txt
 0  10-11-2010 15:27   test-assembly/.boots/
 0  10-11-2010 15:27   test-assembly/.boots/boots.txt
 - ---
 0 5 files
 Do you notice the '.paper' and '.boots' directories?  It should just be 
 'paper' and 'boots', if I'm understanding it correctly.
 I tried other versions of the plugin (e.g., beta-4), I tried removing 
 ${project.basedir}/.
 No go. :(
 P.S. If someone points me in the right direction, like a class name, I'll 
 write a test case.

-- 
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-528) FileSet does not support filtering (again)

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-528:
-

Fix Version/s: 2.2.1
 Assignee: John Casey

I'll try to get this one fixed for 2.2.1 as well.

 FileSet does not support filtering (again)
 --

 Key: MASSEMBLY-528
 URL: http://jira.codehaus.org/browse/MASSEMBLY-528
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Maik Richey
Assignee: John Casey
Priority: Critical
 Fix For: 2.2.1

 Attachments: MASSEMBLY-528_sample.zip


 After switching to version 2.2 of the Assembly Plugin filtering for FileSets 
 does not work again as in versions prior to 2.2-beta-3.
 Can anybody confirm this 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] Updated: (MASSEMBLY-524) Make recommended goal usage more explicit; separate non-deprecated goals from deprecated ones explicitly

[John Casey (JIRA)]

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

John Casey updated MASSEMBLY-524:
-

Fix Version/s: 2.2.1
 Assignee: John Casey

This is probably a documentation issue at least until 2.3, when we can probably 
remove the deprecated mojos altogether. I'll try to get it done for 2.2.1.

 Make recommended goal usage more explicit; separate non-deprecated goals from 
 deprecated ones explicitly
 

 Key: MASSEMBLY-524
 URL: http://jira.codehaus.org/browse/MASSEMBLY-524
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
Affects Versions: 2.2
Reporter: John Casey
Assignee: John Casey
 Fix For: 2.2.1


 currently, the deprecation notices / warnings dominate any list of goals in 
 the assembly plugin, largely owing to their large number.
 We need to review the documents and be more direct about telling the user 
 which goals *should* be used.

-- 
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: (MASSEMBLY-475) Flattening directories in file sets

[John Casey (JIRA)]

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

John Casey closed MASSEMBLY-475.


Resolution: Duplicate
  Assignee: John Casey

This issue is contained within the larger issue MASSEMBLY-45

 Flattening directories in file sets
 ---

 Key: MASSEMBLY-475
 URL: http://jira.codehaus.org/browse/MASSEMBLY-475
 Project: Maven 2.x Assembly Plugin
  Issue Type: Improvement
Reporter: Andrew Rampulla
Assignee: John Casey

 A feature I would like is to be able to specify a fileSet such that I specify 
 a root directory X and an include pattern of a/*/target/*.war and have it 
 populate the archive with a flattened directory.
 For example:
 My source structure
 a/test1/target/test1.war
 a/test2/target/test2.war
 Desired output archive:
 test1.war
 test2.war
 This way I can just include everything I want from a subdirectory into my 
 distribution archive.

-- 
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-3321) Skip plugin and/or execution

[John Casey (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=253766#action_253766
 ] 

John Casey commented on MNG-3321:
-

I've noted this on the dev@ ML, but I'll add a short comment here as well.

I think this is a great idea, and I like the approach of the patch. However, 
I'd like to see us take it a little further before we consider releasing a 
version of Maven with this patch in place. I'd like to have an option to 
trigger plugin/execution suppression from somewhere in the POM, not just via 
CLI option. This allows us to say, My build uses the jar packaging, but I 
never want the X plugin to run.

To me, this is important because it means we don't have to worry about users 
getting the right CLI options in place to run a build (or, more importantly, a 
release). In many cases, failing to use the suppressing CLI option may break 
the build, but in others it may lead to incorrect build results being released 
for public consumption. Also, in cases where it's important that users can 
rebuild the project from source (as in cases where ASF votes are taken), 
requiring a CLI option to produce a correct build adds a new layer of build 
complexity. It takes us away from the common vocabulary that makes Maven so 
effective, and back toward something more like Ant, where you have to know the 
correct incantation to produce a build.

I hope this patch is applied, but I think we need to spend a little more time 
focusing on how to codify these suppressions in the POM before releasing a 
Maven version with this patch in place.

 Skip plugin and/or execution
 

 Key: MNG-3321
 URL: http://jira.codehaus.org/browse/MNG-3321
 Project: Maven 2  3
  Issue Type: New Feature
  Components: Command Line
Affects Versions: 2.0.8
Reporter: Paul Gier
 Fix For: 3.1

 Attachments: MNG-3321-core-integration-testing.patch, 
 MNG-3321-maven-core.patch, MNG-3321-maven-core.patch


 Add ability to skip the execution of certain plugins.  From the command line 
 this could look something like:
 {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin 
 install {code}
 Also useful would be the ability to skip individual executions of a plugin.  
 For example, if the surefire plugin had two executions defined as ex1 and 
 ex2, you could do something like this:
 {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin:ex1 
 install {code}
 This would skip ex1 but still run ex2.

-- 
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: (MASSEMBLY-539) Link to Assembly Descriptor Schemas (XSD) for 1.1.2 is broken

[John Casey (JIRA)]

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

John Casey closed MASSEMBLY-539.


   Resolution: Fixed
Fix Version/s: 2.2
 Assignee: John Casey

looks like this was fixed in SVN by Dennis L. I just fixed a local workdir 
checkout of 2.2 and pushed that up to the site.

Also, this is what I get when I retrieve the 1.1.2 XSD:

{noformat}
betelgeuse:maven-plugins jdcasey$ curl -i 
http://maven.apache.org/xsd/assembly-1.1.2.xsd | head
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  1 651191  11630 0   5517  0  0:00:11 --:--:--  0:00:11  
5517HTTP/1.1 200 OK
Date: Wed, 12 Jan 2011 16:49:08 GMT
Server: Apache/2.3.8 (Unix) mod_ssl/2.3.8 OpenSSL/1.0.0a
Last-Modified: Wed, 10 Nov 2010 16:01:32 GMT
ETag: d83673-fe5f-494b4f88f2f00
Accept-Ranges: bytes
Content-Length: 65119

?xml version=1.0?
!-- === DO NOT EDIT THIS FILE  --
[...]
{noformat}

In other words, it doesn't seem to be sending any specific Content-Type header. 
Maybe that should be corrected, but it's not sending Content-Type: text/html 
for sure.

 Link to Assembly Descriptor Schemas (XSD) for 1.1.2 is broken
 -

 Key: MASSEMBLY-539
 URL: http://jira.codehaus.org/browse/MASSEMBLY-539
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Eric Lewis
Assignee: John Casey
Priority: Minor
 Fix For: 2.2


 At the bottom of http://maven.apache.org/plugins/maven-assembly-plugin/ there 
 are links to the XSD files.
 The one for 1.1.2 points to
 http://maven.apache.org/xsd/assembly-1.1.1.xsd
 but should point to
 http://maven.apache.org/xsd/assembly-1.1.2.xsd
 Also, http://maven.apache.org/xsd/assembly-1.1.2.xsd is delivered as MIME 
 type text/html instead of text/plain

-- 
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-4962) release:prepare with reactor BOM referenced from reactor parent POM results in child with unchanged parent version

[John Casey (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=250780#action_250780
 ] 

John Casey commented on MNG-4962:
-

Digging into this a bit further, it seems that 
DefaultModelBuilder.importDependencyManagement(..) is called twice when running 
release:prepare. The first time is as a result of the 
DefaultMaven.collectProjects(..) execution, where the complete list of project 
files is used to build up an effective reactor model cache. 

The second time is a result of MavenProject.getParent(), which uses the 
ProjectBuildingRequest stored in the MavenProject instance, and has no notion 
of other models available in the reactor. It seems like this is a special 
problem when it comes to loading import-scoped dependencies, since they have no 
relative path attached to them. With no relative path to use in reconstructing 
a reactor path, and no cached model for the BOM, parent POMs referencing BOMs 
in the same reactor will fail to build.

Another symptom of this problem is that the failure to build the parent 
MavenProject instance on-demand will be visible only in the great wash of 
output that is the debug log-level. In other words, it will not prevent the 
build from progressing, in spite of the fact that an explicit call has to be 
made requesting this information in order to trigger the failure...which IMO by 
default we should assume is critical to the build's progress. If this call is 
made and the parent-project construction fails, the caller should be given the 
opportunity to handle the exception.

 release:prepare with reactor BOM referenced from reactor parent POM results 
 in child with unchanged parent version
 --

 Key: MNG-4962
 URL: http://jira.codehaus.org/browse/MNG-4962
 Project: Maven 2  3
  Issue Type: Bug
  Components: Reactor and workspace
Affects Versions: 3.0, 3.0.1, 3.0.2
Reporter: John Casey
 Attachments: release-parent-adjustment.zip, test.git.zip


 I'm attaching a sample project that displays the behavior.
 Essentially, the project structure is a multimodule project with two levels 
 of parent POMs, not unlike the structure found in maven-scm or similar. There 
 is also a top-level submodule that is just a Bill-of-Materials POM, named - 
 'bom'. The second-level parent POM, named 'children' imports 'bom', and is 
 inherited by the 'child1' submodule.
 When release:prepare is run, the POMs are transformed on disk, it seems to 
 trigger a re-resolution of the 'child1' parent reference - the 
 MavenProject.getParent() call triggers the ProjectBuilder.build(...) to 
 retrieve the 'children' POM. When this happens, the process of building the 
 'children' POM results in trying to locate the 'bom' POM. HOWEVER, at this 
 point there is no reactor cache at all, much less one that contains the 
 proper coordinate for the transformed BOM. This means the 
 project-construction for 'children' fails, and the parent reference in the 
 'child1' MavenProject instance is null...which means the release plugin's 
 check of MavenProject.hasParent() returns false, and the parent/ reference 
 doesn't get updated.
 I haven't dug deeper than this, so I'm not sure how the reactor cache is 
 lost, or how it was ever preserved so that the MavenProject.getParent() call 
 could succeed under normal circumstances.
 I know that the parent/ update works in this scenario when using Maven 
 2.2.1, though I haven't done the debugging to know exactly why. I'm guessing 
 it's taking advantage of a higher-level cache within the MavenProjectBuilder 
 itself to avoid losing track of the parents. I also know that it eagerly 
 builds/resolves/associates parent MavenProject instances, so maybe that has 
 something to do with 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: (MNG-4962) release:prepare with reactor BOM referenced from reactor parent POM results in child with unchanged parent version

[John Casey (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=250782#action_250782
 ] 

John Casey commented on MNG-4962:
-

Thinking about this a little more, the root of this problem seems to be the 
change from 2.x - 3.x to stop creating hard references between a MavenProject 
and it's parent MavenProject instance. In 2.2.1, the getParent() method made 
sense, since we were materializing the whole project set before we 
started...the philosophy was geared around the CLI and not long-running 
processes. In 3.x, having MavenProject.getParent() doesn't make sense. In 3.x, 
it requires storing a reference to the ProjectBuilder, which isn't a model 
object, it's a component. Also, it separates the use of the ProjectBuilder from 
the larger build context, what we're calling the reactor. The list of other 
files available in the reactor - and the models, coordinates, etc. available 
from those files - is lost to this ProjectBuilder usage.

Maybe it'd be better to require callers to @Require their own reference to the 
ProjectBuilder and request the parent MavenProject instance through that, 
rather than allowing MavenProject.getParent(). Although, this currently shares 
some of the context issues, namely that the original reactor model cache seems 
to be discarded once the projects are constructed the first time by 
DefaultMaven.collectProjects()...

 release:prepare with reactor BOM referenced from reactor parent POM results 
 in child with unchanged parent version
 --

 Key: MNG-4962
 URL: http://jira.codehaus.org/browse/MNG-4962
 Project: Maven 2  3
  Issue Type: Bug
  Components: Reactor and workspace
Affects Versions: 3.0, 3.0.1, 3.0.2
Reporter: John Casey
 Attachments: release-parent-adjustment.zip, test.git.zip


 I'm attaching a sample project that displays the behavior.
 Essentially, the project structure is a multimodule project with two levels 
 of parent POMs, not unlike the structure found in maven-scm or similar. There 
 is also a top-level submodule that is just a Bill-of-Materials POM, named - 
 'bom'. The second-level parent POM, named 'children' imports 'bom', and is 
 inherited by the 'child1' submodule.
 When release:prepare is run, the POMs are transformed on disk, it seems to 
 trigger a re-resolution of the 'child1' parent reference - the 
 MavenProject.getParent() call triggers the ProjectBuilder.build(...) to 
 retrieve the 'children' POM. When this happens, the process of building the 
 'children' POM results in trying to locate the 'bom' POM. HOWEVER, at this 
 point there is no reactor cache at all, much less one that contains the 
 proper coordinate for the transformed BOM. This means the 
 project-construction for 'children' fails, and the parent reference in the 
 'child1' MavenProject instance is null...which means the release plugin's 
 check of MavenProject.hasParent() returns false, and the parent/ reference 
 doesn't get updated.
 I haven't dug deeper than this, so I'm not sure how the reactor cache is 
 lost, or how it was ever preserved so that the MavenProject.getParent() call 
 could succeed under normal circumstances.
 I know that the parent/ update works in this scenario when using Maven 
 2.2.1, though I haven't done the debugging to know exactly why. I'm guessing 
 it's taking advantage of a higher-level cache within the MavenProjectBuilder 
 itself to avoid losing track of the parents. I also know that it eagerly 
 builds/resolves/associates parent MavenProject instances, so maybe that has 
 something to do with 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: (MNG-4962) release:prepare with reactor BOM referenced from reactor parent POM results in child with unchanged parent version

[John Casey (JIRA)]

[ 
http://jira.codehaus.org/browse/MNG-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=250785#action_250785
 ] 

John Casey commented on MNG-4962:
-

It would be nice to have the option to specify a durable working memory of 
sorts for Maven, with the default for long-running callers being an on-demand 
cache instead. This might give workflow executions like release:prepare or any 
normal build the opportunity to track things like BOMs present and used in the 
same reactor, while still allowing non-workflow usages like m2eclipse to 
function without too much overhead or risk of staleness.

 release:prepare with reactor BOM referenced from reactor parent POM results 
 in child with unchanged parent version
 --

 Key: MNG-4962
 URL: http://jira.codehaus.org/browse/MNG-4962
 Project: Maven 2  3
  Issue Type: Bug
  Components: Reactor and workspace
Affects Versions: 3.0, 3.0.1, 3.0.2
Reporter: John Casey
 Attachments: release-parent-adjustment.zip, test.git.zip


 I'm attaching a sample project that displays the behavior.
 Essentially, the project structure is a multimodule project with two levels 
 of parent POMs, not unlike the structure found in maven-scm or similar. There 
 is also a top-level submodule that is just a Bill-of-Materials POM, named - 
 'bom'. The second-level parent POM, named 'children' imports 'bom', and is 
 inherited by the 'child1' submodule.
 When release:prepare is run, the POMs are transformed on disk, it seems to 
 trigger a re-resolution of the 'child1' parent reference - the 
 MavenProject.getParent() call triggers the ProjectBuilder.build(...) to 
 retrieve the 'children' POM. When this happens, the process of building the 
 'children' POM results in trying to locate the 'bom' POM. HOWEVER, at this 
 point there is no reactor cache at all, much less one that contains the 
 proper coordinate for the transformed BOM. This means the 
 project-construction for 'children' fails, and the parent reference in the 
 'child1' MavenProject instance is null...which means the release plugin's 
 check of MavenProject.hasParent() returns false, and the parent/ reference 
 doesn't get updated.
 I haven't dug deeper than this, so I'm not sure how the reactor cache is 
 lost, or how it was ever preserved so that the MavenProject.getParent() call 
 could succeed under normal circumstances.
 I know that the parent/ update works in this scenario when using Maven 
 2.2.1, though I haven't done the debugging to know exactly why. I'm guessing 
 it's taking advantage of a higher-level cache within the MavenProjectBuilder 
 itself to avoid losing track of the parents. I also know that it eagerly 
 builds/resolves/associates parent MavenProject instances, so maybe that has 
 something to do with 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] Created: (MNG-4962) release:prepare with reactor BOM referenced from reactor parent POM results in child with unchanged parent version

[John Casey (JIRA)]

release:prepare with reactor BOM referenced from reactor parent POM results in 
child with unchanged parent version
--

 Key: MNG-4962
 URL: http://jira.codehaus.org/browse/MNG-4962
 Project: Maven 2  3
  Issue Type: Bug
  Components: Reactor and workspace
Affects Versions: 3.0.1, 3.0, 3.0.2
Reporter: John Casey
 Attachments: release-parent-adjustment.zip, test.git.zip

I'm attaching a sample project that displays the behavior.

Essentially, the project structure is a multimodule project with two levels of 
parent POMs, not unlike the structure found in maven-scm or similar. There is 
also a top-level submodule that is just a Bill-of-Materials POM, named - 'bom'. 
The second-level parent POM, named 'children' imports 'bom', and is inherited 
by the 'child1' submodule.

When release:prepare is run, the POMs are transformed on disk, it seems to 
trigger a re-resolution of the 'child1' parent reference - the 
MavenProject.getParent() call triggers the ProjectBuilder.build(...) to 
retrieve the 'children' POM. When this happens, the process of building the 
'children' POM results in trying to locate the 'bom' POM. HOWEVER, at this 
point there is no reactor cache at all, much less one that contains the proper 
coordinate for the transformed BOM. This means the project-construction for 
'children' fails, and the parent reference in the 'child1' MavenProject 
instance is null...which means the release plugin's check of 
MavenProject.hasParent() returns false, and the parent/ reference doesn't get 
updated.

I haven't dug deeper than this, so I'm not sure how the reactor cache is lost, 
or how it was ever preserved so that the MavenProject.getParent() call could 
succeed under normal circumstances.

I know that the parent/ update works in this scenario when using Maven 2.2.1, 
though I haven't done the debugging to know exactly why. I'm guessing it's 
taking advantage of a higher-level cache within the MavenProjectBuilder itself 
to avoid losing track of the parents. I also know that it eagerly 
builds/resolves/associates parent MavenProject instances, so maybe that has 
something to do with 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