[jira] (MASSEMBLY-576) addClasspath broken in new single goal
[
https://jira.codehaus.org/browse/MASSEMBLY-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312237#comment-312237
]
Dennis Lundberg commented on MASSEMBLY-576:
---
This seems to be a Maven 3 only issue. It works for me with Maven 2.2.1, but
not with 3.0.4.
> addClasspath broken in new single goal
> --
>
> Key: MASSEMBLY-576
> URL: https://jira.codehaus.org/browse/MASSEMBLY-576
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
> Environment: Maven 3.0.3
> Ubuntu 11.04
> Sun java 6 (1.6.0_26)
>Reporter: James Davis
>Priority: Blocker
>
> According to the documentation, using true in
> archive/manifest, should place the generated classpath in to the manifest.
> This works with assembly:assembly (now deprecated), but is broken in
> assembly:single
> Here is my plugin definition section:
> {code:xml}
>
> org.apache.maven.plugins
> maven-assembly-plugin
>
>
> src/main/assembly/assembly.xml
>
>
>
> com.example.Main
> true
> lib/
>
>
>
>
>
> package
>
> single
>
>
>
>
> {code}
> and the custom assembly file:
> {code:xml}
>
> full
>
> jar
>
> false
>
>
> false
> runtime
> true
> lib/
>
>
>
>
> ${project.build.outputDirectory}
> /
>
>
>
> {code}
> I'm not sure if this is just because the documentation does not correctly
> address how to do this or if it is actually just broken. I did check the
> docs and this is how the docs claim you should be able to do this.
--
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-574) includeBaseDirectory is ignored in version 2.2.1
[
https://jira.codehaus.org/browse/MASSEMBLY-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-574:
--
Description:
"includeBaseDirectory" is ignored in 2.2.1, had to revert to 2.2-beta-2 for
this to work
{code:xml}
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
dependencies
jar
false
false
META-INF/spring.handlers
META-INF/spring.schemas
META-INF/spring.tooling
runtime
lib
{code}
was:
"includeBaseDirectory" is ignored in 2.2.1, had to revert to 2.2-beta-2 for
this to work
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
dependencies
jar
false
false
META-INF/spring.handlers
META-INF/spring.schemas
META-INF/spring.tooling
runtime
lib
Affects Version/s: 2.2.1
Summary: includeBaseDirectory is ignored in version 2.2.1 (was:
version 2.2.1 )
> includeBaseDirectory is ignored in version 2.2.1
>
>
> Key: MASSEMBLY-574
> URL: https://jira.codehaus.org/browse/MASSEMBLY-574
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
> Environment: fedora 15, maven 2.2.1
>Reporter: lillian angel
>
> "includeBaseDirectory" is ignored in 2.2.1, had to revert to 2.2-beta-2 for
> this to work
> {code:xml}
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
> http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
> dependencies
>
> jar
>
> false
>
>
> false
>
>
> META-INF/spring.handlers
> META-INF/spring.schemas
> META-INF/spring.tooling
>
>
> runtime
>
>
>
>
> lib
>
>
>
> {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-634) Add Maven version used to Created-By entry in manifest
Dennis Lundberg created MASSEMBLY-634: - Summary: Add Maven version used to Created-By entry in manifest Key: MASSEMBLY-634 URL: https://jira.codehaus.org/browse/MASSEMBLY-634 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Reporter: Dennis Lundberg Upgrade the dependency to org.apache.maven:maven-archiver to version 2.5 to get the version of Maven Core used for building included in the Created-By manifest entry. The call to MavenArchiver also needs to be slightly updated to pass along the MavenSession. -- 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-634) Add Maven version used to Created-By entry in manifest
[ https://jira.codehaus.org/browse/MASSEMBLY-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MASSEMBLY-634: -- Description: In org.apache.maven:maven-archiver:2.5 you can get the version of Maven Core used for building, so that it can be included in the "Created-By" manifest entry. The call to MavenArchiver also needs to be slightly updated to pass along the MavenSession. (was: Upgrade the dependency to org.apache.maven:maven-archiver to version 2.5 to get the version of Maven Core used for building included in the Created-By manifest entry. The call to MavenArchiver also needs to be slightly updated to pass along the MavenSession.) Affects Version/s: 2.3 Fix Version/s: 2.4 Assignee: Dennis Lundberg > Add Maven version used to Created-By entry in manifest > -- > > Key: MASSEMBLY-634 > URL: https://jira.codehaus.org/browse/MASSEMBLY-634 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 2.4 > > > In org.apache.maven:maven-archiver:2.5 you can get the version of Maven Core > used for building, so that it can be included in the "Created-By" manifest > entry. The call to MavenArchiver also needs to be slightly updated to pass > along the MavenSession. -- 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-634) Add Maven version used to Created-By entry in manifest
[ https://jira.codehaus.org/browse/MASSEMBLY-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MASSEMBLY-634. - Resolution: Fixed Fixed in [r1402062|http://svn.apache.org/viewvc?view=revision&revision=1402062]. > Add Maven version used to Created-By entry in manifest > -- > > Key: MASSEMBLY-634 > URL: https://jira.codehaus.org/browse/MASSEMBLY-634 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 2.4 > > > In org.apache.maven:maven-archiver:2.5 you can get the version of Maven Core > used for building, so that it can be included in the "Created-By" manifest > entry. The call to MavenArchiver also needs to be slightly updated to pass > along the MavenSession. -- 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-628) Bogus warning when assembling to a directory
[ https://jira.codehaus.org/browse/MASSEMBLY-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MASSEMBLY-628. - Resolution: Not A Bug > Bogus warning when assembling to a directory > > > Key: MASSEMBLY-628 > URL: https://jira.codehaus.org/browse/MASSEMBLY-628 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: c:\Users\visola\Downloads\springsource\apache-maven-3.0.3 > Java version: 1.6.0_32, vendor: Sun Microsystems Inc. > Java home: c:\Program Files\Java\jdk1.6.0_32\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" > maven-assembly-plugin:2.3 >Reporter: Vinicius Isola > Attachments: test.zip > > > When adding a "dir" format to the assembly file, it will output a bogus > warning like the following: > [WARNING] Assembly file: c:\Users\visola\temp\test\target\test-1.0.0 is not a > regular file (it may be a directory). It cannot be attached to the project > build for installation or deployment. > I think it is related to bug: http://jira.codehaus.org/browse/MASSEMBLY-289 > Attached is an example project that can reproduce the problem just running > "mvn clean install" -- 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 updated MASSEMBLY-626:
--
Description:
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
org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:185)
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:452)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
{noformat}
The relevant bit of the effective POM is pretty simple, but here it is anyway:
{code:xml}
maven-assembly-plugin
2.3
package
single
jar-with-dependencies
[jira] (MASSEMBLY-626) NullPointerException in PlexusIoURLResource.getContents
[
https://jira.codehaus.org/browse/MASSEMBLY-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312288#comment-312288
]
Kristian Rosenvold commented on MASSEMBLY-626:
--
Fixed in plexus-io 2.0.6
> 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
>
> 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
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:185)
> at
> org.apache.maven.plugin.
[jira] (MASSEMBLY-626) NullPointerException in PlexusIoURLResource.getContents
[
https://jira.codehaus.org/browse/MASSEMBLY-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312288#comment-312288
]
Kristian Rosenvold edited comment on MASSEMBLY-626 at 10/25/12 8:41 AM:
Fixed in plexus-io 2.0.6. btw the root cause is some malformedness of a path,
which you will now see!
was (Author: krosenvold):
Fixed in plexus-io 2.0.6
> 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
>
> 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.cr
[jira] (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Latombe updated MSITE-604:
--
Attachment: MSITE-604-it.patch
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Apache Maven 2.2.1 and 3.0.3
>Reporter: Marcin Kuthan
> Fix For: backlog
>
> Attachments: MSITE-604-it.patch, MSITE-604-maven3-2.patch,
> MSITE-604-maven3.patch, MSITE-604.tgz
>
>
> My distribution management section looks like:
> {code}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {code}
> I'm able redefine properties from command line, the provided repository is
> used instead default one:
> {code}
> mvn site:site site:deploy
> -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
> -Dacme-corporate-pom.siteRepositoryId=somehost
> {code}
> But when I redefine properties in the profile in {{settings.xml}}, they are
> ignored. The profile is activated in {{ It looks, than only m-site-p ignores properties defined in the
> {{settings.xml}} file. m-deploy-p recognizes properties as I expected
> (distribution management section for articats deployment is configured in
> similar way to site deployment).
> --
> Marcin Kuthan
> Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
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-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312289#comment-312289
]
Vincent Latombe edited comment on MSITE-604 at 10/25/12 8:46 AM:
-
I've managed to find some time to reproduce the issue, and I have updated the
IT accordingly (see MSITE-604-it.patch).
This IT fails if MSITE-604-maven3-2.patch isn't applied.
Basically, the build will fail if the site url starts with an expression, which
is only defined in settings.xml (not at pom.xml level). Also, it happens if the
site definition is actually done in a parent pom, not in the pom itself.
was (Author: vlatombe):
I've managed to find some time to reproduce the issue, and I have updated
the IT accordingly.
This IT fails if MSITE-604-maven3-2.patch isn't applied.
Basically, the build will fail if the site url starts with an expression, which
is only defined in settings.xml (not at pom.xml level). Also, it happens if the
site definition is actually done in a parent pom, not in the pom itself.
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Apache Maven 2.2.1 and 3.0.3
>Reporter: Marcin Kuthan
> Fix For: backlog
>
> Attachments: MSITE-604-it.patch, MSITE-604-maven3-2.patch,
> MSITE-604-maven3.patch, MSITE-604.tgz
>
>
> My distribution management section looks like:
> {code}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {code}
> I'm able redefine properties from command line, the provided repository is
> used instead default one:
> {code}
> mvn site:site site:deploy
> -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
> -Dacme-corporate-pom.siteRepositoryId=somehost
> {code}
> But when I redefine properties in the profile in {{settings.xml}}, they are
> ignored. The profile is activated in {{ It looks, than only m-site-p ignores properties defined in the
> {{settings.xml}} file. m-deploy-p recognizes properties as I expected
> (distribution management section for articats deployment is configured in
> similar way to site deployment).
> --
> Marcin Kuthan
> Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
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-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312289#comment-312289
]
Vincent Latombe commented on MSITE-604:
---
I've managed to find some time to reproduce the issue, and I have updated the
IT accordingly.
This IT fails if MSITE-604-maven3-2.patch isn't applied.
Basically, the build will fail if the site url starts with an expression, which
is only defined in settings.xml (not at pom.xml level). Also, it happens if the
site definition is actually done in a parent pom, not in the pom itself.
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Apache Maven 2.2.1 and 3.0.3
>Reporter: Marcin Kuthan
> Fix For: backlog
>
> Attachments: MSITE-604-it.patch, MSITE-604-maven3-2.patch,
> MSITE-604-maven3.patch, MSITE-604.tgz
>
>
> My distribution management section looks like:
> {code}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {code}
> I'm able redefine properties from command line, the provided repository is
> used instead default one:
> {code}
> mvn site:site site:deploy
> -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
> -Dacme-corporate-pom.siteRepositoryId=somehost
> {code}
> But when I redefine properties in the profile in {{settings.xml}}, they are
> ignored. The profile is activated in {{ It looks, than only m-site-p ignores properties defined in the
> {{settings.xml}} file. m-deploy-p recognizes properties as I expected
> (distribution management section for articats deployment is configured in
> similar way to site deployment).
> --
> Marcin Kuthan
> Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
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-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312291#comment-312291
]
Vincent Latombe commented on MSITE-604:
---
I managed to do some additional tests, and it seems that my patch also fixes
MSITE-632. I'm able to redefine distributionManagement in my child module and
it overrides correctly the entry declared in the parent POM.
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Apache Maven 2.2.1 and 3.0.3
>Reporter: Marcin Kuthan
> Fix For: backlog
>
> Attachments: MSITE-604-it.patch, MSITE-604-maven3-2.patch,
> MSITE-604-maven3.patch, MSITE-604.tgz
>
>
> My distribution management section looks like:
> {code}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {code}
> I'm able redefine properties from command line, the provided repository is
> used instead default one:
> {code}
> mvn site:site site:deploy
> -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
> -Dacme-corporate-pom.siteRepositoryId=somehost
> {code}
> But when I redefine properties in the profile in {{settings.xml}}, they are
> ignored. The profile is activated in {{ It looks, than only m-site-p ignores properties defined in the
> {{settings.xml}} file. m-deploy-p recognizes properties as I expected
> (distribution management section for articats deployment is configured in
> similar way to site deployment).
> --
> Marcin Kuthan
> Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
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-5362) Option to always download SNAPSHOT from remote repo
Venkata created MNG-5362: Summary: Option to always download SNAPSHOT from remote repo Key: MNG-5362 URL: https://jira.codehaus.org/browse/MNG-5362 Project: Maven 2 & 3 Issue Type: Improvement Reporter: Venkata Priority: Critical It should be possible for a project to always download a remote SNAPSHOT artifact when mentioned as part of the dependency. Consider our scenario, where we have two projects - projA and projB, projA depends on projB - under active development. CI Builds happen on a cluster of 4 servers. ProjB ends up throwing errors very frequently because latest of ProjA would have been compiled on a different server than ProjB. For organizational reasons, we cannot make our Artifactory repo to use 'Nonunique snapshots', i.e. we need the artifact name to be same for each update in Maven repo. I am pretty sure that many people out there have been facing the same issue. There are other solutions, but all of them are equally frustrating. It would be nice to have an updatePolicy of 'force' or something which will always reach out to latest snapshot version. Thanks. -- 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-634) Add Maven version used to Created-By entry in manifest
[ https://jira.codehaus.org/browse/MASSEMBLY-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312295#comment-312295 ] Anders Hammar commented on MASSEMBLY-634: - Ah, awesome! > Add Maven version used to Created-By entry in manifest > -- > > Key: MASSEMBLY-634 > URL: https://jira.codehaus.org/browse/MASSEMBLY-634 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 2.4 > > > In org.apache.maven:maven-archiver:2.5 you can get the version of Maven Core > used for building, so that it can be included in the "Created-By" manifest > entry. The call to MavenArchiver also needs to be slightly updated to pass > along the MavenSession. -- 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-5362) Option to always download SNAPSHOT from remote repo
[ https://jira.codehaus.org/browse/MNG-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar updated MNG-5362: --- Priority: Major (was: Critical) Lowering priority. I don't follow, could you please explain what solutions you've tried that are frustrating. Also, you say you cannot use "nonunique" snapshots as they name needs to be the same over builds. Don't you mean that cannot use UNIQUE (timestamped) snapshots? > Option to always download SNAPSHOT from remote repo > --- > > Key: MNG-5362 > URL: https://jira.codehaus.org/browse/MNG-5362 > Project: Maven 2 & 3 > Issue Type: Improvement >Reporter: Venkata > > It should be possible for a project to always download a remote SNAPSHOT > artifact when mentioned as part of the dependency. > Consider our scenario, where we have two projects - projA and projB, projA > depends on projB - under active development. > CI Builds happen on a cluster of 4 servers. ProjB ends up throwing errors > very frequently because latest of ProjA would have been compiled on a > different server than ProjB. > For organizational reasons, we cannot make our Artifactory repo to use > 'Nonunique snapshots', i.e. we need the artifact name to be same for each > update in Maven repo. > I am pretty sure that many people out there have been facing the same issue. > There are other solutions, but all of them are equally frustrating. > It would be nice to have an updatePolicy of 'force' or something which will > always reach out to latest snapshot version. > Thanks. -- 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-5362) Option to always download SNAPSHOT from remote repo
[ https://jira.codehaus.org/browse/MNG-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312297#comment-312297 ] Venkata commented on MNG-5362: -- Hi Anders, Thanks for response. I meant 'unique' where I said 'nonunique'. If possible, please edit it (I do not seem to have privileges). Following are the solution I have tried: 1. -U flag. It is still at the mercy of Maven ascertaining that there is a new update available. 2. I have considered using cron, but we have a combination of windows and Linux build boxes. Also, developers are using Windows boxes. We can put in a 'process' for a mechanical activity. 3. Currently, I have all the build happening on a single server, which kind of becomes a bottleneck 4. Developers frequently give me the 'Works on my workstation' and they cannot be questioned because they may be right (mitigated to a large extent by #3, but still frustrating). 5. Currently, I am trying to put in 'purge-local-repo' into each build we have, but still will be painful because we have to enable each maven build and each build will go crazy downloading files after that. Also, it will cause issues when two builds are triggered with common dependencies. They WILL delete files needed by each other, producing inconsistent build breakages. These are probably the biggest pain points. > Option to always download SNAPSHOT from remote repo > --- > > Key: MNG-5362 > URL: https://jira.codehaus.org/browse/MNG-5362 > Project: Maven 2 & 3 > Issue Type: Improvement >Reporter: Venkata > > It should be possible for a project to always download a remote SNAPSHOT > artifact when mentioned as part of the dependency. > Consider our scenario, where we have two projects - projA and projB, projA > depends on projB - under active development. > CI Builds happen on a cluster of 4 servers. ProjB ends up throwing errors > very frequently because latest of ProjA would have been compiled on a > different server than ProjB. > For organizational reasons, we cannot make our Artifactory repo to use > 'Nonunique snapshots', i.e. we need the artifact name to be same for each > update in Maven repo. > I am pretty sure that many people out there have been facing the same issue. > There are other solutions, but all of them are equally frustrating. > It would be nice to have an updatePolicy of 'force' or something which will > always reach out to latest snapshot version. > Thanks. -- 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-5362) Option to always download SNAPSHOT from remote repo
[ https://jira.codehaus.org/browse/MNG-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312300#comment-312300 ] Venkata commented on MNG-5362: -- And of course, from a possibility stand-point, it seems logical to have 'force' or 'ignore-local-copy', at least for snapshots. I definitely believe that released artifacts should not need this. > Option to always download SNAPSHOT from remote repo > --- > > Key: MNG-5362 > URL: https://jira.codehaus.org/browse/MNG-5362 > Project: Maven 2 & 3 > Issue Type: Improvement >Reporter: Venkata > > It should be possible for a project to always download a remote SNAPSHOT > artifact when mentioned as part of the dependency. > Consider our scenario, where we have two projects - projA and projB, projA > depends on projB - under active development. > CI Builds happen on a cluster of 4 servers. ProjB ends up throwing errors > very frequently because latest of ProjA would have been compiled on a > different server than ProjB. > For organizational reasons, we cannot make our Artifactory repo to use > 'Nonunique snapshots', i.e. we need the artifact name to be same for each > update in Maven repo. > I am pretty sure that many people out there have been facing the same issue. > There are other solutions, but all of them are equally frustrating. > It would be nice to have an updatePolicy of 'force' or something which will > always reach out to latest snapshot version. > Thanks. -- 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-5362) Option to always download SNAPSHOT from remote repo
[ https://jira.codehaus.org/browse/MNG-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar updated MNG-5362: --- Priority: Minor (was: Major) I believe that "-U" should work here or configuring updatePolicy to "always" for the repo. BUT, as you're using nonunique snapshots this might not work. However, unique snapshots is the supported way in Maven 3 so I would vote closing this ticket as won't fix. Lowering priority for now. Any other ASF Maven project member may close the ticket if he/she thinks the same. I suggest you look into using unique snapshots which will most likely solve you problems. > Option to always download SNAPSHOT from remote repo > --- > > Key: MNG-5362 > URL: https://jira.codehaus.org/browse/MNG-5362 > Project: Maven 2 & 3 > Issue Type: Improvement >Reporter: Venkata >Priority: Minor > > It should be possible for a project to always download a remote SNAPSHOT > artifact when mentioned as part of the dependency. > Consider our scenario, where we have two projects - projA and projB, projA > depends on projB - under active development. > CI Builds happen on a cluster of 4 servers. ProjB ends up throwing errors > very frequently because latest of ProjA would have been compiled on a > different server than ProjB. > For organizational reasons, we cannot make our Artifactory repo to use > 'Nonunique snapshots', i.e. we need the artifact name to be same for each > update in Maven repo. > I am pretty sure that many people out there have been facing the same issue. > There are other solutions, but all of them are equally frustrating. > It would be nice to have an updatePolicy of 'force' or something which will > always reach out to latest snapshot version. > Thanks. -- 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-5362) Option to always download SNAPSHOT from remote repo
[ https://jira.codehaus.org/browse/MNG-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312302#comment-312302 ] Anders Hammar commented on MNG-5362: Just to add, the "-U" flag should force and if you would provide a patch (including ITs) solving any current issues with non-unique snapshots it could be added. But, unique snapshots is the way forward IMO. > Option to always download SNAPSHOT from remote repo > --- > > Key: MNG-5362 > URL: https://jira.codehaus.org/browse/MNG-5362 > Project: Maven 2 & 3 > Issue Type: Improvement >Reporter: Venkata >Priority: Minor > > It should be possible for a project to always download a remote SNAPSHOT > artifact when mentioned as part of the dependency. > Consider our scenario, where we have two projects - projA and projB, projA > depends on projB - under active development. > CI Builds happen on a cluster of 4 servers. ProjB ends up throwing errors > very frequently because latest of ProjA would have been compiled on a > different server than ProjB. > For organizational reasons, we cannot make our Artifactory repo to use > 'Nonunique snapshots', i.e. we need the artifact name to be same for each > update in Maven repo. > I am pretty sure that many people out there have been facing the same issue. > There are other solutions, but all of them are equally frustrating. > It would be nice to have an updatePolicy of 'force' or something which will > always reach out to latest snapshot version. > Thanks. -- 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-915) runOrder=failedfirst runs new tests last
[ https://jira.codehaus.org/browse/SUREFIRE-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-915. --- Resolution: Fixed Fix Version/s: 2.13 Assignee: Kristian Rosenvold Fixed in 531826a77fa977e54f8c7e28606cd5609e67868c, thanks for the excellent patch ! > runOrder=failedfirst runs new tests last > > > Key: SUREFIRE-915 > URL: https://jira.codehaus.org/browse/SUREFIRE-915 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.12.3 >Reporter: Takeji Naigeon >Assignee: Kristian Rosenvold > Fix For: 2.13 > > Attachments: maven_surefire-fix.patch > > -- 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] [Created] (MPOM-38) Enable RAT to help us get maven releases to be license-header compliant
Benson Margulies created MPOM-38: Summary: Enable RAT to help us get maven releases to be license-header compliant Key: MPOM-38 URL: https://issues.apache.org/jira/browse/MPOM-38 Project: Maven POMs Issue Type: Bug Components: maven Affects Versions: MAVEN-21 Reporter: Benson Margulies Assignee: Benson Margulies We should run rat, at least in report mode, to help us get releases into compliance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MPOM-38) Enable RAT to help us get maven releases to be license-header compliant
[ https://issues.apache.org/jira/browse/MPOM-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MPOM-38: - Description: We should run rat, at least in report mode, to help us get releases into compliance. While I am here, I propose to 'useReleaseProfiles' when running the maven-release-plugin. was:We should run rat, at least in report mode, to help us get releases into compliance. > Enable RAT to help us get maven releases to be license-header compliant > --- > > Key: MPOM-38 > URL: https://issues.apache.org/jira/browse/MPOM-38 > Project: Maven POMs > Issue Type: Bug > Components: maven >Affects Versions: MAVEN-21 >Reporter: Benson Margulies >Assignee: Benson Margulies > Attachments: MPOM-38.diff > > > We should run rat, at least in report mode, to help us get releases into > compliance. > While I am here, I propose to 'useReleaseProfiles' when running the > maven-release-plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MPOM-38) Enable RAT to help us get maven releases to be license-header compliant
[ https://issues.apache.org/jira/browse/MPOM-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MPOM-38: - Attachment: MPOM-38.diff This is here for people to throw darts at. > Enable RAT to help us get maven releases to be license-header compliant > --- > > Key: MPOM-38 > URL: https://issues.apache.org/jira/browse/MPOM-38 > Project: Maven POMs > Issue Type: Bug > Components: maven >Affects Versions: MAVEN-21 >Reporter: Benson Margulies >Assignee: Benson Margulies > Attachments: MPOM-38.diff > > > We should run rat, at least in report mode, to help us get releases into > compliance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5362) Option to always download SNAPSHOT from remote repo
[ https://jira.codehaus.org/browse/MNG-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312321#comment-312321 ] Venkata commented on MNG-5362: -- On initial analysis, it seems that most of this code comes from Aether in Maven 3. Logged a bug with Aether with eclipse bugzilla as Aether is now a part of eclipse foundation. Reference: https://bugs.eclipse.org/bugs/show_bug.cgi?id=392864 Regards > Option to always download SNAPSHOT from remote repo > --- > > Key: MNG-5362 > URL: https://jira.codehaus.org/browse/MNG-5362 > Project: Maven 2 & 3 > Issue Type: Improvement >Reporter: Venkata >Priority: Minor > > It should be possible for a project to always download a remote SNAPSHOT > artifact when mentioned as part of the dependency. > Consider our scenario, where we have two projects - projA and projB, projA > depends on projB - under active development. > CI Builds happen on a cluster of 4 servers. ProjB ends up throwing errors > very frequently because latest of ProjA would have been compiled on a > different server than ProjB. > For organizational reasons, we cannot make our Artifactory repo to use > 'Nonunique snapshots', i.e. we need the artifact name to be same for each > update in Maven repo. > I am pretty sure that many people out there have been facing the same issue. > There are other solutions, but all of them are equally frustrating. > It would be nice to have an updatePolicy of 'force' or something which will > always reach out to latest snapshot version. > Thanks. -- 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] (SCM-697) git add fail on windows when a lot of files to add
[ https://jira.codehaus.org/browse/SCM-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hobson closed SCM-697. --- Resolution: Fixed Removed previous batch file workaround since this still suffers from the line limit of 8191 characters. Instead, added files one by one when on Windows. > git add fail on windows when a lot of files to add > -- > > Key: SCM-697 > URL: https://jira.codehaus.org/browse/SCM-697 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.8 > Environment: windows >Reporter: Olivier Lamy >Assignee: Mark Hobson > Fix For: 1.9 > > -- 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] (MSCMPUB-2) publish-scm can fail with many files on windows.
[
https://jira.codehaus.org/browse/MSCMPUB-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hobson closed MSCMPUB-2.
-
Resolution: Fixed
Fixed by SCM-697.
> publish-scm can fail with many files on windows.
>
>
> Key: MSCMPUB-2
> URL: https://jira.codehaus.org/browse/MSCMPUB-2
> Project: maven-scm-publish-plugin
> Issue Type: Bug
> Environment: Cygwin, Windows
>Reporter: Mark Hobson
>Assignee: Mark Hobson
>
> Running publish-scm with a large site can cause the command process to fail
> due to the command line being too long. For example:
> {noformat}
> [INFO] --- maven-scm-publish-plugin:1.0-beta-1:publish-scm (scm-publish) @ X
> ---
> ...
> [INFO] Executing: cmd.exe /X /C "git add -- "
> {noformat}
> Results in:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
> (scm-publish) on project X: Failed to add new files to SCM: Exception while
> executing SCM command. Error while executing command. Error while executing
> process. Cannot run program "cmd.exe" (in directory X): CreateProcess
> error=206, The filename or extension is too long -> [Help 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] (MNG-5363) Regression for SSLv3
James Kionka created MNG-5363: - Summary: Regression for SSLv3 Key: MNG-5363 URL: https://jira.codehaus.org/browse/MNG-5363 Project: Maven 2 & 3 Issue Type: Bug Components: Errors Affects Versions: 3.0.4 Environment: Operation system independent, but tested on Macbook Pro with 10.6 and Red Hat Enterprise Linux 6 on a virtual machine. Reporter: James Kionka When attempting to access a Maven repository which uses SSLv3, you get the following error, "javax.net.ssl.SSLException: Received fatal alert: bad_record_mac". Earlier versions of Maven used java.net.URLConnection which respects the https.protocols system property. This allowed us to set it to SSLv3, which is what our Maven repository uses. However, HttpClient ignores that property. In other situations, we programmatically tell HttpClient to use SSLv3, which we cannot do from our end. You can find another person in the same situation here: http://stackoverflow.com/questions/12787657/received-fatal-alert-bad-record-mac-when-deploying-to-sonatype -- 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-1012) with only doesn't work
[ https://jira.codehaus.org/browse/MNG-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312329#comment-312329 ] Hendy Irawan commented on MNG-1012: --- I agree with David. As it stands now, it's pretty annoying and unnecessary. The Parent POM coordinates are only used in repositories, but not in project *builds*. Please distinguish those two use cases. > with only doesn't work > -- > > Key: MNG-1012 > URL: https://jira.codehaus.org/browse/MNG-1012 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.0-beta-1 >Reporter: Hao Chen > > Use the following in child pom.xml > > ../pom.xml > > Got error: > [INFO] Reason: Missing groupId element from parent element > Why do we need groupId, artifactId, and version? These data are already > contained in ../pom.xml. It should work the same as Maven 1.0 . -- 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-1012) with only doesn't work
[ https://jira.codehaus.org/browse/MNG-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312329#comment-312329 ] Hendy Irawan edited comment on MNG-1012 at 10/25/12 4:29 PM: - I agree with David. As it stands now (Maven 3.0), it's pretty annoying and unnecessary. The Parent POM coordinates are only used in repositories, but not in project *builds*. Please distinguish those two use cases. was (Author: ceefour): I agree with David. As it stands now, it's pretty annoying and unnecessary. The Parent POM coordinates are only used in repositories, but not in project *builds*. Please distinguish those two use cases. > with only doesn't work > -- > > Key: MNG-1012 > URL: https://jira.codehaus.org/browse/MNG-1012 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.0-beta-1 >Reporter: Hao Chen > > Use the following in child pom.xml > > ../pom.xml > > Got error: > [INFO] Reason: Missing groupId element from parent element > Why do we need groupId, artifactId, and version? These data are already > contained in ../pom.xml. It should work the same as Maven 1.0 . -- 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-5364) Document known Bad Practices with suggested alternatives
Barrie Treloar created MNG-5364:
---
Summary: Document known Bad Practices with suggested alternatives
Key: MNG-5364
URL: https://jira.codehaus.org/browse/MNG-5364
Project: Maven 2 & 3
Issue Type: Bug
Components: Documentation: General
Reporter: Barrie Treloar
See http://maven.40175.n5.nabble.com/Repository-Order-tp5727834p5728010.html
There are probably a bunch more.
* repository in pom
* Using ${pom.version} in dependencyManagement
* Other enforcer rules?
* etc
These should be baked into Maven to warn that the practice is not recommended
and to link to where the discussion is on what the preferred alternative is.
--
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-tabpanel&focusedCommentId=312340#comment-312340 ] Kristian Rosenvold commented on SUREFIRE-864: - The sample project seems to be missing the source for TestSurefireLib, any chance you have that ? (Sorry about the delay...) > 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-882) Fork x parallel JVMs once
[ https://jira.codehaus.org/browse/SUREFIRE-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312341#comment-312341 ] Kristian Rosenvold commented on SUREFIRE-882: - I think the flag we'd be looking for is reusableForks=true/false ;) > Fork x parallel JVMs once > - > > Key: SUREFIRE-882 > URL: https://jira.codehaus.org/browse/SUREFIRE-882 > Project: Maven Surefire > Issue Type: New Feature > Components: process forking >Affects Versions: 2.12 >Reporter: Falko Modler > > In 2.12 a new forkMode "perthread" was introduced, which (in conjunction with > parallel!=none) behaves like a parallel "always"-forkMode. > So for instance parallel=classes and forkMode=perthread fork x JVMs in > parallel, whereas each JVM executes just one(!) test class and then > terminates. > It would come in handy if there was another new forkMode (like > "perthreadOnce" or similar) which forks x JVMs that keep on executing test > classes (parallel=classes) until there are no more test-classes left to > execute. > Example (all with parallel=classes and threadCount=2) with 4 test classes > (Test1-4): > perthread: > JVM1 is forked for Test1 > JVM2 is forked for Test2 > JVM1 for Test1 terminates > JVM2 for Test2 terminates > JVM3 is forked for Test3 > JVM4 is forked for Test4 > JVM4 for Test3 terminates > JVM3 for Test3 terminates > perthreadOnce (or the like): > JVM1 is forked, executes Test1 > JVM2 is forked, executes Test2 > JVM1 executes Test3 > JVM2 executes Test4 > JVM1 terminates > JVM2 terminates > In reality, the order of events can differ of course. -- 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-tabpanel&focusedCommentId=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
