[jira] (SUREFIRE-864) NPE when unit test loads resources from JAR

2012-10-26 Thread Kristian Rosenvold (JIRA)

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

Kristian Rosenvold closed SUREFIRE-864.
---

Resolution: Not A Bug
  Assignee: Kristian Rosenvold

This is not really a surefire bug, but rather the eclipse classloader 
implementation that allows you to enumerate directories, which is not supported 
by the regular jdk.

If you run the testcase with just a standard jdk, you'll see it doesn't work 
there either. 

http://stackoverflow.com/questions/3923129/get-a-list-of-resources-from-classpath-directory

> NPE when unit test loads resources from JAR
> ---
>
> Key: SUREFIRE-864
> URL: https://jira.codehaus.org/browse/SUREFIRE-864
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.9, 2.10, 2.11, 2.12
> Environment: Windows 64-bit, Eclipse Maven plug-in
>Reporter: Luke Stevens
>Assignee: Kristian Rosenvold
> Attachments: TestSurefire.zip
>
>
> I have a unit test that reads resources from a JAR built by another project. 
> This works totally fine when running JUnit within Eclipse. But when building 
> under Maven, it hits an error:
> java.lang.NullPointerException
> at java.io.FilterInputStream.close(FilterInputStream.java:155)
> at 
> sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream.close(JarURLConnection.java:90)
> ...
> Suppressing this error (which occurs on close, after all) only leads to 
> others.
> Some digging reveals that this is probably related to a longstanding 
> classloader bug in the JVM:
> http://stackoverflow.com/questions/3216780/
> A very simple project is attached to demonstrate the problem.

--
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] (DOXIA-476) Doxia appends .html to file suffix when linking to a file with confluence markup

2012-10-26 Thread Lukas Theussl (JIRA)

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

Lukas Theussl closed DOXIA-476.
---

Resolution: Duplicate
  Assignee: Lukas Theussl

> Doxia appends .html to file suffix when linking to a file with confluence 
> markup
> 
>
> Key: DOXIA-476
> URL: https://jira.codehaus.org/browse/DOXIA-476
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Module - Confluence
>Affects Versions: 1.3
>Reporter: Tuukka Mustonen
>Assignee: Lukas Theussl
>
> As reported in 
> http://jira.codehaus.org/browse/DOXIA-298?focusedCommentId=300128&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-300128,
>  caused by fix of http://jira.codehaus.org/browse/DOXIA-298
> Adding a link to a file with Confluence markup causes generated HTML to 
> always append .html to the file suffix, causing linkage to fail.
> To reproduce:
> {code}
> Click on this [link to a file|a-powerpoint-file.ppt]
> {code}
> Renders as:
> {code}
> Click on this link to a file
> {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-614) useTransitiveFiltering implemented contrarily

2012-10-26 Thread Felix Martin Martin (JIRA)

[ 
https://jira.codehaus.org/browse/MASSEMBLY-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312355#comment-312355
 ] 

Felix Martin Martin commented on MASSEMBLY-614:
---

It also affects to version 2.2.1

> useTransitiveFiltering implemented contrarily
> -
>
> Key: MASSEMBLY-614
> URL: https://jira.codehaus.org/browse/MASSEMBLY-614
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Jörg Schaible
>
> useTransitiveFiltering is implemented wrongly, it filters when set to false 
> and does not filter when set to true.
> One of the declared dependencies in the project is this:
> {code:xml}
> 
>   com.sun.xml.ws
>   jaxws-rt
>   2.2.6
> 
> {code}
> The assembly descriptor is:
> {code:xml}
> 
>   false
>   false
>   true
>   false
>   
> *:jaxws*
>   
> 
> {code}
> The result contains only the jar for jaxws-rt, but not its dependencies. 
> Setting useTransitiveFiltering to true, then all dependencies are included. 
> It works quite contrary to the documentation and the implicit property name.

--
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-814) Parallel "both" setting does not execute classes in parallel

2012-10-26 Thread Kristian Rosenvold (JIRA)

[ 
https://jira.codehaus.org/browse/SUREFIRE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312356#comment-312356
 ] 

Kristian Rosenvold commented on SUREFIRE-814:
-

We had a bug that was fixed for 2.12 that may be the source of your problem 
(SUREFIRE-865). Please confirm if the problem persists with the latest version 
(2.12.4 as of this writing)

> Parallel "both" setting does not execute classes in parallel
> 
>
> Key: SUREFIRE-814
> URL: https://jira.codehaus.org/browse/SUREFIRE-814
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.11
>Reporter: Quantum Mechanics
>
> jdk 1.6.0_22, windows XP

--
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] (MSITE-661) support markdown format per default

2012-10-26 Thread Olivier Lamy (JIRA)

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

Olivier Lamy updated MSITE-661:
---

Fix Version/s: 3.3
 Assignee: Olivier Lamy

> support markdown format per default
> ---
>
> Key: MSITE-661
> URL: https://jira.codehaus.org/browse/MSITE-661
> Project: Maven 2.x and 3.x Site Plugin
>  Issue Type: Bug
>  Components: doxia integration
>Affects Versions: 3.2
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
> Fix For: 3.3
>
>
> currently using markdown format need extra configuration.
> This must be supported per default

--
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] (MSITE-661) support markdown format per default

2012-10-26 Thread Olivier Lamy (JIRA)
Olivier Lamy created MSITE-661:
--

 Summary: support markdown format per default
 Key: MSITE-661
 URL: https://jira.codehaus.org/browse/MSITE-661
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: doxia integration
Affects Versions: 3.2
Reporter: Olivier Lamy


currently using markdown format need extra configuration.
This must be supported per default

--
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] (MSITE-661) support markdown format per default

2012-10-26 Thread Olivier Lamy (JIRA)

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

Olivier Lamy closed MSITE-661.
--

Resolution: Fixed

fixed.

> support markdown format per default
> ---
>
> Key: MSITE-661
> URL: https://jira.codehaus.org/browse/MSITE-661
> Project: Maven 2.x and 3.x Site Plugin
>  Issue Type: Bug
>  Components: doxia integration
>Affects Versions: 3.2
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
> Fix For: 3.3
>
>
> currently using markdown format need extra configuration.
> This must be supported per default

--
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-5237) Cannot download maven dependencies through proxy

2012-10-26 Thread Phillip Singer (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312386#comment-312386
 ] 

Phillip Singer commented on MNG-5237:
-

I just ran across this thread: 
http://mail-archives.apache.org/mod_mbox/maven-users/201208.mbox/%3c501ce4e9.5000...@pp6.inet.fi%3E

Might that be your issue instead?

> Cannot download maven dependencies through proxy
> 
>
> Key: MNG-5237
> URL: https://jira.codehaus.org/browse/MNG-5237
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.0.4
> Environment: windows xp64 using cygwin
>Reporter: Niels Mordt-Ostergaard
>Assignee: Jason van Zyl
>
> Using proxy in settings.xml, I was able to download maven dependencies in 
> 3.0.3, but this seems to be broken with 3.0.4:
> Proxy definition in settings.xml (hidden ip adress below, but correct proxy 
> ip on my system):
>   
>
>   optional
>   true
>   http
>   
>   
>   xxx.xx.xx.xx
>   8080
>   localhost|127.0.0.1
> 
>   
> Output from 3.0.3:
> $ mvn -V clean
> Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: C:\Program Files\apache-maven-3.0.3
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_24\jre
> Default locale: no_NO, platform encoding: Cp1252
> OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows"
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building 
> [INFO] 
> 
> Downloading: 
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
> Downloaded: 
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
>  (5 KB at 4.9 KB/sec)
> . and so on...
> Output from 3.0.4:
> $ mvn -V clean
> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Maven home: C:\Program Files\apache-maven-3.0.4
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_24\jre
> Default locale: no_NO, platform encoding: Cp1252
> OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows"
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building 
> [INFO] 
> 
> Downloading: 
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 0.390s
> [INFO] Finished at: Fri Feb 03 13:14:35 CET 2012
> [INFO] Final Memory: 5M/490M
> [INFO] 
> 
> [ERROR] Plugin org.apache.maven.plugins:maven-clean-plugin:2.4.1 or one of 
> its dependencies could not be resolved: Failed to read artifact descriptor 
> for org.apache.maven.plugins:maven-clean-plugin:jar:2.4.1: Could not transfer 
> artifact org.apache.maven.plugins:maven-clean-plugin:pom:2.4.1 from/to 
> central (http://repo.maven.apache.org/maven2): Access denied to: 
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom,
>  ReasonPhrase:Forbidden. -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

--
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-5237) Cannot download maven dependencies through proxy

2012-10-26 Thread Anders Hammar (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312387#comment-312387
 ] 

Anders Hammar commented on MNG-5237:


Should "proxy" in this ticket's summary be changed to "NTLM proxy"?

> Cannot download maven dependencies through proxy
> 
>
> Key: MNG-5237
> URL: https://jira.codehaus.org/browse/MNG-5237
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.0.4
> Environment: windows xp64 using cygwin
>Reporter: Niels Mordt-Ostergaard
>Assignee: Jason van Zyl
>
> Using proxy in settings.xml, I was able to download maven dependencies in 
> 3.0.3, but this seems to be broken with 3.0.4:
> Proxy definition in settings.xml (hidden ip adress below, but correct proxy 
> ip on my system):
>   
>
>   optional
>   true
>   http
>   
>   
>   xxx.xx.xx.xx
>   8080
>   localhost|127.0.0.1
> 
>   
> Output from 3.0.3:
> $ mvn -V clean
> Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: C:\Program Files\apache-maven-3.0.3
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_24\jre
> Default locale: no_NO, platform encoding: Cp1252
> OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows"
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building 
> [INFO] 
> 
> Downloading: 
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
> Downloaded: 
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
>  (5 KB at 4.9 KB/sec)
> . and so on...
> Output from 3.0.4:
> $ mvn -V clean
> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Maven home: C:\Program Files\apache-maven-3.0.4
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_24\jre
> Default locale: no_NO, platform encoding: Cp1252
> OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows"
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building 
> [INFO] 
> 
> Downloading: 
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 0.390s
> [INFO] Finished at: Fri Feb 03 13:14:35 CET 2012
> [INFO] Final Memory: 5M/490M
> [INFO] 
> 
> [ERROR] Plugin org.apache.maven.plugins:maven-clean-plugin:2.4.1 or one of 
> its dependencies could not be resolved: Failed to read artifact descriptor 
> for org.apache.maven.plugins:maven-clean-plugin:jar:2.4.1: Could not transfer 
> artifact org.apache.maven.plugins:maven-clean-plugin:pom:2.4.1 from/to 
> central (http://repo.maven.apache.org/maven2): Access denied to: 
> http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom,
>  ReasonPhrase:Forbidden. -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

--
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-5324) Incorrect parsing of metadata by Maven: Cannot find snapshot artifact with older timestamp

2012-10-26 Thread Robert Scholte (JIRA)

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

Robert Scholte reassigned MNG-5324:
---

Assignee: Robert Scholte

> Incorrect parsing of metadata by Maven: Cannot find snapshot artifact with 
> older timestamp
> --
>
> Key: MNG-5324
> URL: https://jira.codehaus.org/browse/MNG-5324
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 3.0.4
>Reporter: Anton Smeenk
>Assignee: Robert Scholte
> Attachments: DefaultVersionResolver.java, 
> DefaultVersionResolver.java, DefaultVersionResolver.patch
>
>
> Maven can only retrieve an artifact from Nexus with a classifier with latest 
> timestamp.
> Artifacts with classifiers with an older timestamp cannot be resolved.
> For example. If I deploy an artifact Apple with classifier A and a bit later 
> deploy the same artifact with classifier B.
> Next I want to retrieve the artifacts from Nexus:
> For a module Banana, which needs Apple with classifier A the Artifact 
> resolver will fail.
> For a module Strawberry, which needs Apple with classifier B the Artifact 
> resolver will succesfully resolve the artifact.
> I found the cause for this behaviour:
> With an proxy between Maven and Nexus I could see the behavour of Maven, at 
> the moment that I want to fetch an artifact:
> First the metadata.xml is fetched from Nexus. This file does contain the 
> timestamp of the latest artifact in nexus and all timestamps of older 
> artifacts, with different classifier.
> From this metdata file Maven figures out what the correct name is for the 
> artifact.
> But Maven can resolve the name of classifierb, but not the name of 
> classifierB. 
> The metadata is not correctly parsed! All information is there, but still 
> Maven can only find the artifact with the latest timestamp.
> Here is an example of an metadata file:
> {code:xml}
>  
>   com.ccv.systems.modules.gen_modem 
>   modem 
>   07.20.3-SNAPSHOT 
>  
>  
>   20120809.112920 
>   97 
>   
>   20120809112920 
>  
>   classsifierA 
>   jar 
>   07.20.3-20120809.112124-88 
>   20120809112124 
>   
>  
>   classsifierB 
>   jar 
>   07.20.3-20120809.112920-97 
>   20120809112920 
>   
>   
>   
>   
> {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] (MNG-3507) ANSI Color logging for improved output visibility.

2012-10-26 Thread Gary Gregory (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312393#comment-312393
 ] 

Gary Gregory commented on MNG-3507:
---

Note that if Maven used JAnsi, color logging would work everywhere including 
Windows.

> ANSI Color logging for improved output visibility.
> --
>
> Key: MNG-3507
> URL: https://jira.codehaus.org/browse/MNG-3507
> Project: Maven 2 & 3
>  Issue Type: Improvement
>Reporter: Rahul Thakur
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: maven-colorlogger.zip, 
> plexus-colorized-ConsoleLogger.patch, pom.xml
>
>
> Is it possible for Maven to use ANSI color logging? IMO it would make Maven 
> logs much easier to read and increase the visibility of items that the user 
> want to see at any given point in time. 
> I think Andrew Williams did some work under Plexus sandbox to enable color 
> logging. There also a color logger available in Ant. 
> http://ant.apache.org/manual/listeners.html#AnsiColorLogger

--
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-626) NullPointerException in PlexusIoURLResource.getContents

2012-10-26 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MASSEMBLY-626.
-

   Resolution: Fixed
Fix Version/s: 2.4
 Assignee: Dennis Lundberg

Fixed in [r1402674|http://svn.apache.org/viewvc?view=revision&revision=1402674].

Thanks Kristian!

> NullPointerException in PlexusIoURLResource.getContents
> ---
>
> Key: MASSEMBLY-626
> URL: https://jira.codehaus.org/browse/MASSEMBLY-626
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Nathaniel Mishkin
>Assignee: Dennis Lundberg
> Fix For: 2.4
>
>
> I have a situation where I can reliably reproduce an NPE during assembly in 
> one dev environment but not in another.  Probably the most notable difference 
> between the environments is that the working one is running Windows and the 
> non-working one is running Linux, but it's not clear why that should matter.  
> The project is unfortunately part of a large multi-module project so I can't 
> readily attach it here and I haven't yet attempted to boil it down.  So 
> hopefully this stack trace will help:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-assembly-plugin:2.3:single (default) on 
> project system-tests: Execution default of goal 
> org.apache.maven.plugins:maven-assembly-plugin:2.3:single failed. 
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-assembly-plugin:2.3:single (default) on 
> project system-tests: Execution default of goal 
> org.apache.maven.plugins:maven-assembly-plugin:2.3:single failed.
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
>   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 org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>   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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
> default of goal org.apache.maven.plugins:maven-assembly-plugin:2.3:single 
> failed.
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>   ... 19 more
> Caused by: java.lang.NullPointerException
>   at 
> org.codehaus.plexus.components.io.resources.PlexusIoURLResource.getContents(PlexusIoURLResource.java:38)
>   at 
> org.codehaus.plexus.archiver.ArchiveEntry.getInputStream(ArchiveEntry.java:106)
>   at 
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:552)
>   at 
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:387)
>   at 
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:312)
>   at 
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:211)
>   at 
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:897)
>   at 
> org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:512)

[jira] (MNG-5324) Incorrect parsing of metadata by Maven: Cannot find snapshot artifact with older timestamp

2012-10-26 Thread Robert Scholte (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-5324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312407#comment-312407
 ] 

Robert Scholte commented on MNG-5324:
-

Anton,

I've written a junit-test, committed in 
[r1402675|http://svn.apache.org/viewvc?rev=1402675&view=rev]. These tests 
succeed, so it seems that the problem is somewhere else.
My idea is that the classified jar already got the wrong uniqueVersion when it 
entered this method. So we need to figure out where.


> Incorrect parsing of metadata by Maven: Cannot find snapshot artifact with 
> older timestamp
> --
>
> Key: MNG-5324
> URL: https://jira.codehaus.org/browse/MNG-5324
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 3.0.4
>Reporter: Anton Smeenk
>Assignee: Robert Scholte
> Attachments: DefaultVersionResolver.java, 
> DefaultVersionResolver.java, DefaultVersionResolver.patch
>
>
> Maven can only retrieve an artifact from Nexus with a classifier with latest 
> timestamp.
> Artifacts with classifiers with an older timestamp cannot be resolved.
> For example. If I deploy an artifact Apple with classifier A and a bit later 
> deploy the same artifact with classifier B.
> Next I want to retrieve the artifacts from Nexus:
> For a module Banana, which needs Apple with classifier A the Artifact 
> resolver will fail.
> For a module Strawberry, which needs Apple with classifier B the Artifact 
> resolver will succesfully resolve the artifact.
> I found the cause for this behaviour:
> With an proxy between Maven and Nexus I could see the behavour of Maven, at 
> the moment that I want to fetch an artifact:
> First the metadata.xml is fetched from Nexus. This file does contain the 
> timestamp of the latest artifact in nexus and all timestamps of older 
> artifacts, with different classifier.
> From this metdata file Maven figures out what the correct name is for the 
> artifact.
> But Maven can resolve the name of classifierb, but not the name of 
> classifierB. 
> The metadata is not correctly parsed! All information is there, but still 
> Maven can only find the artifact with the latest timestamp.
> Here is an example of an metadata file:
> {code:xml}
>  
>   com.ccv.systems.modules.gen_modem 
>   modem 
>   07.20.3-SNAPSHOT 
>  
>  
>   20120809.112920 
>   97 
>   
>   20120809112920 
>  
>   classsifierA 
>   jar 
>   07.20.3-20120809.112124-88 
>   20120809112124 
>   
>  
>   classsifierB 
>   jar 
>   07.20.3-20120809.112920-97 
>   20120809112920 
>   
>   
>   
>   
> {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-571) moduleSet dependencies processed incorrectly

2012-10-26 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg updated MASSEMBLY-571:
--

Description: 
Following configuration:
{code:xml}


com.example:extra-hiper-app



my-app.${extension}
output/lib
false

true



${artifactId}-${version}.${extension}




{code}

Results in bunch of: 
{noformat}
[INFO] lib/my-app-0.0.1.${extension} already added, skipping
{noformat}

with assembly plugin in version 2.2.1


NOTE: but it works correctly (and as expected with version: 2.2-beta-1)


  was:
Following configuration:


com.example:extra-hiper-app



my-app.${extension}
output/lib
false

true



${artifactId}-${version}.${extension}





Results in bunch of: 
[INFO] lib/my-app-0.0.1.${extension} already added, skipping

with assembly plugin in version 2.2.1


NOTE: but it works correctly (and as expected with version: 2.2-beta-1)


Summary: moduleSet dependencies processed incorrectly  (was: moduleSet 
dependencies processed incorrecrly)

> moduleSet dependencies processed incorrectly
> 
>
> Key: MASSEMBLY-571
> URL: https://jira.codehaus.org/browse/MASSEMBLY-571
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2.1
> Environment: any
>Reporter: Paul Green
>Priority: Critical
>
> Following configuration:
> {code:xml}
> 
> 
> com.example:extra-hiper-app
> 
> 
> 
> my-app.${extension}
> output/lib
> false
> true
> 
> 
> 
> ${artifactId}-${version}.${extension}
> 
> 
> 
> 
> {code}
> Results in bunch of: 
> {noformat}
> [INFO] lib/my-app-0.0.1.${extension} already added, skipping
> {noformat}
> with assembly plugin in version 2.2.1
> NOTE: but it works correctly (and as expected with version: 2.2-beta-1)

--
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-571) moduleSet dependencies processed incorrectly

2012-10-26 Thread Dennis Lundberg (JIRA)

[ 
https://jira.codehaus.org/browse/MASSEMBLY-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312408#comment-312408
 ] 

Dennis Lundberg commented on MASSEMBLY-571:
---

In what way is this not working? We need more information.

> moduleSet dependencies processed incorrectly
> 
>
> Key: MASSEMBLY-571
> URL: https://jira.codehaus.org/browse/MASSEMBLY-571
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2.1
> Environment: any
>Reporter: Paul Green
>Priority: Critical
>
> Following configuration:
> {code:xml}
> 
> 
> com.example:extra-hiper-app
> 
> 
> 
> my-app.${extension}
> output/lib
> false
> true
> 
> 
> 
> ${artifactId}-${version}.${extension}
> 
> 
> 
> 
> {code}
> Results in bunch of: 
> {noformat}
> [INFO] lib/my-app-0.0.1.${extension} already added, skipping
> {noformat}
> with assembly plugin in version 2.2.1
> NOTE: but it works correctly (and as expected with version: 2.2-beta-1)

--
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-5365) Replace Aether's deprecated ConfigurationProperties with ConfigUtils

2012-10-26 Thread Robert Scholte (JIRA)

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

Robert Scholte reassigned MNG-5365:
---

Assignee: Robert Scholte

> Replace Aether's deprecated ConfigurationProperties with ConfigUtils
> 
>
> Key: MNG-5365
> URL: https://jira.codehaus.org/browse/MNG-5365
> Project: Maven 2 & 3
>  Issue Type: Task
>  Components: Artifacts and Repositories
>Affects Versions: 3.0.4
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Minor
>


--
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-5365) Replace Aether's deprecated ConfigurationProperties with ConfigUtils

2012-10-26 Thread Robert Scholte (JIRA)
Robert Scholte created MNG-5365:
---

 Summary: Replace Aether's deprecated ConfigurationProperties with 
ConfigUtils
 Key: MNG-5365
 URL: https://jira.codehaus.org/browse/MNG-5365
 Project: Maven 2 & 3
  Issue Type: Task
  Components: Artifacts and Repositories
Affects Versions: 3.0.4
Reporter: Robert Scholte
Priority: Minor




--
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-5365) Replace Aether's deprecated ConfigurationProperties with ConfigUtils

2012-10-26 Thread Robert Scholte (JIRA)

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

Robert Scholte closed MNG-5365.
---

   Resolution: Fixed
Fix Version/s: 3.1

Fixed in [r1402701|http://svn.apache.org/viewvc?rev=1402701&view=rev]

> Replace Aether's deprecated ConfigurationProperties with ConfigUtils
> 
>
> Key: MNG-5365
> URL: https://jira.codehaus.org/browse/MNG-5365
> Project: Maven 2 & 3
>  Issue Type: Task
>  Components: Artifacts and Repositories
>Affects Versions: 3.0.4
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.1
>
>


--
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-610) Documentation unclear in the Usage > Configuration section

2012-10-26 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MASSEMBLY-610.
-

   Resolution: Fixed
Fix Version/s: 2.4
 Assignee: Dennis Lundberg

Fixed in [r1402704|http://svn.apache.org/viewvc?view=revision&revision=1402704].

> Documentation unclear in the Usage > Configuration section
> --
>
> Key: MASSEMBLY-610
> URL: https://jira.codehaus.org/browse/MASSEMBLY-610
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
>Reporter: jacques
>Assignee: Dennis Lundberg
> Fix For: 2.4
>
>
> "If you're using one of the prefabricated assembly descriptors, you just tell 
> it which one; if you're using a custom assembly descriptor, you give it the 
> path to the descriptor."
> Now really, any IT or Non IT english person will read this and immediately 
> ask: "What is 'it'"?
> "If you're using one of the prefabricated assembly descriptors, you just tell 
> it which one"
> huh? come again?
> "If YOU are using X of Y, YOU just tell it which X." Who the hell is "it"?

--
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-611) Documentation unclear in Usage > Configuration (part 2)

2012-10-26 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MASSEMBLY-611.
-

   Resolution: Fixed
Fix Version/s: 2.4
 Assignee: Dennis Lundberg

Fixed in [r1402706|http://svn.apache.org/viewvc?view=revision&revision=1402706].

> Documentation unclear in Usage > Configuration (part 2)
> ---
>
> Key: MASSEMBLY-611
> URL: https://jira.codehaus.org/browse/MASSEMBLY-611
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
>Reporter: jacques
>Assignee: Dennis Lundberg
> Fix For: 2.4
>
>
> The example that follows "we can take advantage of one of the Assembly 
> Plugin's prefabricated descriptors, as follows:" does not state that we're 
> looking at the pom.xml. We are right? I'm just guessing here.

--
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-612) Documentation improvements: Assembly page

2012-10-26 Thread Dennis Lundberg (JIRA)

[ 
https://jira.codehaus.org/browse/MASSEMBLY-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312413#comment-312413
 ] 

Dennis Lundberg commented on MASSEMBLY-612:
---

What is it you want?
Do you want a list of the available prefabricated descriptors?
Do you want links to the assembly descriptor files for the prefabricated 
descriptors?
Do you want a link to an index of which prefabricated descriptors are available?


> Documentation improvements: Assembly page
> -
>
> Key: MASSEMBLY-612
> URL: https://jira.codehaus.org/browse/MASSEMBLY-612
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
>Reporter: jacques
>
> "Although there are already prefabricated descriptors available for use, they 
> can only suffice some of the common assembly requirements."
> Where are these plura of prefabricated descriptors?

--
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-608) Missing XML tag in example documentation

2012-10-26 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MASSEMBLY-608.
-

   Resolution: Fixed
Fix Version/s: 2.4
 Assignee: Dennis Lundberg

Fixed in [r1402707|http://svn.apache.org/viewvc?view=revision&revision=1402707].

> Missing XML tag  in example documentation
> --
>
> Key: MASSEMBLY-608
> URL: https://jira.codehaus.org/browse/MASSEMBLY-608
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.3
> Environment: 
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
>Reporter: Alexander Tumin
>Assignee: Dennis Lundberg
> Fix For: 2.4
>
> Attachments: module-binary-inclusion-simple.html
>
>
> On the 
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
>  page there is missing tag  between  and  in third 
> snippet (one that goes to distribution module's pom.xml), which results in 
> XML validation failure by maven.

--
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-604) Please document dir

2012-10-26 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MASSEMBLY-604.
-

   Resolution: Fixed
Fix Version/s: 2.4
 Assignee: Dennis Lundberg

Fixed in [r1402709|http://svn.apache.org/viewvc?view=revision&revision=1402709].

> Please document dir
> 
>
> Key: MASSEMBLY-604
> URL: https://jira.codehaus.org/browse/MASSEMBLY-604
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.3
> Environment: FreeBSD 64 bit
>Reporter: Radim Kolar
>Assignee: Dennis Lundberg
> Fix For: 2.4
>
>
> Please document that you can also pack files into directory, not only archive.
> I mean - dir
> I had to dig in source code to discover that.

--
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-623) Assembly documentation does not list all supported formats

2012-10-26 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MASSEMBLY-623.
-

   Resolution: Fixed
Fix Version/s: 2.4
 Assignee: Dennis Lundberg

Fixed in [r1402709|http://svn.apache.org/viewvc?view=revision&revision=1402709].

> Assembly documentation does not list all supported formats
> --
>
> Key: MASSEMBLY-623
> URL: https://jira.codehaus.org/browse/MASSEMBLY-623
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 2.3
> Environment: Website
>Reporter: Curtis Rueden
>Assignee: Dennis Lundberg
> Fix For: 2.4
>
>
> The assembly plugin supports several different assembly formats. However, the 
> supported formats are enumerated in two different places:
> * On the [front page|http://maven.apache.org/plugins/maven-assembly-plugin/]
> * On the [formats/format element of the assembly descriptor 
> page|http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#assembly].
> These two lists do not match; each has at least one item missing from the 
> other. These lists should be reconciled such that either:
> A) each is a complete listing of all supported formats; or
> B) one says something like "etc." with a link to the other, as a canonical 
> complete listing.
> I would argue that the formats/format section should list all supported 
> types, since the assembly descriptor page is supposed to be a complete 
> technical description of the descriptor format. The listing on the front page 
> could either link to the descriptor page, or else fully recapitulate the 
> listing, as long as new formats supported in the future continue to get added 
> to both.

--
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-864) NPE when unit test loads resources from JAR

2012-10-26 Thread Luke Stevens (JIRA)

[ 
https://jira.codehaus.org/browse/SUREFIRE-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312419#comment-312419
 ] 

Luke Stevens commented on SUREFIRE-864:
---

Wow, that means the JUnit plugin is doing the wrong thing by letting it work. 
Never would have figured that out myself. Thanks for looking into it!

> NPE when unit test loads resources from JAR
> ---
>
> Key: SUREFIRE-864
> URL: https://jira.codehaus.org/browse/SUREFIRE-864
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.9, 2.10, 2.11, 2.12
> Environment: Windows 64-bit, Eclipse Maven plug-in
>Reporter: Luke Stevens
>Assignee: Kristian Rosenvold
> Attachments: TestSurefire.zip
>
>
> I have a unit test that reads resources from a JAR built by another project. 
> This works totally fine when running JUnit within Eclipse. But when building 
> under Maven, it hits an error:
> java.lang.NullPointerException
> at java.io.FilterInputStream.close(FilterInputStream.java:155)
> at 
> sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream.close(JarURLConnection.java:90)
> ...
> Suppressing this error (which occurs on close, after all) only leads to 
> others.
> Some digging reveals that this is probably related to a longstanding 
> classloader bug in the JVM:
> http://stackoverflow.com/questions/3216780/
> A very simple project is attached to demonstrate the problem.

--
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