date:20121107


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

Dennis Lundberg updated MASSEMBLY-636:
--

Component/s: permissions

 Directory permissions still not correct for dirs created by dependencySet
 -

 Key: MASSEMBLY-636
 URL: https://jira.codehaus.org/browse/MASSEMBLY-636
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
  Components: dependencySet, permissions
Affects Versions: 2.3
Reporter: Jason Dillon
Priority: Critical

 While 2.3 did fix some of the permission problems, it still seems to have 
 issues creating proper permissions in zip files for directories created by 
 dependencySet, even with directoryMode configured.
 I've setup a branch of nexus 'm-assembly-p-2.3-still-broke' which configures 
 version 2.3 of the m-assembly-p:
 https://github.com/sonatype/nexus/tree/m-assembly-p-2.3-still-broke
 {noformat}
 mvn clean install -Dtest=skip
 unzip -d target 
 nexus/nexus-oss-webapp/target/nexus-oss-webapp-2.3-SNAPSHOT-bundle.zip
 find target/nexus-oss-webapp-2.3-SNAPSHOT -ls | grep rwxrwx
 {noformat}
 Shows that the lib and nexus directories are 777:
 {noformat}
 1574536150 drwxrwxrwx   23 jasonstaff 782 
 Nov  2 16:42 target/nexus-oss-webapp-2.3-SNAPSHOT/lib
 1574528520 drwxrwxrwx   12 jasonstaff 408 
 Nov  2 16:42 target/nexus-oss-webapp-2.3-SNAPSHOT/nexus
 {noformat}
 Both of these directories are created by a dependencySet with directoryMode 
 set to 0755.
 The last version of the m-assembly-p which actually functions correct for 
 perms/assembly configuration is 2.2-beta-3.

--
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] (MASSEMBLY-449) Permissions on directories in a zipped archive incorrect


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

Dennis Lundberg closed MASSEMBLY-449.
-

   Resolution: Fixed
Fix Version/s: 2.4

 Permissions on directories in a zipped archive incorrect
 

 Key: MASSEMBLY-449
 URL: https://jira.codehaus.org/browse/MASSEMBLY-449
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
  Components: permissions
Affects Versions: 2.2-beta-4
Reporter: James Kavanagh
 Fix For: 2.4


 Using the following assembly plugin:
 {code:xml}
 assembly
 idtarget-packaged/id
 formats
 formatzip/format
 /formats
 includeBaseDirectoryfalse/includeBaseDirectory
 moduleSets
 moduleSet
 includes
 include*:core-env/include
 /includes
 binaries
 attachmentClassifierenv/attachmentClassifier
 includeDependenciesfalse/includeDependencies
 unpacktrue/unpack
 /binaries
 /moduleSet
 moduleSet
 includes
 include*:data-bridge/include
 /includes
 binaries
 attachmentClassifiertarget/attachmentClassifier
 includeDependenciesfalse/includeDependencies
 unpacktrue/unpack
 /binaries
 /moduleSet
 moduleSet
 includes
 include*:web/include
 /includes
 binaries
 attachmentClassifierweb/attachmentClassifier
 includeDependenciesfalse/includeDependencies
 unpacktrue/unpack
 /binaries
 /moduleSet
 /moduleSets
 /assembly
 {code}
 When unzipping the result on a Linux host all the directory permissions have 
 been set to 777.
 If I revert the plugin version to 2.2-beta-3 the issue goes away.

--
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] (MASSEMBLY-460) default file mode of 7777 leads to trouble


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

Dennis Lundberg commented on MASSEMBLY-460:
---

I'm trying to reproduce this, but I don't have enought to go on. Can you please 
supply the assembly descriptor you are using and the plugin configuration?

 default file mode of  leads to trouble 
 ---

 Key: MASSEMBLY-460
 URL: https://jira.codehaus.org/browse/MASSEMBLY-460
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
  Components: permissions
Affects Versions: 2.2-beta-4
Reporter: Benson Margulies

 We are getting build failures as follows. 1: why  and not 0777? Why a 
 WARNING if the build is going to quit? Why quit?
 {noformat}
 [WARNING] Standard output:
 [WARNING] ---
 [WARNING] chmod: changing permissions of 
 `/basis/users/skearns/svn/trunk_mirror/greenhouse/jester/distribution/target/jester-all.dir/jester/release_package'
  (requested: , actual: 6777): Operation not permitted
 [WARNING] ---
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Failed to create assembly: Error creating assembly archive all: chmod 
 exit code was: 1
 {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] (MASSEMBLY-621) directoryMode not enforced


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

Dennis Lundberg closed MASSEMBLY-621.
-

   Resolution: Fixed
Fix Version/s: 2.4

 directoryMode not enforced
 --

 Key: MASSEMBLY-621
 URL: https://jira.codehaus.org/browse/MASSEMBLY-621
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
  Components: permissions
Affects Versions: 2.2.1
 Environment: Linux x86_64 Fedora 17
Reporter: Asif Akhtar
 Fix For: 2.4


 Maven assembly plugin does not enforce directoryMode when specified for the 
 outputdirectory.
 For example:
 {code}
 fileSet
 directorysrc/main/conf/directory
 fileMode0644/fileMode
 directoryMode0755/directoryMode
 outputDirectoryconf/outputDirectory
 /fileSet
 {code}
 The directories still appear as 775.
 {code}
 drwxrwxr-x
 {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] (MASSEMBLY-636) Directory permissions still not correct for dirs created by dependencySet


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

Dennis Lundberg commented on MASSEMBLY-636:
---

Can you please try with the latest 2.4-SNAPSHOT version? I think that it has 
solved this issue.

 Directory permissions still not correct for dirs created by dependencySet
 -

 Key: MASSEMBLY-636
 URL: https://jira.codehaus.org/browse/MASSEMBLY-636
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
  Components: dependencySet, permissions
Affects Versions: 2.3
Reporter: Jason Dillon
Priority: Critical

 While 2.3 did fix some of the permission problems, it still seems to have 
 issues creating proper permissions in zip files for directories created by 
 dependencySet, even with directoryMode configured.
 I've setup a branch of nexus 'm-assembly-p-2.3-still-broke' which configures 
 version 2.3 of the m-assembly-p:
 https://github.com/sonatype/nexus/tree/m-assembly-p-2.3-still-broke
 {noformat}
 mvn clean install -Dtest=skip
 unzip -d target 
 nexus/nexus-oss-webapp/target/nexus-oss-webapp-2.3-SNAPSHOT-bundle.zip
 find target/nexus-oss-webapp-2.3-SNAPSHOT -ls | grep rwxrwx
 {noformat}
 Shows that the lib and nexus directories are 777:
 {noformat}
 1574536150 drwxrwxrwx   23 jasonstaff 782 
 Nov  2 16:42 target/nexus-oss-webapp-2.3-SNAPSHOT/lib
 1574528520 drwxrwxrwx   12 jasonstaff 408 
 Nov  2 16:42 target/nexus-oss-webapp-2.3-SNAPSHOT/nexus
 {noformat}
 Both of these directories are created by a dependencySet with directoryMode 
 set to 0755.
 The last version of the m-assembly-p which actually functions correct for 
 perms/assembly configuration is 2.2-beta-3.

--
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] (MASSEMBLY-460) default file mode of 7777 leads to trouble

2012-11-07 Thread Benson Margulies (JIRA)


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

Benson Margulies closed MASSEMBLY-460.
--

Resolution: Cannot Reproduce
  Assignee: Benson Margulies

I reported this a very long time ago, and I've long ago lost the thread. So I', 
closing it.


 default file mode of  leads to trouble 
 ---

 Key: MASSEMBLY-460
 URL: https://jira.codehaus.org/browse/MASSEMBLY-460
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
  Components: permissions
Affects Versions: 2.2-beta-4
Reporter: Benson Margulies
Assignee: Benson Margulies

 We are getting build failures as follows. 1: why  and not 0777? Why a 
 WARNING if the build is going to quit? Why quit?
 {noformat}
 [WARNING] Standard output:
 [WARNING] ---
 [WARNING] chmod: changing permissions of 
 `/basis/users/skearns/svn/trunk_mirror/greenhouse/jester/distribution/target/jester-all.dir/jester/release_package'
  (requested: , actual: 6777): Operation not permitted
 [WARNING] ---
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Failed to create assembly: Error creating assembly archive all: chmod 
 exit code was: 1
 {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-922) missing org/apache/maven/plugin/surefire/report/plexus/util/xml/XmlStreamReader

2012-11-07 Thread Christopher Mosher (JIRA)


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

Christopher Mosher commented on SUREFIRE-922:
-

Good idea. However, the problem had gone away now. Maybe, as you suggested, 
there we some cross-version problem that got resolved during our next build. 
Thanks.

 missing 
 org/apache/maven/plugin/surefire/report/plexus/util/xml/XmlStreamReader
 ---

 Key: SUREFIRE-922
 URL: https://jira.codehaus.org/browse/SUREFIRE-922
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Failsafe Plugin
 Environment: linux, mvn, failsafe (parallel execution threads)
Reporter: Christopher Mosher

 We are using the 2.13-SNAPSHOT of surefire, and we just started getting this 
 error (as of about Nov 5 2012 15:00 EST):
 message : Failed to execute goal 
 org.apache.maven.plugins:maven-failsafe-plugin:2.13-SNAPSHOT:verify (verify) 
 on project databaseUtil: Execution verify of goal 
 org.apache.maven.plugins:maven-failsafe-plugin:2.13-SNAPSHOT:verify failed: A 
 required class was missing while executing 
 org.apache.maven.plugins:maven-failsafe-plugin:2.13-SNAPSHOT:verify: 
 org/apache/maven/plugin/surefire/report/plexus/util/xml/XmlStreamReader

--
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-922) missing org/apache/maven/plugin/surefire/report/plexus/util/xml/XmlStreamReader

2012-11-07 Thread Christopher Mosher (JIRA)


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

Christopher Mosher closed SUREFIRE-922.
---

Resolution: Cannot Reproduce

 missing 
 org/apache/maven/plugin/surefire/report/plexus/util/xml/XmlStreamReader
 ---

 Key: SUREFIRE-922
 URL: https://jira.codehaus.org/browse/SUREFIRE-922
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Failsafe Plugin
 Environment: linux, mvn, failsafe (parallel execution threads)
Reporter: Christopher Mosher

 We are using the 2.13-SNAPSHOT of surefire, and we just started getting this 
 error (as of about Nov 5 2012 15:00 EST):
 message : Failed to execute goal 
 org.apache.maven.plugins:maven-failsafe-plugin:2.13-SNAPSHOT:verify (verify) 
 on project databaseUtil: Execution verify of goal 
 org.apache.maven.plugins:maven-failsafe-plugin:2.13-SNAPSHOT:verify failed: A 
 required class was missing while executing 
 org.apache.maven.plugins:maven-failsafe-plugin:2.13-SNAPSHOT:verify: 
 org/apache/maven/plugin/surefire/report/plexus/util/xml/XmlStreamReader

--
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-922) missing org/apache/maven/plugin/surefire/report/plexus/util/xml/XmlStreamReader

2012-11-07 Thread Christopher Mosher (JIRA)

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

Christopher Mosher edited comment on SUREFIRE-922 at 11/7/12 10:02 AM:
---

Good idea. However, the problem has gone away now. Maybe, as you suggested,
there we some cross-version problem that got resolved during our next build.
Thanks.

was (Author: cmosher01):
Good idea. However, the problem had gone away now. Maybe, as you suggested,
there we some cross-version problem that got resolved during our next build.
Thanks.

missing
org/apache/maven/plugin/surefire/report/plexus/util/xml/XmlStreamReader
---

Key: SUREFIRE-922
URL: https://jira.codehaus.org/browse/SUREFIRE-922
Project: Maven Surefire
Issue Type: Bug
Components: Maven Failsafe Plugin
Environment: linux, mvn, failsafe (parallel execution threads)
Reporter: Christopher Mosher

We are using the 2.13-SNAPSHOT of surefire, and we just started getting this
error (as of about Nov 5 2012 15:00 EST):
message : Failed to execute goal
org.apache.maven.plugins:maven-failsafe-plugin:2.13-SNAPSHOT:verify (verify)
on project databaseUtil: Execution verify of goal
org.apache.maven.plugins:maven-failsafe-plugin:2.13-SNAPSHOT:verify failed: A
required class was missing while executing
org.apache.maven.plugins:maven-failsafe-plugin:2.13-SNAPSHOT:verify:
org/apache/maven/plugin/surefire/report/plexus/util/xml/XmlStreamReader

--
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] (MEAR-161) Accept custom EarModule implementations

2012-11-07 Thread Harvey Raja (JIRA)

Harvey Raja created MEAR-161:


 Summary: Accept custom EarModule implementations
 Key: MEAR-161
 URL: https://jira.codehaus.org/browse/MEAR-161
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Reporter: Harvey Raja


It would be great if the plugin allowed users to specify custom EarModule, i.e. 
a Map configuration parameter with key being module type and value being the 
EarModule class implementation. This would allow any module types not specified 
in the jee spec to be supported by the plugin by vendors providing their own 
implementations. Additionally this could result in the generation of a 
container specific descriptor file.

--
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-3229) Active by default profile is ignored when another is specified explicitly.


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

Ronald Chen commented on MNG-3229:
--

Not a bug.  As intended.  activeByDefault is ONLY used when no -P are used

 Active by default  profile is ignored when another is specified explicitly.
 ---

 Key: MNG-3229
 URL: https://jira.codehaus.org/browse/MNG-3229
 Project: Maven 2  3
  Issue Type: Bug
  Components: Profiles
Affects Versions: 2.0.7
Reporter: Oleksandr Maksymchuk
 Fix For: Documentation Deficit


 When default profile is added its used only when there is no another profile 
 specified to be used on command line via -P option.
 So in the pom containig:
   profile
   iddefault/id
   activation
   activeByDefaulttrue/activeByDefault
   /activation
   profile
   iddev/id
   !-- Not active, should be called explicitly. --
 default profile is used only when running command without -P dev
 mvn 
 but not used when running:
 mvn -P dev
 Expected: should be used in both variants as per doc.

--
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-923) Scanning for junit4.8 when using groups/excludedGroups does not consider transitive dependencies

2012-11-07 Thread James Shaw (JIRA)

James Shaw created SUREFIRE-923:
---

 Summary: Scanning for junit4.8 when using groups/excludedGroups 
does not consider transitive dependencies
 Key: SUREFIRE-923
 URL: https://jira.codehaus.org/browse/SUREFIRE-923
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.12.4
Reporter: James Shaw


I've had to include junit explicitly in my pom to get groups/excludedGroups to 
work.  If it's included through a transitive dependency I get the error:
{code}
groups/excludedGroups require TestNG or JUunit48+ on project test classpath
{code}

Also, note the typo in JUunit48+ ;)

--
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-910) Surefire 2.12.1 fails with The forked VM terminated without saying properly goodbye

2012-11-07 Thread Kristian Rosenvold (JIRA)


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

Kristian Rosenvold commented on SUREFIRE-910:
-

I just added a faq entry about this issue, explaining what the situation is; 
the entry will appear in the faq once the site gets published, but can be seen 
here:

https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commitdiff;h=0e900e3196f77d5b26b951731fc6ee1f28c2effd;hp=ec09dc90ed989a24f934bcd8b80713483a23bfc7

The morale here is that there's little hope in waiting for us to fix this, 
since there are no known cases when this issue happens within surefire itself. 
Unless the source of the issue is some resource leak from within surefire 
itself, this most likely some kind of leak within your code/libraries.

Now there may be some failure conditions we should be picking up (dumped 
messages coming to the console), so I'm keeping this issue open a little 
longer; but basically this is a cannot reproduce. 



 Surefire 2.12.1 fails with The forked VM terminated without saying properly 
 goodbye
 -

 Key: SUREFIRE-910
 URL: https://jira.codehaus.org/browse/SUREFIRE-910
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Reporter: Ilya Katsov

 Build fails with The forked VM terminated without saying properly goodbye 
 message with no information about the source of the problem:
 {code}
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.125 sec
 Running org.apache.hadoop.fs.viewfs.TestViewFsHdfs
 Tests run: 42, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 14.149 sec
 Running org.apache.hadoop.fs.TestFcHdfsSymlink
 Tests run: 67, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 20.792 sec
 Results :
 Tests run: 1033, Failures: 0, Errors: 0, Skipped: 1
 [INFO]
  
 [INFO] 
 
 [INFO] Skipping Apache Hadoop HDFS Project
 [INFO] This project has been banned from the build due to previous failures.
 [INFO] 
 
 [INFO]
  
 [INFO] 
 
 [INFO] Skipping Apache Hadoop HDFS
 [INFO] This project has been banned from the build due to previous failures.
 [INFO] 
 
 [INFO] 
 
 [INFO] Reactor Summary:
 [INFO] 
 [INFO] Apache Hadoop HDFS  FAILURE 
 [1:06:10.415s]
 [INFO] Apache Hadoop HttpFS .. SKIPPED
 [INFO] Apache Hadoop HDFS Project  SKIPPED
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 [INFO] Total time: 1:06:11.188s
 [INFO] Finished at: Wed Sep 05 12:01:46 MSK 2012
 [INFO] Final Memory: 24M/394M
 [INFO] 
 
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.12.1:test (default-test) on 
 project hadoop-hdfs: ExecutionException; nested exception is 
 java.util.concurrent.ExecutionException: java.lang.RuntimeException: The 
 forked VM terminated without saying properly goodbye. VM crash or System.exit 
 called ? - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-surefire-plugin:2.12.1:test 
 (default-test) on project hadoop-hdfs: ExecutionException; nested exception 
 is java.util.concurrent.ExecutionException: java.lang.RuntimeException: The 
 forked VM terminated without saying properly goodbye. VM crash or System.exit 
 called ?
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
   at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
   at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
   at

[jira] (SUREFIRE-923) Scanning for junit4.8 when using groups/excludedGroups does not consider transitive dependencies

2012-11-07 Thread Kristian Rosenvold (JIRA)


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

Kristian Rosenvold commented on SUREFIRE-923:
-

Typo fixed in fa8038c454d5821e025d9d5b9726897c3bbfb61e ;)

 Scanning for junit4.8 when using groups/excludedGroups does not consider 
 transitive dependencies
 

 Key: SUREFIRE-923
 URL: https://jira.codehaus.org/browse/SUREFIRE-923
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.12.4
Reporter: James Shaw

 I've had to include junit explicitly in my pom to get groups/excludedGroups 
 to work.  If it's included through a transitive dependency I get the error:
 {code}
 groups/excludedGroups require TestNG or JUunit48+ on project test classpath
 {code}
 Also, note the typo in JUunit48+ ;)

--
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] (MASSEMBLY-636) Directory permissions still not correct for dirs created by dependencySet

2012-11-07 Thread Jason Dillon (JIRA)


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

Jason Dillon commented on MASSEMBLY-636:


Just tried 2.4-SNAPSHOT and it does appear to resolve this problem.  Hopefully 
it stays fixed :-)

 Directory permissions still not correct for dirs created by dependencySet
 -

 Key: MASSEMBLY-636
 URL: https://jira.codehaus.org/browse/MASSEMBLY-636
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
  Components: dependencySet, permissions
Affects Versions: 2.3
Reporter: Jason Dillon
Priority: Critical

 While 2.3 did fix some of the permission problems, it still seems to have 
 issues creating proper permissions in zip files for directories created by 
 dependencySet, even with directoryMode configured.
 I've setup a branch of nexus 'm-assembly-p-2.3-still-broke' which configures 
 version 2.3 of the m-assembly-p:
 https://github.com/sonatype/nexus/tree/m-assembly-p-2.3-still-broke
 {noformat}
 mvn clean install -Dtest=skip
 unzip -d target 
 nexus/nexus-oss-webapp/target/nexus-oss-webapp-2.3-SNAPSHOT-bundle.zip
 find target/nexus-oss-webapp-2.3-SNAPSHOT -ls | grep rwxrwx
 {noformat}
 Shows that the lib and nexus directories are 777:
 {noformat}
 1574536150 drwxrwxrwx   23 jasonstaff 782 
 Nov  2 16:42 target/nexus-oss-webapp-2.3-SNAPSHOT/lib
 1574528520 drwxrwxrwx   12 jasonstaff 408 
 Nov  2 16:42 target/nexus-oss-webapp-2.3-SNAPSHOT/nexus
 {noformat}
 Both of these directories are created by a dependencySet with directoryMode 
 set to 0755.
 The last version of the m-assembly-p which actually functions correct for 
 perms/assembly configuration is 2.2-beta-3.

--
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-5369) Inconsistent interaction between activeProfiles and activeByDefault

Ronald Chen created MNG-5369:


 Summary: Inconsistent interaction between activeProfiles and 
activeByDefault
 Key: MNG-5369
 URL: https://jira.codehaus.org/browse/MNG-5369
 Project: Maven 2  3
  Issue Type: Bug
  Components: Profiles, Settings
Affects Versions: 3.0.4
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
Maven home: /home/rchen/dev/tools/apache-maven-3.0.4
Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
Java home: /home/rchen/dev/tools/jdk1.6.0_26/jre
Default locale: en_CA, platform encoding: UTF-8
OS name: linux, version: 2.6.36-020636-generic, arch: amd64, family: 
unix

Reporter: Ronald Chen
 Attachments: maven-active-by-default-parent.tar.gz, 
maven-profiles-bug.png

I have two profiles.  One is activated by activeProfiles in settings.xml and 
the other is activeByDefault = true

They are both expected to be active as I am not using -P in my commands.

The bug is there are some cases in which the activeByDefault profile is not 
active.

It seems like whenever both profiles are located in the same pom, the 
activeByDefault profile is no longer active.  But moving the activeProfiles 
profile up into a parent pom or moving the activeByDefault profile down to a 
module both seems to work.

Its a rather complicated to describe, so I have attached 6 sample projects 
which illustrates various scenarios.  I've summarized the results in the 
attached image.

You can also run all the projects with the command:
ls -1 | xargs --verbose -I CASE mvn -f CASE/sub-parent/project/pom.xml validate 
-s CASE/settings.xml |grep -vP '^\[INFO\]'



--
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-5369) Inconsistent interaction between activeProfiles and activeByDefault


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

Ronald Chen commented on MNG-5369:
--

Sorry I left out one thing.  For all 6 projects given the command mvn validate 
-s settings.xml -f sub-parent/project/pom.xml I expect to see the following 
output:
main:
 [echo] 
 [echo] # activated-profile-from-settings-xml #
 [echo] 

main:
 [echo] 
 [echo] # activated-by-default #
 [echo] 


 Inconsistent interaction between activeProfiles and activeByDefault
 ---

 Key: MNG-5369
 URL: https://jira.codehaus.org/browse/MNG-5369
 Project: Maven 2  3
  Issue Type: Bug
  Components: Profiles, Settings
Affects Versions: 3.0.4
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
 Maven home: /home/rchen/dev/tools/apache-maven-3.0.4
 Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
 Java home: /home/rchen/dev/tools/jdk1.6.0_26/jre
 Default locale: en_CA, platform encoding: UTF-8
 OS name: linux, version: 2.6.36-020636-generic, arch: amd64, family: 
 unix
Reporter: Ronald Chen
 Attachments: maven-active-by-default-parent.tar.gz, 
 maven-profiles-bug.png


 I have two profiles.  One is activated by activeProfiles in settings.xml and 
 the other is activeByDefault = true
 They are both expected to be active as I am not using -P in my commands.
 The bug is there are some cases in which the activeByDefault profile is not 
 active.
 It seems like whenever both profiles are located in the same pom, the 
 activeByDefault profile is no longer active.  But moving the activeProfiles 
 profile up into a parent pom or moving the activeByDefault profile down to a 
 module both seems to work.
 Its a rather complicated to describe, so I have attached 6 sample projects 
 which illustrates various scenarios.  I've summarized the results in the 
 attached image.
 You can also run all the projects with the command:
 ls -1 | xargs --verbose -I CASE mvn -f CASE/sub-parent/project/pom.xml 
 validate -s CASE/settings.xml |grep -vP '^\[INFO\]'

--
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-5369) Inconsistent interaction between activeProfiles and activeByDefault


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

Ronald Chen edited comment on MNG-5369 at 11/7/12 3:53 PM:
---

Sorry I left out one thing.  For all 6 projects given the command mvn validate 
-s settings.xml -f sub-parent/project/pom.xml I expect to see the following 
output:
[INFO] Scanning for projects...
[INFO] 
[INFO] 
[INFO] Building project 1-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run (ant-echo-1) @ project ---
[INFO] Executing tasks

main:
 [echo] 
 [echo] # activated-profile-from-settings-xml #
 [echo] 
[INFO] Executed tasks
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run (ant-echo-2) @ project ---
[INFO] Executing tasks

main:
 [echo] 
 [echo] # activated-by-default #
 [echo] 
[INFO] Executed tasks
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 0.984s
[INFO] Finished at: Wed Nov 07 13:53:30 PST 2012
[INFO] Final Memory: 3M/117M
[INFO] 


  was (Author: pyrolistical):
Sorry I left out one thing.  For all 6 projects given the command mvn 
validate -s settings.xml -f sub-parent/project/pom.xml I expect to see the 
following output:
...
main:
 [echo] 
 [echo] # activated-profile-from-settings-xml #
 [echo] 
...
main:
 [echo] 
 [echo] # activated-by-default #
 [echo] 
...
  
 Inconsistent interaction between activeProfiles and activeByDefault
 ---

 Key: MNG-5369
 URL: https://jira.codehaus.org/browse/MNG-5369
 Project: Maven 2  3
  Issue Type: Bug
  Components: Profiles, Settings
Affects Versions: 3.0.4
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
 Maven home: /home/rchen/dev/tools/apache-maven-3.0.4
 Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
 Java home: /home/rchen/dev/tools/jdk1.6.0_26/jre
 Default locale: en_CA, platform encoding: UTF-8
 OS name: linux, version: 2.6.36-020636-generic, arch: amd64, family: 
 unix
Reporter: Ronald Chen
 Attachments: maven-active-by-default-parent.tar.gz, 
 maven-profiles-bug.png


 I have two profiles.  One is activated by activeProfiles in settings.xml and 
 the other is activeByDefault = true
 They are both expected to be active as I am not using -P in my commands.
 The bug is there are some cases in which the activeByDefault profile is not 
 active.
 It seems like whenever both profiles are located in the same pom, the 
 activeByDefault profile is no longer active.  But moving the activeProfiles 
 profile up into a parent pom or moving the activeByDefault profile down to a 
 module both seems to work.
 Its a rather complicated to describe, so I have attached 6 sample projects 
 which illustrates various scenarios.  I've summarized the results in the 
 attached image.
 You can also run all the projects with the command:
 ls -1 | xargs --verbose -I CASE mvn -f CASE/sub-parent/project/pom.xml 
 validate -s CASE/settings.xml |grep -vP '^\[INFO\]'

--
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-5369) Inconsistent interaction between activeProfiles and activeByDefault


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

Ronald Chen edited comment on MNG-5369 at 11/7/12 3:53 PM:
---

Sorry I left out one thing.  For all 6 projects given the command mvn validate 
-s settings.xml -f sub-parent/project/pom.xml I expect to see the following 
output:
...
main:
 [echo] 
 [echo] # activated-profile-from-settings-xml #
 [echo] 
...
main:
 [echo] 
 [echo] # activated-by-default #
 [echo] 
...

  was (Author: pyrolistical):
Sorry I left out one thing.  For all 6 projects given the command mvn 
validate -s settings.xml -f sub-parent/project/pom.xml I expect to see the 
following output:
main:
 [echo] 
 [echo] # activated-profile-from-settings-xml #
 [echo] 

main:
 [echo] 
 [echo] # activated-by-default #
 [echo] 

  
 Inconsistent interaction between activeProfiles and activeByDefault
 ---

 Key: MNG-5369
 URL: https://jira.codehaus.org/browse/MNG-5369
 Project: Maven 2  3
  Issue Type: Bug
  Components: Profiles, Settings
Affects Versions: 3.0.4
 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
 Maven home: /home/rchen/dev/tools/apache-maven-3.0.4
 Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
 Java home: /home/rchen/dev/tools/jdk1.6.0_26/jre
 Default locale: en_CA, platform encoding: UTF-8
 OS name: linux, version: 2.6.36-020636-generic, arch: amd64, family: 
 unix
Reporter: Ronald Chen
 Attachments: maven-active-by-default-parent.tar.gz, 
 maven-profiles-bug.png


 I have two profiles.  One is activated by activeProfiles in settings.xml and 
 the other is activeByDefault = true
 They are both expected to be active as I am not using -P in my commands.
 The bug is there are some cases in which the activeByDefault profile is not 
 active.
 It seems like whenever both profiles are located in the same pom, the 
 activeByDefault profile is no longer active.  But moving the activeProfiles 
 profile up into a parent pom or moving the activeByDefault profile down to a 
 module both seems to work.
 Its a rather complicated to describe, so I have attached 6 sample projects 
 which illustrates various scenarios.  I've summarized the results in the 
 attached image.
 You can also run all the projects with the command:
 ls -1 | xargs --verbose -I CASE mvn -f CASE/sub-parent/project/pom.xml 
 validate -s CASE/settings.xml |grep -vP '^\[INFO\]'

--
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-5369) Inconsistent interaction between activeProfiles and activeByDefault

2012-11-07 Thread JIRA

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

Jörg Schaible commented on MNG-5369:

Sorry, but you simply did not understand, how profiles work. Maven is
absolutely right how it behaves. You cannot inherit active profiles from a
parent, every profile activation is considered on its own in the scope of the
currently processed POM. Your matrix is simply a proof, that Maven works fine.

Inconsistent interaction between activeProfiles and activeByDefault
---

Key: MNG-5369
URL: https://jira.codehaus.org/browse/MNG-5369
Project: Maven 2 3
Issue Type: Bug
Components: Profiles, Settings
Affects Versions: 3.0.4
Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
Maven home: /home/rchen/dev/tools/apache-maven-3.0.4
Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
Java home: /home/rchen/dev/tools/jdk1.6.0_26/jre
Default locale: en_CA, platform encoding: UTF-8
OS name: linux, version: 2.6.36-020636-generic, arch: amd64, family:
unix
Reporter: Ronald Chen
Attachments: maven-active-by-default-parent.tar.gz,
maven-profiles-bug.png

I have two profiles. One is activated by activeProfiles in settings.xml and
the other is activeByDefault = true
They are both expected to be active as I am not using -P in my commands.
The bug is there are some cases in which the activeByDefault profile is not
active.
It seems like whenever both profiles are located in the same pom, the
activeByDefault profile is no longer active. But moving the activeProfiles
profile up into a parent pom or moving the activeByDefault profile down to a
module both seems to work.
Its a rather complicated to describe, so I have attached 6 sample projects
which illustrates various scenarios. I've summarized the results in the
attached image.
You can also run all the projects with the command:
ls -1 | xargs --verbose -I CASE mvn -f CASE/sub-parent/project/pom.xml
validate -s CASE/settings.xml |grep -vP '^\[INFO\]'

[jira] (MNG-5369) Inconsistent interaction between activeProfiles and activeByDefault

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

Ronald Chen commented on MNG-5369:
--

Jörg if what you say is true, every case in my matrix should have failed.

The fact that some cases did work is the inconsistency. Consistency can be
fixed by flipping the success condition and make all those cases fail.

Inconsistent interaction between activeProfiles and activeByDefault
---

[jira] (MCHECKSTYLE-99) includeTestSourceDirectory should use default test sources xref output dir: ${project.reporting.outputDirectory}/xref-test

2012-11-07 Thread Andrew Brock (JIRA)


[ 
https://jira.codehaus.org/browse/MCHECKSTYLE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=313060#comment-313060
 ] 

Andrew Brock commented on MCHECKSTYLE-99:
-

This is happening for me too - it's not just Linux
Windows 7, Maven 3.0.4, Checkstyle plugin version 2.9.1
Agree with Dan's suggestion as a logical fix.

 includeTestSourceDirectory should use default test sources xref output dir: 
 ${project.reporting.outputDirectory}/xref-test
 

 Key: MCHECKSTYLE-99
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-99
 Project: Maven 2.x Checkstyle Plugin
  Issue Type: Bug
Affects Versions: 2.2
 Environment: Linux (but I assume it happens in all environs)
Reporter: Dan Rollo
 Attachments: pom.xml


 The xref link to the Source pages in the checkstyle report page is
 broken. The source xref link for Unit Test Source files is not using the
 default value of the destDir for jxr test sources. From the jxr plugin docs
 for jxr:test-jxr:
 destDir
 Folder where the Xref files will be copied to.
 * Type: java.lang.String
 * Required: No
 * Expression: ${project.reporting.outputDirectory}/xref-test
 I think the checkstyle plugin should:
 - assume the default dir for jxr:test-jxr
 - provide it's own additional override setting (similar to xrefLocation,
 but for test sources). like: testXrefLocation.
 A pom file exhibiting this problem is attached.
 Dan Rollo

--
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] (MPLUGIN-227) HelpMojo javadoc generated in unnamed package


[ 
https://jira.codehaus.org/browse/MPLUGIN-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=313070#comment-313070
 ] 

Herve Boutemy commented on MPLUGIN-227:
---

hardened code in [r1406480|http://svn.apache.org/viewvc?rev=1406480view=rev], 
[r1406554|http://svn.apache.org/viewvc?rev=1406554view=rev] and 
[r1406615|http://svn.apache.org/viewvc?rev=1406615view=rev]

 HelpMojo javadoc generated in unnamed package
 ---

 Key: MPLUGIN-227
 URL: https://jira.codehaus.org/browse/MPLUGIN-227
 Project: Maven 2.x Plugin Tools
  Issue Type: Bug
Affects Versions: 3.0, 3.1
Reporter: Herve Boutemy
Assignee: Herve Boutemy
 Fix For: 3.2


 see 
 http://maven.apache.org/plugins/maven-javadoc-plugin-2.9/apidocs/package-summary.html
  or 
 http://maven.apache.org/plugins/maven-ear-plugin/apidocs/package-summary.html

--
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-924) generate every Surefire artifact site in /surefire and redirect previous /plugins/maven-(surefire|failsafe|surefire-report)-plugin

Herve Boutemy created SUREFIRE-924:
--

 Summary: generate every Surefire artifact site in /surefire and 
redirect previous /plugins/maven-(surefire|failsafe|surefire-report)-plugin
 Key: SUREFIRE-924
 URL: https://jira.codehaus.org/browse/SUREFIRE-924
 Project: Maven Surefire
  Issue Type: Task
Reporter: Herve Boutemy


Surefire generates site content dispatched in misc locations:
- /surefire
- /plugins/maven-surefire-plugin
- /plugins/maven-failsafe-plugin
- /plugins/maven-surefire-report-plugin

This will cause problems when we switch to svnpubsub+maven-scm-publish-plugin 
because this won't represent one unique svn commit

the build should deploy everything in /surefire and the site redirect from 
/plugins/surefure plugins locations to /surefire/*

--
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-924) generate every Surefire artifact site in /surefire and redirect previous /plugins/maven-(surefire|failsafe|surefire-report)-plugin


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

Herve Boutemy updated SUREFIRE-924:
---

  Component/s: Maven Surefire Report Plugin
   Maven Surefire Plugin
   Maven Failsafe Plugin
   documentation
Affects Version/s: 2.12.4
Fix Version/s: 2.13
 Assignee: Herve Boutemy

 generate every Surefire artifact site in /surefire and redirect previous 
 /plugins/maven-(surefire|failsafe|surefire-report)-plugin
 --

 Key: SUREFIRE-924
 URL: https://jira.codehaus.org/browse/SUREFIRE-924
 Project: Maven Surefire
  Issue Type: Task
  Components: documentation, Maven Failsafe Plugin, Maven Surefire 
 Plugin, Maven Surefire Report Plugin
Affects Versions: 2.12.4
Reporter: Herve Boutemy
Assignee: Herve Boutemy
 Fix For: 2.13


 Surefire generates site content dispatched in misc locations:
 - /surefire
 - /plugins/maven-surefire-plugin
 - /plugins/maven-failsafe-plugin
 - /plugins/maven-surefire-report-plugin
 This will cause problems when we switch to svnpubsub+maven-scm-publish-plugin 
 because this won't represent one unique svn commit
 the build should deploy everything in /surefire and the site redirect from 
 /plugins/surefure plugins locations to /surefire/*

--
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] (MPLUGIN-233) remove InstanciationStrategy enum from annotations

Herve Boutemy created MPLUGIN-233:
-

 Summary: remove InstanciationStrategy enum from annotations
 Key: MPLUGIN-233
 URL: https://jira.codehaus.org/browse/MPLUGIN-233
 Project: Maven 2.x Plugin Tools
  Issue Type: Task
  Components: maven-plugin-annotations
Affects Versions: 3.1, 3.0, 3.2
Reporter: Herve Boutemy


it was a typo, replaced by InstantiationStrategy quite early in 3.0 release 
cycle
then should not cause any harm to simply remove instead of deprecating

--
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] (MPLUGIN-233) remove InstanciationStrategy enum from annotations


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

Herve Boutemy closed MPLUGIN-233.
-

   Resolution: Fixed
Fix Version/s: 3.2.1
 Assignee: Herve Boutemy

done in [r1406929|http://svn.apache.org/viewvc?rev=1406929view=rev]

 remove InstanciationStrategy enum from annotations
 --

 Key: MPLUGIN-233
 URL: https://jira.codehaus.org/browse/MPLUGIN-233
 Project: Maven 2.x Plugin Tools
  Issue Type: Task
  Components: maven-plugin-annotations
Affects Versions: 3.0, 3.1, 3.2
Reporter: Herve Boutemy
Assignee: Herve Boutemy
 Fix For: 3.2.1


 it was a typo, replaced by InstantiationStrategy quite early in 3.0 release 
 cycle
 then should not cause any harm to simply remove instead of deprecating

--
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-3092) Version ranges with non-snapshot bounds can contain snapshot versions


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

Herve Boutemy commented on MNG-3092:


yes, Maven 3.1 can be a chance to do something
to me, the question is not is a snapshot in a range, because the reply is 
obvious: yes, a snapshot is in the range since a range is a mathematical notion 
with two bounds and a comparison algorihtm
but the questionis more: how does Maven choose the best match when multiple 
artifacts are available matching restrictions (I say restriction to avoid 
range and since ranges are only one form of restriction)
then we need a use case with a reproducible simple test to work on it (and I 
need to look for where is the code that makes this choice)

is somebody interested in working in such a direction?

 Version ranges with non-snapshot bounds can contain snapshot versions
 -

 Key: MNG-3092
 URL: https://jira.codehaus.org/browse/MNG-3092
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
Reporter: Mark Hobson
 Attachments: MNG-3092.patch


 Contrary to the 2.0 design docs:
 Resolution of dependency ranges should not resolve to a snapshot 
 (development version) unless it is included as an explicit boundary.
 -- from 
 http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification
 The following is equates to true:
 VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new 
 DefaultArtifactVersion( 1.1-SNAPSHOT ) )
 The attached patch only allows snapshot versions to be contained in a range 
 if they are equal to one of the boundaries.  Note that this is a strict 
 equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT.

--
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-3092) Version ranges with non-snapshot bounds can contain snapshot versions


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

Herve Boutemy edited comment on MNG-3092 at 11/8/12 12:18 AM:
--

yes, Maven 3.1 can be a chance to do something
to me, the question is not is a snapshot in a range?, because the reply is 
obvious: yes, a snapshot is in the range since a range is a mathematical notion 
with two bounds and an order (a comparison algorithm)
but the questionis more: how does Maven choose the best match when multiple 
artifacts are available matching restrictions? (I say restriction to avoid 
range and since ranges are only one form of restriction)
then we need a use case with a reproducible simple test to work on it (and I 
need to look for where is the code that makes this choice)

is somebody interested in working in such a direction?

  was (Author: hboutemy):
yes, Maven 3.1 can be a chance to do something
to me, the question is not is a snapshot in a range, because the reply is 
obvious: yes, a snapshot is in the range since a range is a mathematical notion 
with two bounds and a comparison algorihtm
but the questionis more: how does Maven choose the best match when multiple 
artifacts are available matching restrictions (I say restriction to avoid 
range and since ranges are only one form of restriction)
then we need a use case with a reproducible simple test to work on it (and I 
need to look for where is the code that makes this choice)

is somebody interested in working in such a direction?
  
 Version ranges with non-snapshot bounds can contain snapshot versions
 -

 Key: MNG-3092
 URL: https://jira.codehaus.org/browse/MNG-3092
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
Reporter: Mark Hobson
 Attachments: MNG-3092.patch


 Contrary to the 2.0 design docs:
 Resolution of dependency ranges should not resolve to a snapshot 
 (development version) unless it is included as an explicit boundary.
 -- from 
 http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification
 The following is equates to true:
 VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new 
 DefaultArtifactVersion( 1.1-SNAPSHOT ) )
 The attached patch only allows snapshot versions to be contained in a range 
 if they are equal to one of the boundaries.  Note that this is a strict 
 equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT.

--
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-3092) Version ranges with non-snapshot bounds can contain snapshot versions


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

Herve Boutemy commented on MNG-3092:


when I read http://www.infoq.com/news/2012/04/osgi-snapshot, I understand they 
cannot do SNASPHOT this way:
a SNAPSHOT in Maven is not 1.1.20121108..., but 1.1-20121108...: notice the 
dash instead of dot, and read [the Maven comparison 
doc|http://maven.apache.org/ref/3.1-SNAPSHOT/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html]
 a dash usually precedes a qualifier, and *is always less important than 
something preceded with a dot*.

if OSGi can't afford a new separator, they can't do SNAPSHOTs like Maven, or 
they'll face problem reported by the article: the comparison algorithm is based 
on a bad trick to change behaviour when a minor number is detected as a 
timestamp then not treated as a real number

 Version ranges with non-snapshot bounds can contain snapshot versions
 -

 Key: MNG-3092
 URL: https://jira.codehaus.org/browse/MNG-3092
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
Reporter: Mark Hobson
 Attachments: MNG-3092.patch


 Contrary to the 2.0 design docs:
 Resolution of dependency ranges should not resolve to a snapshot 
 (development version) unless it is included as an explicit boundary.
 -- from 
 http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification
 The following is equates to true:
 VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new 
 DefaultArtifactVersion( 1.1-SNAPSHOT ) )
 The attached patch only allows snapshot versions to be contained in a range 
 if they are equal to one of the boundaries.  Note that this is a strict 
 equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT.

--
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-924) generate every Surefire artifact site in /surefire and redirect previous /plugins/maven-(surefire|failsafe|surefire-report)-plugin


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

Herve Boutemy closed SUREFIRE-924.
--

Resolution: Fixed

done in 
[a2929af1|http://git-wip-us.apache.org/repos/asf/maven-surefire/commit/a2929af1]

 generate every Surefire artifact site in /surefire and redirect previous 
 /plugins/maven-(surefire|failsafe|surefire-report)-plugin
 --

 Key: SUREFIRE-924
 URL: https://jira.codehaus.org/browse/SUREFIRE-924
 Project: Maven Surefire
  Issue Type: Task
  Components: documentation, Maven Failsafe Plugin, Maven Surefire 
 Plugin, Maven Surefire Report Plugin
Affects Versions: 2.12.4
Reporter: Herve Boutemy
Assignee: Herve Boutemy
 Fix For: 2.13


 Surefire generates site content dispatched in misc locations:
 - /surefire
 - /plugins/maven-surefire-plugin
 - /plugins/maven-failsafe-plugin
 - /plugins/maven-surefire-report-plugin
 This will cause problems when we switch to svnpubsub+maven-scm-publish-plugin 
 because this won't represent one unique svn commit
 the build should deploy everything in /surefire and the site redirect from 
 /plugins/surefure plugins locations to /surefire/*

--
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-924) generate every Surefire artifact site in /surefire and redirect previous /plugins/maven-(surefire|failsafe|surefire-report)-plugin


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

Herve Boutemy edited comment on SUREFIRE-924 at 11/8/12 1:00 AM:
-

done in 
[a2929af1a62c02e2ecbc54621c5c93f6911638d6|http://git-wip-us.apache.org/repos/asf/maven-surefire/commit/a2929af1]

  was (Author: hboutemy):
done in 
[a2929af1|http://git-wip-us.apache.org/repos/asf/maven-surefire/commit/a2929af1]
  
 generate every Surefire artifact site in /surefire and redirect previous 
 /plugins/maven-(surefire|failsafe|surefire-report)-plugin
 --

 Key: SUREFIRE-924
 URL: https://jira.codehaus.org/browse/SUREFIRE-924
 Project: Maven Surefire
  Issue Type: Task
  Components: documentation, Maven Failsafe Plugin, Maven Surefire 
 Plugin, Maven Surefire Report Plugin
Affects Versions: 2.12.4
Reporter: Herve Boutemy
Assignee: Herve Boutemy
 Fix For: 2.13


 Surefire generates site content dispatched in misc locations:
 - /surefire
 - /plugins/maven-surefire-plugin
 - /plugins/maven-failsafe-plugin
 - /plugins/maven-surefire-report-plugin
 This will cause problems when we switch to svnpubsub+maven-scm-publish-plugin 
 because this won't represent one unique svn commit
 the build should deploy everything in /surefire and the site redirect from 
 /plugins/surefure plugins locations to /surefire/*

--
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-924) generate every Surefire artifact site in /surefire and redirect previous /plugins/maven-(surefire|failsafe|surefire-report)-plugin


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

Herve Boutemy commented on SUREFIRE-924:


redirection is prepared in 
[r1406944|http://svn.apache.org/viewvc?rev=1406944view=rev]: just need to 
uncomment when necessary

 generate every Surefire artifact site in /surefire and redirect previous 
 /plugins/maven-(surefire|failsafe|surefire-report)-plugin
 --

 Key: SUREFIRE-924
 URL: https://jira.codehaus.org/browse/SUREFIRE-924
 Project: Maven Surefire
  Issue Type: Task
  Components: documentation, Maven Failsafe Plugin, Maven Surefire 
 Plugin, Maven Surefire Report Plugin
Affects Versions: 2.12.4
Reporter: Herve Boutemy
Assignee: Herve Boutemy
 Fix For: 2.13


 Surefire generates site content dispatched in misc locations:
 - /surefire
 - /plugins/maven-surefire-plugin
 - /plugins/maven-failsafe-plugin
 - /plugins/maven-surefire-report-plugin
 This will cause problems when we switch to svnpubsub+maven-scm-publish-plugin 
 because this won't represent one unique svn commit
 the build should deploy everything in /surefire and the site redirect from 
 /plugins/surefure plugins locations to /surefire/*

--
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] (MENFORCER-144) generate every enforcer plugin site in /enforcer and redirect previous /plugins/maven-enforcer-plugin


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

Herve Boutemy updated MENFORCER-144:


Fix Version/s: 1.2

 generate every enforcer plugin site in /enforcer and redirect previous 
 /plugins/maven-enforcer-plugin
 -

 Key: MENFORCER-144
 URL: https://jira.codehaus.org/browse/MENFORCER-144
 Project: Maven 2.x Enforcer Plugin
  Issue Type: Task
  Components: Plugin
Affects Versions: 1.1.1
Reporter: Herve Boutemy
 Fix For: 1.2


 like SUREFIRE-924, this will be necessary for 
 svnpubsub+maven-scm-publish-plugin migration

--
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] (MENFORCER-144) generate every enforcer plugin site in /enforcer and redirect previous /plugins/maven-enforcer-plugin

Herve Boutemy created MENFORCER-144:
---

 Summary: generate every enforcer plugin site in /enforcer and 
redirect previous /plugins/maven-enforcer-plugin
 Key: MENFORCER-144
 URL: https://jira.codehaus.org/browse/MENFORCER-144
 Project: Maven 2.x Enforcer Plugin
  Issue Type: Task
  Components: Plugin
Affects Versions: 1.1.1
Reporter: Herve Boutemy


like SUREFIRE-924, this will be necessary for 
svnpubsub+maven-scm-publish-plugin migration

--
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] (MENFORCER-144) generate every enforcer plugin site in /enforcer and redirect previous /plugins/maven-enforcer-plugin