[jira] (SUREFIRE-864) NPE when unit test loads resources from JAR
[ https://jira.codehaus.org/browse/SUREFIRE-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=312343#comment-312343 ] Luke Stevens commented on SUREFIRE-864: --- I just checked the zip, and it's right; just a resource-only jar with no Java sources (though adding some does not affect the outcome). 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 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] (SUREFIRE-864) NPE when unit test loads resources from JAR
[ 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
[
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=300128page=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 a href=a-powerpoint-file.ppt.htmllink to a file/a
{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
[
https://jira.codehaus.org/browse/MASSEMBLY-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
dependency
groupIdcom.sun.xml.ws/groupId
artifactIdjaxws-rt/artifactId
version2.2.6/version
/dependency
{code}
The assembly descriptor is:
{code:xml}
dependencySet
unpackfalse/unpack
useProjectArtifactfalse/useProjectArtifact
useTransitiveDependenciestrue/useTransitiveDependencies
useTransitiveFilteringfalse/useTransitiveFiltering
includes
include*:jaxws*/include
/includes
/dependencySet
{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
[ https://jira.codehaus.org/browse/SUREFIRE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[ 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
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
[ 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
[ https://jira.codehaus.org/browse/MNG-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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): proxies proxy idoptional/id activetrue/active protocolhttp/protocol username/username password/password hostxxx.xx.xx.xx/host port8080/port nonProxyHostslocalhost|127.0.0.1/nonProxyHosts /proxy /proxies 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 xxx hidden xxx [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 xxx hidden xxx [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
[ https://jira.codehaus.org/browse/MNG-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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): proxies proxy idoptional/id activetrue/active protocolhttp/protocol username/username password/password hostxxx.xx.xx.xx/host port8080/port nonProxyHostslocalhost|127.0.0.1/nonProxyHosts /proxy /proxies 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 xxx hidden xxx [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 xxx hidden xxx [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
[
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}
metadata modelVersion=1.1.0
groupIdcom.ccv.systems.modules.gen_modem/groupId
artifactIdmodem/artifactId
version07.20.3-SNAPSHOT/version
versioning
snapshot
timestamp20120809.112920/timestamp
buildNumber97/buildNumber
/snapshot
lastUpdated20120809112920/lastUpdated
snapshotVersion
classifierclasssifierA/classifier
extensionjar/extension
value07.20.3-20120809.112124-88/value
updated20120809112124/updated
/snapshotVersion
snapshotVersion
classifierclasssifierB/classifier
extensionjar/extension
value07.20.3-20120809.112920-97/value
updated20120809112920/updated
/snapshotVersion
/snapshotVersions
/versioning
/metadata
{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.
[ https://jira.codehaus.org/browse/MNG-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[
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=revisionrevision=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)
at
[jira] (MNG-5324) Incorrect parsing of metadata by Maven: Cannot find snapshot artifact with older timestamp
[
https://jira.codehaus.org/browse/MNG-5324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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=1402675view=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}
metadata modelVersion=1.1.0
groupIdcom.ccv.systems.modules.gen_modem/groupId
artifactIdmodem/artifactId
version07.20.3-SNAPSHOT/version
versioning
snapshot
timestamp20120809.112920/timestamp
buildNumber97/buildNumber
/snapshot
lastUpdated20120809112920/lastUpdated
snapshotVersion
classifierclasssifierA/classifier
extensionjar/extension
value07.20.3-20120809.112124-88/value
updated20120809112124/updated
/snapshotVersion
snapshotVersion
classifierclasssifierB/classifier
extensionjar/extension
value07.20.3-20120809.112920-97/value
updated20120809112920/updated
/snapshotVersion
/snapshotVersions
/versioning
/metadata
{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
[
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}
moduleSet
includes
includecom.example:extra-hiper-app/include
/includes
binaries
outputFileNameMappingmy-app.${extension}/outputFileNameMapping
outputDirectoryoutput/lib/outputDirectory
unpackfalse/unpack
includeDependenciestrue/includeDependencies
dependencySets
dependencySet
outputFileNameMapping${artifactId}-${version}.${extension}/outputFileNameMapping
/dependencySet
/dependencySets
/binaries
/moduleSet
{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:
moduleSet
includes
includecom.example:extra-hiper-app/include
/includes
binaries
outputFileNameMappingmy-app.${extension}/outputFileNameMapping
outputDirectoryoutput/lib/outputDirectory
unpackfalse/unpack
includeDependenciestrue/includeDependencies
dependencySets
dependencySet
outputFileNameMapping${artifactId}-${version}.${extension}/outputFileNameMapping
/dependencySet
/dependencySets
/binaries
/moduleSet
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}
moduleSet
includes
includecom.example:extra-hiper-app/include
/includes
binaries
outputFileNameMappingmy-app.${extension}/outputFileNameMapping
outputDirectoryoutput/lib/outputDirectory
unpackfalse/unpack
includeDependenciestrue/includeDependencies
dependencySets
dependencySet
outputFileNameMapping${artifactId}-${version}.${extension}/outputFileNameMapping
/dependencySet
/dependencySets
/binaries
/moduleSet
{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
[
https://jira.codehaus.org/browse/MASSEMBLY-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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}
moduleSet
includes
includecom.example:extra-hiper-app/include
/includes
binaries
outputFileNameMappingmy-app.${extension}/outputFileNameMapping
outputDirectoryoutput/lib/outputDirectory
unpackfalse/unpack
includeDependenciestrue/includeDependencies
dependencySets
dependencySet
outputFileNameMapping${artifactId}-${version}.${extension}/outputFileNameMapping
/dependencySet
/dependencySets
/binaries
/moduleSet
{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
[ 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
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
[ 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=1402701view=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
[ 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=revisionrevision=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)
[ 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=revisionrevision=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
[ https://jira.codehaus.org/browse/MASSEMBLY-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 plugins in example documentation
[ 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=revisionrevision=1402707]. Missing XML tag plugins 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 plugins between build and plugin 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 formatdir/format
[ 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=revisionrevision=1402709]. Please document formatdir/format 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 - formatdir/format 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
[ 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=revisionrevision=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
[ https://jira.codehaus.org/browse/SUREFIRE-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
