[jira] (MSHARED-295) Non reliable killing of processes by CommandLineUtils
[ https://jira.codehaus.org/browse/MSHARED-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332601#comment-332601 ] Kristian Rosenvold commented on MSHARED-295: I have no problem with going platform specific like JNI or forking a shell command as long as it just works. But I don't think we want JNA as a dependency here. This does not sound like an extension point we really want. If you make a patch I'll review it :) Non reliable killing of processes by CommandLineUtils - Key: MSHARED-295 URL: https://jira.codehaus.org/browse/MSHARED-295 Project: Maven Shared Components Issue Type: Improvement Components: maven-shared-utils Reporter: Andrey Klochkov CommandLineUtils is used in Maven-Surefire to start forks which execute tests. It is a well known issue that sometimes child processes are not killed correctly. This is a known limitation of JVM, and the only reliable way to implement it would be platform specific. Bug report in Surefire JIRA: http://jira.codehaus.org/browse/SUREFIRE-773 JVM bug report. It's Windows specific, but the problem exists on Linux and OSX as well. http://bugs.sun.com/view_bug.do?bug_id=4770092 I'm proposing either 1) to implement several platform specific implementations of ProcessHook or 2) to make the mechanism of killing processes extendable for clients of the library. -- 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] (MSHARED-295) Non reliable killing of processes by CommandLineUtils
[ https://jira.codehaus.org/browse/MSHARED-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332602#comment-332602 ] Milos Kleint commented on MSHARED-295: -- I'm sure jenkins is already doing something in this area? Non reliable killing of processes by CommandLineUtils - Key: MSHARED-295 URL: https://jira.codehaus.org/browse/MSHARED-295 Project: Maven Shared Components Issue Type: Improvement Components: maven-shared-utils Reporter: Andrey Klochkov CommandLineUtils is used in Maven-Surefire to start forks which execute tests. It is a well known issue that sometimes child processes are not killed correctly. This is a known limitation of JVM, and the only reliable way to implement it would be platform specific. Bug report in Surefire JIRA: http://jira.codehaus.org/browse/SUREFIRE-773 JVM bug report. It's Windows specific, but the problem exists on Linux and OSX as well. http://bugs.sun.com/view_bug.do?bug_id=4770092 I'm proposing either 1) to implement several platform specific implementations of ProcessHook or 2) to make the mechanism of killing processes extendable for clients of the library. -- 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] (SCM-731) [PATCH] port maven-scm to latest version of plexus-container-default
[ https://jira.codehaus.org/browse/SCM-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332604#comment-332604 ] Mat Booth commented on SCM-731: --- Yes, it does. [PATCH] port maven-scm to latest version of plexus-container-default Key: SCM-731 URL: https://jira.codehaus.org/browse/SCM-731 Project: Maven SCM Issue Type: Improvement Components: maven-scm-client Affects Versions: 1.8.1 Reporter: Mat Booth Assignee: Olivier Lamy Attachments: 0001-ensure-compatibility-with-newer-versions-of-plexus-c.patch, 0001-port-maven-scm-to-latest-version-of-plexus-default-c.patch In the client module, the org.codehaus.plexus.embed.Embedder is used. This class was deprecated and removed in future versions of plexus-container-default. In order to build maven-scm against the latest version of plexus-container-default, as we must for inclusion in Fedora Linux for example, a smallish patch must be applied. Please see the attached. The patch removes use of the org.codehaus.plexus.embed.Embedder class, ports all unit tests to latest container and builds the maven-plugin with a newer version of maven. The patch was made against the current svn trunk/git master. All unit tests continue to pass and the command line client still functions normally. Thanks for your time. Edit: Please see the later patch! 0001-port-maven-scm-to-latest-version-of-plexus-default-c.patch -- 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] (MSHARED-295) Non reliable killing of processes by CommandLineUtils
[ https://jira.codehaus.org/browse/MSHARED-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332606#comment-332606 ] Kristian Rosenvold commented on MSHARED-295: And selenium uses JNA on windows and also shells to kill on linux. Killing firefox cross platform turns out to be one of the hardest problems in computer science. That stuff about P and NP is just kids stuff compared. Non reliable killing of processes by CommandLineUtils - Key: MSHARED-295 URL: https://jira.codehaus.org/browse/MSHARED-295 Project: Maven Shared Components Issue Type: Improvement Components: maven-shared-utils Reporter: Andrey Klochkov CommandLineUtils is used in Maven-Surefire to start forks which execute tests. It is a well known issue that sometimes child processes are not killed correctly. This is a known limitation of JVM, and the only reliable way to implement it would be platform specific. Bug report in Surefire JIRA: http://jira.codehaus.org/browse/SUREFIRE-773 JVM bug report. It's Windows specific, but the problem exists on Linux and OSX as well. http://bugs.sun.com/view_bug.do?bug_id=4770092 I'm proposing either 1) to implement several platform specific implementations of ProcessHook or 2) to make the mechanism of killing processes extendable for clients of the library. -- 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] (MDEPLOY-157) Add deployAtEnd option for multimodule projects
[ https://jira.codehaus.org/browse/MDEPLOY-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332612#comment-332612 ] Dominik Bartholdi edited comment on MDEPLOY-157 at 9/10/13 8:17 AM: when will version 2.8 finally be released? MINSTALL-93 (installAtEnd for maven-install-plugin:2.5) has just been released, but it actully only makes sense if the deploy plugin is available with the same feature. was (Author: domi): when will version 2.8 finally be released? MINSTALL-93 (deployAtEnd for maven-install-plugin:2.5) has just been released, but it actully only makes sense if the deploy plugin is available with the same feature. Add deployAtEnd option for multimodule projects --- Key: MDEPLOY-157 URL: https://jira.codehaus.org/browse/MDEPLOY-157 Project: Maven Deploy Plugin Issue Type: New Feature Components: deploy:deploy Affects Versions: 2.7 Reporter: Robert Scholte Assignee: Robert Scholte Fix For: 2.8 With this option it will be possible to only deploy artifacts if all have been succesfully installed. See MRELEASE-664 for further details. -- 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] (MDEPLOY-157) Add deployAtEnd option for multimodule projects
[ https://jira.codehaus.org/browse/MDEPLOY-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332612#comment-332612 ] Dominik Bartholdi commented on MDEPLOY-157: --- when will version 2.8 finally be released? MINSTALL-93 (deployAtEnd for maven-install-plugin:2.5) has just been released, but it actully only makes sense if the deploy plugin is available with the same feature. Add deployAtEnd option for multimodule projects --- Key: MDEPLOY-157 URL: https://jira.codehaus.org/browse/MDEPLOY-157 Project: Maven Deploy Plugin Issue Type: New Feature Components: deploy:deploy Affects Versions: 2.7 Reporter: Robert Scholte Assignee: Robert Scholte Fix For: 2.8 With this option it will be possible to only deploy artifacts if all have been succesfully installed. See MRELEASE-664 for further details. -- 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] (MDEPLOY-164) Mirrors defined in settings.xml should be used to upload artifacts
Rémi Alvergnat created MDEPLOY-164: -- Summary: Mirrors defined in settings.xml should be used to upload artifacts Key: MDEPLOY-164 URL: https://jira.codehaus.org/browse/MDEPLOY-164 Project: Maven Deploy Plugin Issue Type: Improvement Components: deploy:deploy, deploy:deploy-file Affects Versions: 2.7 Environment: Maven 3.1.0, Maven 3.0.5, Windows Reporter: Rémi Alvergnat Priority: Minor When a mirror is defined in maven settings.xml for a repository declared in distributionManagement, upload of artifacts should be done using the mirror URL, instead of original URL from the repository. -- 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] (MSHADE-156) shade plugin is transforming also strings that are not supposed to be transformed
[
https://jira.codehaus.org/browse/MSHADE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neeme Praks updated MSHADE-156:
---
Description:
I'm shading several third party libraries into a single JAR. In the context of
this issue, there are two important libraries:
1. com.nothome:javaxdelta:2.0.1 - this library is in at.spardat.xma.xdelta
package.
2. ch.qos.logback:logback-classic:1.0.11 - in this library, in class
ch.qos.logback.classic.spi.StackTraceElementProxy, there is a method to convert
stack trace elements into strings:
{code}
public String getSTEAsString() {
if (steAsString == null) {
steAsString = at + ste.toString();
}
return steAsString;
}
{code}
I use org.myorgname.appname.shaded package for shading.
During shading, the constant at is replaced with
org.myorgname.appname.shaded.at -- shade plugin thinks that the at in the
beginning of that string is a package name and shades it.
This results in an unfortunate side-effect: all logged stack traces now look
like this:
{noformat}
Caused by: java.util.zip.ZipException: error in opening zip file
org.myorgname.appname.shaded.at java.util.zip.ZipFile.open(Native
Method) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:114) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:131) ~[na:1.6.0_19]
{noformat}
was:
I'm shading several third party libraries into a single JAR. In the context of
this issue, there are two important libraries:
1. com.nothome:javaxdelta:2.0.1 - this library is in at.spardat.xma.xdelta
package.
2. ch.qos.logback:logback-classic:1.0.11 - in this library, in class
ch.qos.logback.classic.spi.StackTraceElementProxy, there is a method to convert
stack trace elements into strings:
public String getSTEAsString() {
if (steAsString == null) {
steAsString = at + ste.toString();
}
return steAsString;
}
I use org.myorgname.appname.shaded package for shading.
During shading, the constant at is replaced with
org.myorgname.appname.shaded.at -- shade plugin thinks that the at in the
beginning of that string is a package name and shades it.
This results in an unfortunate side-effect: all logged stack traces now look
like this:
{noformat}
Caused by: java.util.zip.ZipException: error in opening zip file
org.myorgname.appname.shaded.at java.util.zip.ZipFile.open(Native
Method) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:114) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:131) ~[na:1.6.0_19]
{noformat}
shade plugin is transforming also strings that are not supposed to be
transformed
-
Key: MSHADE-156
URL: https://jira.codehaus.org/browse/MSHADE-156
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Neeme Praks
I'm shading several third party libraries into a single JAR. In the context
of this issue, there are two important libraries:
1. com.nothome:javaxdelta:2.0.1 - this library is in at.spardat.xma.xdelta
package.
2. ch.qos.logback:logback-classic:1.0.11 - in this library, in class
ch.qos.logback.classic.spi.StackTraceElementProxy, there is a method to
convert stack trace elements into strings:
{code}
public String getSTEAsString() {
if (steAsString == null) {
steAsString = at + ste.toString();
}
return steAsString;
}
{code}
I use org.myorgname.appname.shaded package for shading.
During shading, the constant at is replaced with
org.myorgname.appname.shaded.at -- shade plugin thinks that the at in the
beginning of that string is a package name and shades it.
This results in an unfortunate side-effect: all logged stack traces now look
like this:
{noformat}
Caused by: java.util.zip.ZipException: error in opening zip file
org.myorgname.appname.shaded.at java.util.zip.ZipFile.open(Native
Method) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:114) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:131) ~[na:1.6.0_19]
{noformat}
--
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] (MSHADE-156) shade plugin is transforming also strings that are not supposed to be transformed
[
https://jira.codehaus.org/browse/MSHADE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neeme Praks updated MSHADE-156:
---
Description:
I'm shading several third party libraries into a single JAR. In the context of
this issue, there are two important libraries:
1. com.nothome:javaxdelta:2.0.1 - this library is in at.spardat.xma.xdelta
package.
2. ch.qos.logback:logback-classic:1.0.11 - in this library, in class
ch.qos.logback.classic.spi.StackTraceElementProxy, there is a method to convert
stack trace elements into strings:
{code}
public String getSTEAsString() {
if (steAsString == null) {
steAsString = at + ste.toString();
}
return steAsString;
}
{code}
I use org.myorgname.appname.shaded package for shading.
During shading, the constant at is replaced with
org.myorgname.appname.shaded.at -- shade plugin thinks that the at in the
beginning of that string is a package name and shades it.
This results in an unfortunate side-effect: all logged stack traces now look
like this:
{noformat}
Caused by: java.util.zip.ZipException: error in opening zip file
org.myorgname.appname.shaded.at java.util.zip.ZipFile.open(Native
Method) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:114) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:131) ~[na:1.6.0_19]
{noformat}
Possible fix: instead of just checking the first part of the package (at),
check for the full package (at.spardat.xma.xdelta).
was:
I'm shading several third party libraries into a single JAR. In the context of
this issue, there are two important libraries:
1. com.nothome:javaxdelta:2.0.1 - this library is in at.spardat.xma.xdelta
package.
2. ch.qos.logback:logback-classic:1.0.11 - in this library, in class
ch.qos.logback.classic.spi.StackTraceElementProxy, there is a method to convert
stack trace elements into strings:
{code}
public String getSTEAsString() {
if (steAsString == null) {
steAsString = at + ste.toString();
}
return steAsString;
}
{code}
I use org.myorgname.appname.shaded package for shading.
During shading, the constant at is replaced with
org.myorgname.appname.shaded.at -- shade plugin thinks that the at in the
beginning of that string is a package name and shades it.
This results in an unfortunate side-effect: all logged stack traces now look
like this:
{noformat}
Caused by: java.util.zip.ZipException: error in opening zip file
org.myorgname.appname.shaded.at java.util.zip.ZipFile.open(Native
Method) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:114) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:131) ~[na:1.6.0_19]
{noformat}
shade plugin is transforming also strings that are not supposed to be
transformed
-
Key: MSHADE-156
URL: https://jira.codehaus.org/browse/MSHADE-156
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Neeme Praks
I'm shading several third party libraries into a single JAR. In the context
of this issue, there are two important libraries:
1. com.nothome:javaxdelta:2.0.1 - this library is in at.spardat.xma.xdelta
package.
2. ch.qos.logback:logback-classic:1.0.11 - in this library, in class
ch.qos.logback.classic.spi.StackTraceElementProxy, there is a method to
convert stack trace elements into strings:
{code}
public String getSTEAsString() {
if (steAsString == null) {
steAsString = at + ste.toString();
}
return steAsString;
}
{code}
I use org.myorgname.appname.shaded package for shading.
During shading, the constant at is replaced with
org.myorgname.appname.shaded.at -- shade plugin thinks that the at in the
beginning of that string is a package name and shades it.
This results in an unfortunate side-effect: all logged stack traces now look
like this:
{noformat}
Caused by: java.util.zip.ZipException: error in opening zip file
org.myorgname.appname.shaded.at java.util.zip.ZipFile.open(Native
Method) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:114) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:131) ~[na:1.6.0_19]
{noformat}
Possible fix: instead of just checking the first part of the package (at),
check for the full package (at.spardat.xma.xdelta).
--
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] (MSHADE-156) shade plugin is transforming also strings that are not supposed to be transformed
Neeme Praks created MSHADE-156:
--
Summary: shade plugin is transforming also strings that are not
supposed to be transformed
Key: MSHADE-156
URL: https://jira.codehaus.org/browse/MSHADE-156
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Neeme Praks
I'm shading several third party libraries into a single JAR. In the context of
this issue, there are two important libraries:
1. com.nothome:javaxdelta:2.0.1 - this library is in at.spardat.xma.xdelta
package.
2. ch.qos.logback:logback-classic:1.0.11 - in this library, in class
ch.qos.logback.classic.spi.StackTraceElementProxy, there is a method to convert
stack trace elements into strings:
public String getSTEAsString() {
if (steAsString == null) {
steAsString = at + ste.toString();
}
return steAsString;
}
I use org.myorgname.appname.shaded package for shading.
During shading, the constant at is replaced with
org.myorgname.appname.shaded.at -- shade plugin thinks that the at in the
beginning of that string is a package name and shades it.
This results in an unfortunate side-effect: all logged stack traces now look
like this:
{noformat}
Caused by: java.util.zip.ZipException: error in opening zip file
org.myorgname.appname.shaded.at java.util.zip.ZipFile.open(Native
Method) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:114) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:131) ~[na:1.6.0_19]
{noformat}
--
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] (MDEPLOY-120) Unable to deploy large file into Nexus 1.5.0 from Windows Server 2003 Enterprise
[ https://jira.codehaus.org/browse/MDEPLOY-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MDEPLOY-120. -- Resolution: Incomplete Assignee: Robert Scholte No feedback, so closing it. Unable to deploy large file into Nexus 1.5.0 from Windows Server 2003 Enterprise Key: MDEPLOY-120 URL: https://jira.codehaus.org/browse/MDEPLOY-120 Project: Maven Deploy Plugin Issue Type: Bug Components: deploy:deploy-file Affects Versions: 2.5 Environment: Nexus Server: Nexus 1.5.0 OSS running on Linux 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 17:17:21 EST 2007 i686 i686 i386 GNU/Linux Maven client OS: Windows Server 2003 Enterprise with all security updates applied Java(TM) SE Runtime Environment (build 1.6.0_14-b08) Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing) Output from mvn -v: Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) Java version: 1.6.0_14 Java home: D:\jdk1.6.0_14\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 2003 version: 5.2 arch: x86 Family: windows Reporter: Keith Wedinger Assignee: Robert Scholte Priority: Blocker Attachments: mavenuploadfiles.zip, mvn1024.log, mvn1536.log Attached to this issue are the files I am using to deploy a large file to my Nexus repository. The file being deployed is an EXE file whose size is 22,413,688 bytes. During deployment, the upload times out after several minutes with the stack trace below which I captured by running mvn with the -X argument. Deploying smaller files does appear to work but I have not done enough testing to determine the threshold when deployment fails. There is no proxy between the client OS and the Nexus server. The steps to reproduce this on my system are below. 1. Download and unzip mavenuploadfiles.zip onto a Windows Server 2003 Enterprise system. 2. Run mavenupload.cmd to get the syntax for this command script. The syntax message is self-explanatory. The ZIP file also contains my copy of settings.xml, the Maven settings file I am using. If you believe this is a Nexus 1.5.0 issue, please let me know and I will open the appropriate bug for Nexus OSS 1.5.0. STACK TRACE BEGIN: -- Error writing to server [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying artifact: Error transferring file at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying artifact: Error transferring file at org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:240) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) ... 17 more Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException: Error deploying artifact: Error transferring file at
[jira] (MDEPLOY-152) updateReleaseInfo for deploy-file does not work with Maven 3
[
https://jira.codehaus.org/browse/MDEPLOY-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MDEPLOY-152:
---
Description:
When deploying file with {{-DupdateReleaseInfo=true}} with maven3
{{release/release}} tag is not updated/created, but with maven2 everything
is good. Here is the full log:
{noformat}
$mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 10:44:56+0200)
Maven home: /home/user/java/apache-maven-3.0.4
Java version: 1.7.0_04, vendor: Oracle Corporation
Java home: /opt/jdk1.7.0_04/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux, version: 2.6.32-40-generic-pae, arch: i386,
family: unix
$mvn -e -DupdateReleaseInfo=true
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file
-Durl=file:///home/user/test/ldClientDeployTest/repository
-Dfile=/home/user/java/workspace/testing/mvnDeployFileIssue/test-proj/target/test-proj-1.0-SNAPSHOT.jar
-DpomFile=/home/user/java/workspace/testing/mvnDeployFileIssue/test-proj/pom.xml
-Dpackaging=jar
$cat
/home/user/test/ldClientDeployTest/repository/com/example/test-proj/maven-metadata.xml
?xml version=1.0 encoding=UTF-8?
metadata
groupIdcom.example/groupId
artifactIdtest-proj/artifactId
versioning
versions
version1.0-SNAPSHOT/version
/versions
lastUpdated20120702111039/lastUpdated
/versioning
/metadata
$M2_HOME=/home/user/java/apache-maven-2.2.1/
$PATH=$M2_HOME/bin:$PATH
$mvn -version
Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300)
Java version: 1.7.0_04
Java home: /opt/jdk1.7.0_04/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux version: 2.6.32-40-generic-pae arch: i386 Family:
unix
$cat
/home/user/test/ldClientDeployTest/repository/com/example/test-proj/maven-metadata.xml
?xml version=1.0 encoding=UTF-8?
metadata
groupIdcom.example/groupId
artifactIdtest-proj/artifactId
versioning
release1.0-SNAPSHOT/release
versions
version1.0-SNAPSHOT/version
/versions
lastUpdated20120702111359/lastUpdated
/versioning
/metadata
{noformat}
was:
When deploying file with -DupdateReleaseInfo=true with maven3
release/release tag is not updated/created, but with maven2 everything is
good. Here is the full log:
$mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 10:44:56+0200)
Maven home: /home/user/java/apache-maven-3.0.4
Java version: 1.7.0_04, vendor: Oracle Corporation
Java home: /opt/jdk1.7.0_04/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux, version: 2.6.32-40-generic-pae, arch: i386,
family: unix
$mvn -e -DupdateReleaseInfo=true
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file
-Durl=file:///home/user/test/ldClientDeployTest/repository
-Dfile=/home/user/java/workspace/testing/mvnDeployFileIssue/test-proj/target/test-proj-1.0-SNAPSHOT.jar
-DpomFile=/home/user/java/workspace/testing/mvnDeployFileIssue/test-proj/pom.xml
-Dpackaging=jar
$cat
/home/user/test/ldClientDeployTest/repository/com/example/test-proj/maven-metadata.xml
?xml version=1.0 encoding=UTF-8?
metadata
groupIdcom.example/groupId
artifactIdtest-proj/artifactId
versioning
versions
version1.0-SNAPSHOT/version
/versions
lastUpdated20120702111039/lastUpdated
/versioning
/metadata
$M2_HOME=/home/user/java/apache-maven-2.2.1/
$PATH=$M2_HOME/bin:$PATH
$mvn -version
Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300)
Java version: 1.7.0_04
Java home: /opt/jdk1.7.0_04/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux version: 2.6.32-40-generic-pae arch: i386 Family:
unix
$cat
/home/user/test/ldClientDeployTest/repository/com/example/test-proj/maven-metadata.xml
?xml version=1.0 encoding=UTF-8?
metadata
groupIdcom.example/groupId
artifactIdtest-proj/artifactId
versioning
release1.0-SNAPSHOT/release
versions
version1.0-SNAPSHOT/version
/versions
lastUpdated20120702111359/lastUpdated
/versioning
/metadata
updateReleaseInfo for deploy-file does not work with Maven 3
Key: MDEPLOY-152
URL: https://jira.codehaus.org/browse/MDEPLOY-152
Project: Maven Deploy Plugin
Issue Type: Bug
Affects Versions: 2.7
Environment: Linux, maven 3.0.4
Reporter: Ivan Sopov
When deploying file with
[jira] (MSHADE-156) shade plugin is transforming also strings that are not supposed to be transformed
[
https://jira.codehaus.org/browse/MSHADE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neeme Praks updated MSHADE-156:
---
Description:
I'm shading several third party libraries into a single JAR. In the context of
this issue, there are two important libraries:
1. com.nothome:javaxdelta:2.0.1 - this library is in at.spardat.xma.xdelta
package.
2. ch.qos.logback:logback-classic:1.0.11 - in this library, in class
ch.qos.logback.classic.spi.StackTraceElementProxy, there is a method to convert
stack trace elements into strings:
{code}
public String getSTEAsString() {
if (steAsString == null) {
steAsString = at + ste.toString();
}
return steAsString;
}
{code}
I use org.myorgname.appname.shaded package for shading.
During shading, the constant at is replaced with
org.myorgname.appname.shaded.at -- shade plugin thinks that the at in the
beginning of that string is a package name and shades it.
This results in an unfortunate side-effect: all logged stack traces now look
like this:
{noformat}
Caused by: java.util.zip.ZipException: error in opening zip file
org.myorgname.appname.shaded.at java.util.zip.ZipFile.open(Native
Method) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:114) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:131) ~[na:1.6.0_19]
{noformat}
Possible fixes:
* instead of just checking the first part of the package (at), check for the
full package (at.spardat.xma.xdelta).
* allow to configure shade plugin to ignore certain string constants in certain
classes (this would solve also some other issues we have with shade plugin
being too eager).
* both of the above.
was:
I'm shading several third party libraries into a single JAR. In the context of
this issue, there are two important libraries:
1. com.nothome:javaxdelta:2.0.1 - this library is in at.spardat.xma.xdelta
package.
2. ch.qos.logback:logback-classic:1.0.11 - in this library, in class
ch.qos.logback.classic.spi.StackTraceElementProxy, there is a method to convert
stack trace elements into strings:
{code}
public String getSTEAsString() {
if (steAsString == null) {
steAsString = at + ste.toString();
}
return steAsString;
}
{code}
I use org.myorgname.appname.shaded package for shading.
During shading, the constant at is replaced with
org.myorgname.appname.shaded.at -- shade plugin thinks that the at in the
beginning of that string is a package name and shades it.
This results in an unfortunate side-effect: all logged stack traces now look
like this:
{noformat}
Caused by: java.util.zip.ZipException: error in opening zip file
org.myorgname.appname.shaded.at java.util.zip.ZipFile.open(Native
Method) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:114) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:131) ~[na:1.6.0_19]
{noformat}
Possible fix: instead of just checking the first part of the package (at),
check for the full package (at.spardat.xma.xdelta).
shade plugin is transforming also strings that are not supposed to be
transformed
-
Key: MSHADE-156
URL: https://jira.codehaus.org/browse/MSHADE-156
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Neeme Praks
I'm shading several third party libraries into a single JAR. In the context
of this issue, there are two important libraries:
1. com.nothome:javaxdelta:2.0.1 - this library is in at.spardat.xma.xdelta
package.
2. ch.qos.logback:logback-classic:1.0.11 - in this library, in class
ch.qos.logback.classic.spi.StackTraceElementProxy, there is a method to
convert stack trace elements into strings:
{code}
public String getSTEAsString() {
if (steAsString == null) {
steAsString = at + ste.toString();
}
return steAsString;
}
{code}
I use org.myorgname.appname.shaded package for shading.
During shading, the constant at is replaced with
org.myorgname.appname.shaded.at -- shade plugin thinks that the at in the
beginning of that string is a package name and shades it.
This results in an unfortunate side-effect: all logged stack traces now look
like this:
{noformat}
Caused by: java.util.zip.ZipException: error in opening zip file
org.myorgname.appname.shaded.at java.util.zip.ZipFile.open(Native
Method) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:114) ~[na:1.6.0_19]
org.myorgname.appname.shaded.at
java.util.zip.ZipFile.init(ZipFile.java:131) ~[na:1.6.0_19]
{noformat}
Possible fixes:
* instead of just checking the first part of the package (at),
[jira] (MDEPLOY-155) Return code is: 401, ReasonPhrase:Unauthorized. When running a mvn deploy:deploy-file
[ https://jira.codehaus.org/browse/MDEPLOY-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MDEPLOY-155. -- Resolution: Cannot Reproduce Assignee: Robert Scholte If you get a 401, you either tried to access with the wrong credentials or you don't have the role to deploy. Return code is: 401, ReasonPhrase:Unauthorized. When running a mvn deploy:deploy-file - Key: MDEPLOY-155 URL: https://jira.codehaus.org/browse/MDEPLOY-155 Project: Maven Deploy Plugin Issue Type: Bug Reporter: Chris McIntosh Assignee: Robert Scholte When attempting to deploy a file to a protected nexus repository, we get an http 401 unauthorized exception. Plaintext username and password are stored in the settings.xml file. mvn deploy works fine, along with a curl to deploy the file. See http://stackoverflow.com/questions/12187483/how-to-deploy-an-arbitrary-binary-to-nexus-with-maven for sample commands. -- 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] (MDEPLOY-145) Documentation does not list layouts
[ https://jira.codehaus.org/browse/MDEPLOY-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MDEPLOY-145. -- Resolution: Fixed Fix Version/s: 2.8 Assignee: Robert Scholte Fixed in [r1521582|http://svn.apache.org/r1521582] Documentation does not list layouts --- Key: MDEPLOY-145 URL: https://jira.codehaus.org/browse/MDEPLOY-145 Project: Maven Deploy Plugin Issue Type: Bug Components: deploy:deploy Affects Versions: 2.7 Reporter: Benson Margulies Assignee: Robert Scholte Fix For: 2.8 the documentation for deploy:deploy never lists the valid, or even likely, values for 'layout'. -- 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] (MDEPLOY-165) deploy-file ignores classifier
Gili created MDEPLOY-165:
Summary: deploy-file ignores classifier
Key: MDEPLOY-165
URL: https://jira.codehaus.org/browse/MDEPLOY-165
Project: Maven Deploy Plugin
Issue Type: Bug
Components: deploy:deploy-file
Affects Versions: 2.7
Reporter: Gili
Priority: Critical
MDEPLOY-19's implementation is incomplete. If a user specifies a {{classifier}}
then {{generatePom}} fails to take the classifier into consideration and
uploads a POM file that omits the classifier.
The fix is simple:
Add the following line to {{DeployFileMojo.generateModel()}}:
{{model.setClassifier( classifier );}}
--
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] (MDEPLOY-139) deploy:deploy-file does not work with encrypted passwords when deploying to a Nexus repository
[
https://jira.codehaus.org/browse/MDEPLOY-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MDEPLOY-139.
--
Resolution: Not A Bug
Assignee: Robert Scholte
This is not a bug of the {{maven-deploy-plugin}}, but much more likely a Maven
core issue, since the plugin contains no code for credentials or decryption.
deploy:deploy-file does not work with encrypted passwords when deploying to a
Nexus repository
--
Key: MDEPLOY-139
URL: https://jira.codehaus.org/browse/MDEPLOY-139
Project: Maven Deploy Plugin
Issue Type: Bug
Components: deploy:deploy-file
Affects Versions: 2.6
Environment: Windows XP
Reporter: Julian Payne
Assignee: Robert Scholte
When I use an encrypted password in my settings.xml that deploy-file fails
with error code 401 when I deploy to a Nexus repository (Nexus 1.8.0). If I
put the plain text password in my settings.xml file then it works fine.
--
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] (MDEPLOY-130) Deploy uses passwords that failed decryption; retries even if login fails
[ https://jira.codehaus.org/browse/MDEPLOY-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MDEPLOY-130. -- Resolution: Duplicate Assignee: Robert Scholte Deploy uses passwords that failed decryption; retries even if login fails - Key: MDEPLOY-130 URL: https://jira.codehaus.org/browse/MDEPLOY-130 Project: Maven Deploy Plugin Issue Type: Bug Components: deploy:deploy Affects Versions: 2.5 Reporter: SebbASF Assignee: Robert Scholte Labels: contributers-welcome If passwords have been encrypted, deploy fails to notice if the password decryption failed. Furthermore, it carries on trying to login even after a login failure. This is annoying as it can result in lockout due to the multiple failed logins. -- 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] (MDEPLOY-101) Deploying javadoc or sources file without generating POM causes NPE in VersionExpressionTransformation.transformVersions(VersionExpressionTransformation.java:203)
[
https://jira.codehaus.org/browse/MDEPLOY-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MDEPLOY-101.
--
Resolution: Duplicate
Assignee: Robert Scholte
Deploying javadoc or sources file without generating POM causes NPE in
VersionExpressionTransformation.transformVersions(VersionExpressionTransformation.java:203)
--
Key: MDEPLOY-101
URL: https://jira.codehaus.org/browse/MDEPLOY-101
Project: Maven Deploy Plugin
Issue Type: Bug
Components: deploy:deploy-file
Environment: Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)
Java version: 1.6.0_07
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: mac os x version: 10.5.6 arch: x86_64 Family: mac
Reporter: Martin Burger
Assignee: Robert Scholte
If I deploy a sources or javadoc file (with proper classifier set)
without generating a POM (generatePom=false), Maven throws a
NullPointerException:
{noformat}
$ mvn deploy:deploy-file \
-Dfile=javassist-sources.jar \
-Dclassifier=sources \
-DgroupId=javassist \
-DartifactId=javassist \
-Dversion=3.10.0.GA \
-Dpackaging=jar \
-DgeneratePom=false \
-DrepositoryId=thirdparty \
-Durl=dav:https://***/nexus/content/repositories/thirdparty
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'deploy'.
[INFO]
[INFO] Building Javassist
[INFO]task-segment: [deploy:deploy-file] (aggregator-style)
[INFO]
[INFO] [deploy:deploy-file]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.project.artifact.VersionExpressionTransformation.transformVersions(VersionExpressionTransformation.java:203)
at
org.apache.maven.project.artifact.VersionExpressionTransformation.transformForDeployment(VersionExpressionTransformation.java:94)
at
org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.transformForDeployment(DefaultArtifactTransformationManager.java:78)
at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:86)
at
org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:240)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
{noformat}
If I set generatePom to true, it will work.
--
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-5512) Deploy uses passwords that failed decryption; retries even if login fails
SebbASF created MNG-5512: Summary: Deploy uses passwords that failed decryption; retries even if login fails Key: MNG-5512 URL: https://jira.codehaus.org/browse/MNG-5512 Project: Maven 2 3 Issue Type: Bug Reporter: SebbASF [See MDEPLOY-130 which was closed as being an issue in Maven core] If passwords have been encrypted, deploy fails to notice if the password decryption failed. Furthermore, it carries on trying to login even after a login failure. This is true even if the decryption succeeded but the password was incorrect or no encryption was used and the password is incorrect. This is bad as it can result in lockout due to the multiple failed logins - deploy needs to login several times - and may cause unnecessary work for system admins. -- 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] (MDEPLOY-141) Deploy fails for releases with repository deployment policy set to Disable Redeploy
[
https://jira.codehaus.org/browse/MDEPLOY-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332633#comment-332633
]
Robert Scholte commented on MDEPLOY-141:
This is most likely a Maven core issue. Which version was used?
Deploy fails for releases with repository deployment policy set to Disable
Redeploy
---
Key: MDEPLOY-141
URL: https://jira.codehaus.org/browse/MDEPLOY-141
Project: Maven Deploy Plugin
Issue Type: Bug
Affects Versions: 2.7
Reporter: Manfred Schürhoff
Priority: Minor
We recently switched from Archiva to Nexus. The deployment policy for the
release repository in Nexus is set to Disable Redeploy. However, this now
causes problems that are described in MDEPLOY-134 and MDEPLOY-137: when an
artifact is uploaded, it first uploads the pom and the artifact which works
OK, but then it tries to upload the sources of the artifact (also fine) and
again the pom which fails with HTTP 400:
{noformat}Error deploying artifact: Failed to transfer file:
http://nl-nexus/nexus/content/repositories/releases/groupId.artifactId.version.pom.
Return code is: 400{noformat}
We were still using version 2.3 of the maven-deploy-plugin, but we switched
to the latest 2.7 version hoping this would solve the issues described in
MDEPLOY-134 and MDEPLOY-137, but the problem still remains. We've also tried
setting uniqueVersion to false for the releases in distributionManagment, but
that also doesn't help (and is something we'd rather not do).
--
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] (MDEPLOY-165) deploy-file ignores classifier
[
https://jira.codehaus.org/browse/MDEPLOY-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili closed MDEPLOY-165.
Resolution: Not A Bug
Fix Version/s: 2.8
Sorry. I discovered that (no such method) when I tried formulating a patch. I
misunderstood what was going on on my binary server and incorrectly assumed
that the POM should contain a classifier field. As you mentioned, there is no
such field.
I'm closing this issue as not a bug. Sorry for the false alarm.
deploy-file ignores classifier
--
Key: MDEPLOY-165
URL: https://jira.codehaus.org/browse/MDEPLOY-165
Project: Maven Deploy Plugin
Issue Type: Bug
Components: deploy:deploy-file
Affects Versions: 2.7
Reporter: Gili
Priority: Critical
Fix For: 2.8
MDEPLOY-19's implementation is incomplete. If a user specifies a
{{classifier}} then {{generatePom}} fails to take the classifier into
consideration and uploads a POM file that omits the classifier.
The fix is simple:
Add the following line to {{DeployFileMojo.generateModel()}}:
{{model.setClassifier( classifier );}}
--
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] (MDEPLOY-157) Add deployAtEnd option for multimodule projects
[ https://jira.codehaus.org/browse/MDEPLOY-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332638#comment-332638 ] Robert Scholte commented on MDEPLOY-157: I'll go through the open issues and see what else can be fixed. I'll try to release this within a week or two. Add deployAtEnd option for multimodule projects --- Key: MDEPLOY-157 URL: https://jira.codehaus.org/browse/MDEPLOY-157 Project: Maven Deploy Plugin Issue Type: New Feature Components: deploy:deploy Affects Versions: 2.7 Reporter: Robert Scholte Assignee: Robert Scholte Fix For: 2.8 With this option it will be possible to only deploy artifacts if all have been succesfully installed. See MRELEASE-664 for further details. -- 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] (MDEPLOY-150) deploy-file does not use repository url in the same way as deploy
[
https://jira.codehaus.org/browse/MDEPLOY-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332640#comment-332640
]
Robert Scholte edited comment on MDEPLOY-150 at 9/10/13 3:41 PM:
-
MDEPLOY-68 shows the same issue, but then for {{deploy}}
was (Author: rfscholte):
I think MDEPLOY-68 very well explains the same issue.
deploy-file does not use repository url in the same way as deploy
Key: MDEPLOY-150
URL: https://jira.codehaus.org/browse/MDEPLOY-150
Project: Maven Deploy Plugin
Issue Type: Bug
Components: deploy:deploy-file
Affects Versions: 2.7
Environment: Windows 7, Maven 2.2.1
Reporter: Kai Hofmann
Assignee: Robert Scholte
Priority: Critical
We use an own lifecycle here which creates a zip file instead of a jar file.
So we use
{noformat}org.apache.maven.plugins:maven-install-plugin:install,org.apache.maven.plugins:maven-install-plugin:install-file{noformat}
which installs the zip file correctly.
Additionally I now wanted to also allow deploying of this zip file to nexus
by:
{noformat}org.apache.maven.plugins:maven-deploy-plugin:deploy,org.apache.maven.plugins:maven-deploy-plugin:deploy-file{noformat}
in the pom I have then:
{code:xml}
properties
file${project.build.directory}/${project.artifactId}-${project.version}.zip/file
/properties
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-install-plugin/artifactId
version2.3.1/version
executions
execution
idinstall-service-zip/id
goals
goalinstall-file/goal
/goals
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-deploy-plugin/artifactId
version2.7/version
executions
execution
iddeploy-service-zip/id
goals
goaldeploy-file/goal
/goals
/execution
/executions
/plugin
/plugins
/pluginManagement
{code}
as well as settings for the repositories within the maven {{settings.xml}}.
As said the install process works perfectly, but I have trouble with the
{{deploy-file}}.
When working without the {{deploy-file}} (only with the {{deploy}})
everything also works correct for the deployment.
After adding the {{deploy-file}} as shown above I come into trouble, because
beside the file property the deploy-plugin requests for the required url
parameter.
I wonder about this, because I assumed that the url parameter will come
from the choosen repository (release vs snapshot) settings?
When I set the url as property beside the file property, then I can
deploy a snapshot.
But to deploying snapshot/release this will not work.
In {{deploy}} the url parameter is implicitly correctly choosen, why not in
{{deploy-file}}? this would make the url parameter optional.
So I see this as a bug/feature, because when deploy works in this way, then
{{deploy-file}} should work analogous. Or have I missed something here?
--
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] (MDEPLOY-141) Deploy fails for releases with repository deployment policy set to Disable Redeploy
[
https://jira.codehaus.org/browse/MDEPLOY-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=332644#comment-332644
]
Harald Lammers commented on MDEPLOY-141:
For us same problem. We use maven version 2.2.1.
Is it solved in maven 3.0.* or 3.1.*?
Deploy fails for releases with repository deployment policy set to Disable
Redeploy
---
Key: MDEPLOY-141
URL: https://jira.codehaus.org/browse/MDEPLOY-141
Project: Maven Deploy Plugin
Issue Type: Bug
Affects Versions: 2.7
Reporter: Manfred Schürhoff
Priority: Minor
We recently switched from Archiva to Nexus. The deployment policy for the
release repository in Nexus is set to Disable Redeploy. However, this now
causes problems that are described in MDEPLOY-134 and MDEPLOY-137: when an
artifact is uploaded, it first uploads the pom and the artifact which works
OK, but then it tries to upload the sources of the artifact (also fine) and
again the pom which fails with HTTP 400:
{noformat}Error deploying artifact: Failed to transfer file:
http://nl-nexus/nexus/content/repositories/releases/groupId.artifactId.version.pom.
Return code is: 400{noformat}
We were still using version 2.3 of the maven-deploy-plugin, but we switched
to the latest 2.7 version hoping this would solve the issues described in
MDEPLOY-134 and MDEPLOY-137, but the problem still remains. We've also tried
setting uniqueVersion to false for the releases in distributionManagment, but
that also doesn't help (and is something we'd rather not do).
--
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] (MDEPLOY-150) deploy-file does not use repository url in the same way as deploy
[
https://jira.codehaus.org/browse/MDEPLOY-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reopened MDEPLOY-150:
deploy-file does not use repository url in the same way as deploy
Key: MDEPLOY-150
URL: https://jira.codehaus.org/browse/MDEPLOY-150
Project: Maven Deploy Plugin
Issue Type: Bug
Components: deploy:deploy-file
Affects Versions: 2.7
Environment: Windows 7, Maven 2.2.1
Reporter: Kai Hofmann
Assignee: Robert Scholte
Priority: Critical
We use an own lifecycle here which creates a zip file instead of a jar file.
So we use
{noformat}org.apache.maven.plugins:maven-install-plugin:install,org.apache.maven.plugins:maven-install-plugin:install-file{noformat}
which installs the zip file correctly.
Additionally I now wanted to also allow deploying of this zip file to nexus
by:
{noformat}org.apache.maven.plugins:maven-deploy-plugin:deploy,org.apache.maven.plugins:maven-deploy-plugin:deploy-file{noformat}
in the pom I have then:
{code:xml}
properties
file${project.build.directory}/${project.artifactId}-${project.version}.zip/file
/properties
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-install-plugin/artifactId
version2.3.1/version
executions
execution
idinstall-service-zip/id
goals
goalinstall-file/goal
/goals
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-deploy-plugin/artifactId
version2.7/version
executions
execution
iddeploy-service-zip/id
goals
goaldeploy-file/goal
/goals
/execution
/executions
/plugin
/plugins
/pluginManagement
{code}
as well as settings for the repositories within the maven {{settings.xml}}.
As said the install process works perfectly, but I have trouble with the
{{deploy-file}}.
When working without the {{deploy-file}} (only with the {{deploy}})
everything also works correct for the deployment.
After adding the {{deploy-file}} as shown above I come into trouble, because
beside the file property the deploy-plugin requests for the required url
parameter.
I wonder about this, because I assumed that the url parameter will come
from the choosen repository (release vs snapshot) settings?
When I set the url as property beside the file property, then I can
deploy a snapshot.
But to deploying snapshot/release this will not work.
In {{deploy}} the url parameter is implicitly correctly choosen, why not in
{{deploy-file}}? this would make the url parameter optional.
So I see this as a bug/feature, because when deploy works in this way, then
{{deploy-file}} should work analogous. Or have I missed something here?
--
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] (MPIR-290) improve git support: remove directory info (after '.git') for git clone
[ https://jira.codehaus.org/browse/MPIR-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPIR-290. -- Resolution: Fixed Fix Version/s: 2.8 Assignee: Herve Boutemy done in [r1521663|http://svn.apache.org/r1521663] improve git support: remove directory info (after '.git') for git clone - Key: MPIR-290 URL: https://jira.codehaus.org/browse/MPIR-290 Project: Maven Project Info Reports Plugin Issue Type: Improvement Components: scm Affects Versions: 2.7 Reporter: Herve Boutemy Assignee: Herve Boutemy Fix For: 2.8 actually, when a multi-module project uses git as SCM, people often let Maven automatically calculate scm info from parent, ie add a directory named after the artifact id then MPIR displays the info directly: this leads to messages like: git clone https://my.git.server.com/repository.git/artifact-id People should have fixed scm value in the artifact pom, but it's hard to explain that: people tend to imagine MPIR wrote something wrong Hacking MPIR scm report to remove anything after '.git' would give good git clone instructions deducted from wrong info in pom -- 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] (WAGON-401) Access Denied due to missing User-Agent
[
https://jira.codehaus.org/browse/WAGON-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy reopened WAGON-401:
-
one use case has been fixed, but there are other in other plugins
IMHO, a default User-Agent should be defined, to reduce the gap between
wagon-http and wagon-http-lightweight: not hard to do and will avoid more
problems
Access Denied due to missing User-Agent
---
Key: WAGON-401
URL: https://jira.codehaus.org/browse/WAGON-401
Project: Maven Wagon
Issue Type: Improvement
Components: wagon-http
Affects Versions: 2.4
Reporter: Robert Scholte
Assignee: Robert Scholte
Priority: Critical
Attachments: accessdenied-test.patch
In the last week of August 2013 the policy of Maven Central has been changed.
Files like {{maven-metadata.xml}} now require a {{User-Agent}} in their
request.
Otherwise it will fail with an Access Denied status.
The preferred solution is an adjustment of the policy at Maven Central, but
it wouldn't harm if Wagon would set the User-agent.
The attached could be considered as a smoketest.
--
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] (MDEPLOY-150) deploy-file does not use repository url in the same way as deploy
[
https://jira.codehaus.org/browse/MDEPLOY-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MDEPLOY-150.
--
Resolution: Duplicate
Assignee: Robert Scholte
I think MDEPLOY-68 very well explains the same issue.
deploy-file does not use repository url in the same way as deploy
Key: MDEPLOY-150
URL: https://jira.codehaus.org/browse/MDEPLOY-150
Project: Maven Deploy Plugin
Issue Type: Bug
Components: deploy:deploy-file
Affects Versions: 2.7
Environment: Windows 7, Maven 2.2.1
Reporter: Kai Hofmann
Assignee: Robert Scholte
Priority: Critical
We use an own lifecycle here which creates a zip file instead of a jar file.
So we use
{noformat}org.apache.maven.plugins:maven-install-plugin:install,org.apache.maven.plugins:maven-install-plugin:install-file{noformat}
which installs the zip file correctly.
Additionally I now wanted to also allow deploying of this zip file to nexus
by:
{noformat}org.apache.maven.plugins:maven-deploy-plugin:deploy,org.apache.maven.plugins:maven-deploy-plugin:deploy-file{noformat}
in the pom I have then:
{code:xml}
properties
file${project.build.directory}/${project.artifactId}-${project.version}.zip/file
/properties
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-install-plugin/artifactId
version2.3.1/version
executions
execution
idinstall-service-zip/id
goals
goalinstall-file/goal
/goals
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-deploy-plugin/artifactId
version2.7/version
executions
execution
iddeploy-service-zip/id
goals
goaldeploy-file/goal
/goals
/execution
/executions
/plugin
/plugins
/pluginManagement
{code}
as well as settings for the repositories within the maven {{settings.xml}}.
As said the install process works perfectly, but I have trouble with the
{{deploy-file}}.
When working without the {{deploy-file}} (only with the {{deploy}})
everything also works correct for the deployment.
After adding the {{deploy-file}} as shown above I come into trouble, because
beside the file property the deploy-plugin requests for the required url
parameter.
I wonder about this, because I assumed that the url parameter will come
from the choosen repository (release vs snapshot) settings?
When I set the url as property beside the file property, then I can
deploy a snapshot.
But to deploying snapshot/release this will not work.
In {{deploy}} the url parameter is implicitly correctly choosen, why not in
{{deploy-file}}? this would make the url parameter optional.
So I see this as a bug/feature, because when deploy works in this way, then
{{deploy-file}} should work analogous. Or have I missed something here?
--
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] (MSHARED-295) Non reliable killing of processes by CommandLineUtils
[ https://jira.codehaus.org/browse/MSHARED-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Klochkov updated MSHARED-295: Attachment: MSHARED-295.patch Attaching a patch. The idea is to use Sigar (https://support.hyperic.com/display/SIGAR/Home) as an optional dependency. It's JNI based library with Apache license. If Sigar classes are present, use it to walk over child processes and kill them all. Otherwise the default implementation is used. The patch is not finished - in particular, determining PID would not work on Windows. What about the idea? The code itself is verified with Hadoop builds which tend to have the problem of non killed subprocesses. Checked on OSX and Linux. Non reliable killing of processes by CommandLineUtils - Key: MSHARED-295 URL: https://jira.codehaus.org/browse/MSHARED-295 Project: Maven Shared Components Issue Type: Improvement Components: maven-shared-utils Reporter: Andrey Klochkov Attachments: MSHARED-295.patch CommandLineUtils is used in Maven-Surefire to start forks which execute tests. It is a well known issue that sometimes child processes are not killed correctly. This is a known limitation of JVM, and the only reliable way to implement it would be platform specific. Bug report in Surefire JIRA: http://jira.codehaus.org/browse/SUREFIRE-773 JVM bug report. It's Windows specific, but the problem exists on Linux and OSX as well. http://bugs.sun.com/view_bug.do?bug_id=4770092 I'm proposing either 1) to implement several platform specific implementations of ProcessHook or 2) to make the mechanism of killing processes extendable for clients of the library. -- 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
