[jira] (MRELEASE-748) trailing whitespace is stripped from scmCommentPrefix
Jakub Skoczen created MRELEASE-748: -- Summary: trailing whitespace is stripped from scmCommentPrefix Key: MRELEASE-748 URL: https://jira.codehaus.org/browse/MRELEASE-748 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.2.2 Environment: Any Reporter: Jakub Skoczen Priority: Minor When configuring custom scmCommentPrefix any trailing whitespaces are trimmed resulting in ugly commit mesages, eg: scmCommentPrefixMaven: /scmCommentPrefix Maven:prepare for next development iteration sCP should honor whitespaces -- 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] (MRELEASE-749) release:prepare copies contents of source of Subversion branch into release tag
Bindul Bhowmik created MRELEASE-749: --- Summary: release:prepare copies contents of source of Subversion branch into release tag Key: MRELEASE-749 URL: https://jira.codehaus.org/browse/MRELEASE-749 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.2.2 Environment: Windows 7; Silk Subversion 1.6x client; SVN 1.6x Reporter: Bindul Bhowmik When releasing from a branch, release:prepare copies the content of the source of the branch into the release tag rather than the content of the branch -- 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] (MRELEASE-749) release:prepare copies contents of source of Subversion branch into release tag
[ https://jira.codehaus.org/browse/MRELEASE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294081#comment-294081 ] Joerg Schaible commented on MRELEASE-749: - ?? This is exactly how it should work. A release is a release it does not matter if it was created from a branch or not. release:prepare copies contents of source of Subversion branch into release tag --- Key: MRELEASE-749 URL: https://jira.codehaus.org/browse/MRELEASE-749 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.2.2 Environment: Windows 7; Silk Subversion 1.6x client; SVN 1.6x Reporter: Bindul Bhowmik When releasing from a branch, release:prepare copies the content of the source of the branch into the release tag rather than the content of the branch -- 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] (MRELEASE-749) release:prepare copies contents of source of Subversion branch into release tag
[ https://jira.codehaus.org/browse/MRELEASE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294089#comment-294089 ] Bindul Bhowmik commented on MRELEASE-749: - I realize the initial description was not very clear. Here is a simple use case: A project with a standard subversion structure (trunk, branches, tags) has a tag project-1.1 (tags/project-1.2). If there is a need to create a bug fix release (1.2.1), a maintenance branch is created (branches/project-1.2.x) and changes made in the branch. Now, you try and run the release plugin (release:prepare) from the code checked out from the branch to create release 1.2.1. The release:prepare stage creates the proper tag in SVN (tags/project-1.2.1), but the content in the tag is identical to tags/project-1.2 rather than branches/project-1.2.x (with of course the version changes from 1.2.1-SNAPSHOT to 1.2.1). release:prepare run on code checked out from trunk works just fine. Not sure if it is relevant, but here is some additional information: - It is a multi-module maven project with a child module - Subversion client: Subversion command-line client, version 1.6.17-SlikSvn-tag-1.6.17@1130898-X64 - Subversion server: Subversion version 1.6.1 (r37116) release:prepare copies contents of source of Subversion branch into release tag --- Key: MRELEASE-749 URL: https://jira.codehaus.org/browse/MRELEASE-749 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.2.2 Environment: Windows 7; Silk Subversion 1.6x client; SVN 1.6x Reporter: Bindul Bhowmik When releasing from a branch, release:prepare copies the content of the source of the branch into the release tag rather than the content of the branch -- 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] (MRELEASE-749) release:prepare copies contents of source of Subversion branch into release tag
[ https://jira.codehaus.org/browse/MRELEASE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294089#comment-294089 ] Bindul Bhowmik edited comment on MRELEASE-749 at 3/14/12 6:10 AM: -- I realize the initial description was not very clear. Here is a simple use case: A project with a standard subversion structure (trunk, branches, tags) has a tag project-1.1 (tags/project-1.2). If there is a need to create a bug fix release (1.2.1), a maintenance branch is created (branches/project-1.2.x) and changes made in the branch. Now, you try and run the release plugin (release:prepare) from the code checked out from the branch to create release 1.2.1. The release:prepare stage creates the proper tag in SVN (tags/project-1.2.1), but the content in the tag is identical to tags/project-1.2 rather than branches/project-1.2.x (with of course the version changes from 1.2.1-SNAPSHOT to 1.2.1). release:prepare run on code checked out from trunk works just fine. Not sure if it is relevant, but here is some additional information: - It is a multi-module maven project with a child module - Subversion client: Subversion command-line client, version 1.6.17-SlikSvn-tag-1.6.17@1130898-X64 - Subversion server: Subversion version 1.6.1 (r37116) - The branch above was created using Eclipse Subversive plugin ver. 0.7.9.I20110819-1700 (using SVNKit connector 1.3.5 r7406 (SVN 1.6.15 compatible)) was (Author: bindul): I realize the initial description was not very clear. Here is a simple use case: A project with a standard subversion structure (trunk, branches, tags) has a tag project-1.1 (tags/project-1.2). If there is a need to create a bug fix release (1.2.1), a maintenance branch is created (branches/project-1.2.x) and changes made in the branch. Now, you try and run the release plugin (release:prepare) from the code checked out from the branch to create release 1.2.1. The release:prepare stage creates the proper tag in SVN (tags/project-1.2.1), but the content in the tag is identical to tags/project-1.2 rather than branches/project-1.2.x (with of course the version changes from 1.2.1-SNAPSHOT to 1.2.1). release:prepare run on code checked out from trunk works just fine. Not sure if it is relevant, but here is some additional information: - It is a multi-module maven project with a child module - Subversion client: Subversion command-line client, version 1.6.17-SlikSvn-tag-1.6.17@1130898-X64 - Subversion server: Subversion version 1.6.1 (r37116) release:prepare copies contents of source of Subversion branch into release tag --- Key: MRELEASE-749 URL: https://jira.codehaus.org/browse/MRELEASE-749 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.2.2 Environment: Windows 7; Silk Subversion 1.6x client; SVN 1.6x Reporter: Bindul Bhowmik When releasing from a branch, release:prepare copies the content of the source of the branch into the release tag rather than the content of the branch -- 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] (MRELEASE-749) release:prepare copies contents of source of Subversion branch into release tag
[ https://jira.codehaus.org/browse/MRELEASE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294090#comment-294090 ] Joerg Schaible commented on MRELEASE-749: - How did you create the branch? When you do this manually, did you realize, that you have to adjust the SCM URLs in the POM? release:prepare copies contents of source of Subversion branch into release tag --- Key: MRELEASE-749 URL: https://jira.codehaus.org/browse/MRELEASE-749 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.2.2 Environment: Windows 7; Silk Subversion 1.6x client; SVN 1.6x Reporter: Bindul Bhowmik When releasing from a branch, release:prepare copies the content of the source of the branch into the release tag rather than the content of the branch -- 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-1378) Make dependencies of test-jars transitive
[
https://jira.codehaus.org/browse/MNG-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294097#comment-294097
]
Alex Heneveld commented on MNG-1378:
+1
Naively I expected that a dependency which is both test-scoped and
test-jar-classified would pull in test-scoped transitive dependencies, ie given
{code}
proj1 pom:
dependency
artifactIdsupport/artifactId
scopetest/scope
/dependency
proj2 pom:
dependency
artifactIdproj1/artifactId
classifertest-jar/classifier
scopetest/scope
/dependency
{code}
Like others I'd like proj2 to see support without having to explicitly re-list
it.
If I haven't declared classifier test-jar then it's fair enough not to pull in
transitive test-scoped dependencies. I guess the problem is that classifier
namespace isn't as formalised as scopes, and making dependency resolution
itself dependent on the classifier name could get complicated?
Would a new tag {{importScopetest/importScope}} be a good solution?
(Although a part of me worries we this starts down a slippery slope, next
wanting to introduce test-runtime and test-compile scopes...)
Make dependencies of test-jars transitive
-
Key: MNG-1378
URL: https://jira.codehaus.org/browse/MNG-1378
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0
Reporter: Mark Hobson
Fix For: Issues to be reviewed for 3.x
Attachments: mng1378.tar.gz
test-jar transitive dependencies are calculated as per compile scope rather
than test scope.
The situation is demonstrated nicely in it0077:
* module sub1 has a test-scoped dependency of commons-lang
* module sub2 has a test-scoped dependency of sub1 test-jar
sub2 tests should inherit the commons-lang transitive dependency. For
example:
Index:
maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java
===
---
maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java
(revision
328307)
+++
maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java
(working
copy)
@@ -1,6 +1,7 @@
package org.apache.maven.it0077;
import junit.framework.TestCase;
+import org.apache.commons.lang.BooleanUtils;
public class PersonTwoTest
extends PersonTest
Results in:
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
c:\maven-components\maven-core-it\it0077\sub2\src\test\java\org\apache\maven\it0077\PersonTwoTest.java:[4,31]
package org.apache.commons.lang does not exist
--
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-5258) localRepository in settings.xml does not handle ~ as home.dir
[
https://jira.codehaus.org/browse/MNG-5258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MNG-5258.
-
Resolution: Not A Bug
Assignee: Olivier Lamy
to create a private repository somewhere in his/her home directory. just use
${user.home}/foo/maven-rocks-repository :-)
localRepository in settings.xml does not handle ~ as home.dir
-
Key: MNG-5258
URL: https://jira.codehaus.org/browse/MNG-5258
Project: Maven 2 3
Issue Type: Bug
Components: Bootstrap Build, Settings
Affects Versions: 2.2.1, 3.0.4
Environment: Linux (Ubuntu 11.10), Java 6
Reporter: Thomas Zeeman
Assignee: Olivier Lamy
My provided settings.xml contained a localRepository part with the value
~/.m2/repository and when invoking any maven command, this caused issues.
Steps to reproduce:
1 - create a settings.xml with the following content:
settings
!-- localRepository
| The path to the local repository maven will use to store artifacts.
|
| Default: ~/.m2/repository --
localRepository~/.m2/repository/localRepository
/settings
2 - run mvn clean in an existing project
3 - maven will create a ~ directory in the project where it will download all
artifacts to.
Apart from essentially creating a private repository for each project (which
can quickly take up way more space than necessary, cause issues about missing
artifacts) it may also cause issues if you try to remove it and forget to
escape the ~; ie if you do rm -rf ~ instead of rm -rf '~'.
I also tested with maven 2.2.1 and that will blow up with errors about not
being able to create /.m2/repository/some path to an artifact.
Both 3.0.4 and 2.2.1 were downloaded from maven.apache.org, not installed via
apt/dpkg.
--
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-5258) localRepository in settings.xml does not handle ~ as home.dir
[
https://jira.codehaus.org/browse/MNG-5258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Zeeman reopened MNG-5258:
As mentioned in the original report, the settings.xml was provided to me. I've
now traced the source and it was an adapted version from the one supplied in
the conf directory of the maven binary distribution. The localRepository part
was copied from there and the value changed from /path/to/local/repo to what
was in the comment; apparently in the expectation that the value in the comment
works as advertised.
As to the usefulness of having a value of ~/.m2/repository, I agree it is
rather low and I've since removed this entry from my settings.xml. But it took
me some time to figure out what was going wrong especially given the
expectations one has about ~ on a *nix system and the comment in the maven
provided example settings.xml. (Not to mention that a ~ directory does not show
in a typical ls output, my IDE populated the 'real' ~/.m2/repository and any
cli executed maven commands were only occasionally failing or downloading
artifacts again.)
So if you consider this 'not a bug', then at least update the comment in the
apache-maven/src/conf/settings.xml to say ${user.home}/.m2/repository instead
of ~/.m2/repository which obviously does not work as expected and advertised.
Optionally consider making v3 behave like v2 and simply ignore the ~ in the
value for the localRepository.
That should hopefully save others who want to relocate the repo to somewhere
else in their home dir some time in figuring out why it does not work.
localRepository in settings.xml does not handle ~ as home.dir
-
Key: MNG-5258
URL: https://jira.codehaus.org/browse/MNG-5258
Project: Maven 2 3
Issue Type: Bug
Components: Bootstrap Build, Settings
Affects Versions: 2.2.1, 3.0.4
Environment: Linux (Ubuntu 11.10), Java 6
Reporter: Thomas Zeeman
Assignee: Olivier Lamy
My provided settings.xml contained a localRepository part with the value
~/.m2/repository and when invoking any maven command, this caused issues.
Steps to reproduce:
1 - create a settings.xml with the following content:
settings
!-- localRepository
| The path to the local repository maven will use to store artifacts.
|
| Default: ~/.m2/repository --
localRepository~/.m2/repository/localRepository
/settings
2 - run mvn clean in an existing project
3 - maven will create a ~ directory in the project where it will download all
artifacts to.
Apart from essentially creating a private repository for each project (which
can quickly take up way more space than necessary, cause issues about missing
artifacts) it may also cause issues if you try to remove it and forget to
escape the ~; ie if you do rm -rf ~ instead of rm -rf '~'.
I also tested with maven 2.2.1 and that will blow up with errors about not
being able to create /.m2/repository/some path to an artifact.
Both 3.0.4 and 2.2.1 were downloaded from maven.apache.org, not installed via
apt/dpkg.
--
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] (WAGON-369) Maven deploy plugin doesn't follow HTTP 302 redirects
[
https://jira.codehaus.org/browse/WAGON-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated WAGON-369:
---
Fix Version/s: 2.3
Maven deploy plugin doesn't follow HTTP 302 redirects
-
Key: WAGON-369
URL: https://jira.codehaus.org/browse/WAGON-369
Project: Maven Wagon
Issue Type: Bug
Affects Versions: 2.2
Reporter: James Baldassari
Assignee: Olivier Lamy
Fix For: 2.3
We have a reverse proxy server sitting in front of our Artifactory
repository. We've been running with this configuration for over a year with
no problems until we upgraded to Maven 3.0.4 and maven-deploy-plugin 2.7.
When deploying an artifact to a repository, if the request returns a 302
redirect, maven-deploy-plugin 2.7 does not follow the redirect and simply
fails. It seems like a regression was introduced in maven-deploy-plugin some
time after v2.5 (the default version used by Maven 3.0.3, which works). The
full stack trace follows:
{noformat}
[INFO] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
project myartifact: Failed to deploy artifacts: Could not transfer artifact
mycompany:myartifact:pom:4.4.4 from/to maven01
(http://maven.mycompany.net/libs-releases-local): Failed to transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found. - [Help 1]
[INFO] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
(default-deploy) on project myartifact: Failed to deploy artifacts: Could not
transfer artifact mycompany:myartifact:pom:4.4.4 from/to dxmaven01
(http://maven.mycompany.net/libs-releases-local): Failed to transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found.
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
[INFO]at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
[INFO]at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
[INFO]at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
[INFO]at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
[INFO]at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
[INFO]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO]at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[INFO]at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[INFO]at java.lang.reflect.Method.invoke(Method.java:597)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[INFO] Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
deploy artifacts: Could not transfer artifact mycompany:myartifact:pom:4.4.4
from/to dxmaven01 (http://maven.mycompany.net/libs-releases-local): Failed to
transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found.
[INFO]at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:193)
[INFO]at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
[INFO]... 19 more
[INFO] Caused by:
org.apache.maven.artifact.deployer.ArtifactDeploymentException: Failed to
deploy artifacts: Could not transfer artifact mycompany:myartifact:pom:4.4.4
from/to
[jira] (WAGON-367) Very large number of temporary files http-wagon.*.tmp if wagon is used in a long time running JVM (like a CI server)
[
https://jira.codehaus.org/browse/WAGON-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed WAGON-367.
--
Resolution: Fixed
fixed r1300649.
Very large number of temporary files http-wagon.*.tmp if wagon is used in a
long time running JVM (like a CI server)
--
Key: WAGON-367
URL: https://jira.codehaus.org/browse/WAGON-367
Project: Maven Wagon
Issue Type: Bug
Components: wagon-webdav
Affects Versions: 2.0, 2.1
Reporter: Arnaud Heritier
Assignee: Olivier Lamy
Fix For: 2.3
See
http://maven.apache.org/wagon/wagon-providers/wagon-http-shared/xref/index.html
I discovered the issue in Jenkins after having it running for days. My
temporary directory had so many files http-wagon.*.tmp that a {{rm *}} was
refused (too many params).
--
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] (WAGON-369) Maven deploy plugin doesn't follow HTTP 302 redirects
[
https://jira.codehaus.org/browse/WAGON-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294114#comment-294114
]
Olivier Lamy commented on WAGON-369:
fixed for PUT. I will now have a look to write unit test for other http methods
used (i.e. get )
Maven deploy plugin doesn't follow HTTP 302 redirects
-
Key: WAGON-369
URL: https://jira.codehaus.org/browse/WAGON-369
Project: Maven Wagon
Issue Type: Bug
Affects Versions: 2.2
Reporter: James Baldassari
Assignee: Olivier Lamy
Fix For: 2.3
We have a reverse proxy server sitting in front of our Artifactory
repository. We've been running with this configuration for over a year with
no problems until we upgraded to Maven 3.0.4 and maven-deploy-plugin 2.7.
When deploying an artifact to a repository, if the request returns a 302
redirect, maven-deploy-plugin 2.7 does not follow the redirect and simply
fails. It seems like a regression was introduced in maven-deploy-plugin some
time after v2.5 (the default version used by Maven 3.0.3, which works). The
full stack trace follows:
{noformat}
[INFO] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
project myartifact: Failed to deploy artifacts: Could not transfer artifact
mycompany:myartifact:pom:4.4.4 from/to maven01
(http://maven.mycompany.net/libs-releases-local): Failed to transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found. - [Help 1]
[INFO] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
(default-deploy) on project myartifact: Failed to deploy artifacts: Could not
transfer artifact mycompany:myartifact:pom:4.4.4 from/to dxmaven01
(http://maven.mycompany.net/libs-releases-local): Failed to transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found.
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
[INFO]at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
[INFO]at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
[INFO]at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
[INFO]at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
[INFO]at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
[INFO]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO]at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[INFO]at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[INFO]at java.lang.reflect.Method.invoke(Method.java:597)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[INFO] Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
deploy artifacts: Could not transfer artifact mycompany:myartifact:pom:4.4.4
from/to dxmaven01 (http://maven.mycompany.net/libs-releases-local): Failed to
transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found.
[INFO]at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:193)
[INFO]at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
[INFO]... 19 more
[INFO] Caused by:
[jira] (MNG-5261) upgrade wagon version to 2.3 to fix issues with redirect
Olivier Lamy created MNG-5261: - Summary: upgrade wagon version to 2.3 to fix issues with redirect Key: MNG-5261 URL: https://jira.codehaus.org/browse/MNG-5261 Project: Maven 2 3 Issue Type: Bug Components: Deployment Affects Versions: 3.0.4 Reporter: Olivier Lamy related to WAGON-369 -- 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-5261) upgrade wagon version to 2.3 to fix issues with redirect
[ https://jira.codehaus.org/browse/MNG-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MNG-5261: -- Fix Version/s: 3.0.5 Assignee: Olivier Lamy upgrade wagon version to 2.3 to fix issues with redirect Key: MNG-5261 URL: https://jira.codehaus.org/browse/MNG-5261 Project: Maven 2 3 Issue Type: Bug Components: Deployment Affects Versions: 3.0.4 Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 3.0.5 related to WAGON-369 -- 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] (WAGON-369) Maven deploy plugin doesn't follow HTTP 302 redirects
[
https://jira.codehaus.org/browse/WAGON-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294120#comment-294120
]
Olivier Lamy commented on WAGON-369:
feel free to make some tests with maven 3.0.5-SNAPSHOT available here
https://builds.apache.org/view/M-R/view/Maven/job/maven-3.0.x/
Let us know if you still have issues.
Maven deploy plugin doesn't follow HTTP 302 redirects
-
Key: WAGON-369
URL: https://jira.codehaus.org/browse/WAGON-369
Project: Maven Wagon
Issue Type: Bug
Affects Versions: 2.2
Reporter: James Baldassari
Assignee: Olivier Lamy
Fix For: 2.3
We have a reverse proxy server sitting in front of our Artifactory
repository. We've been running with this configuration for over a year with
no problems until we upgraded to Maven 3.0.4 and maven-deploy-plugin 2.7.
When deploying an artifact to a repository, if the request returns a 302
redirect, maven-deploy-plugin 2.7 does not follow the redirect and simply
fails. It seems like a regression was introduced in maven-deploy-plugin some
time after v2.5 (the default version used by Maven 3.0.3, which works). The
full stack trace follows:
{noformat}
[INFO] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
project myartifact: Failed to deploy artifacts: Could not transfer artifact
mycompany:myartifact:pom:4.4.4 from/to maven01
(http://maven.mycompany.net/libs-releases-local): Failed to transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found. - [Help 1]
[INFO] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
(default-deploy) on project myartifact: Failed to deploy artifacts: Could not
transfer artifact mycompany:myartifact:pom:4.4.4 from/to dxmaven01
(http://maven.mycompany.net/libs-releases-local): Failed to transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found.
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
[INFO]at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
[INFO]at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
[INFO]at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
[INFO]at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
[INFO]at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
[INFO]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO]at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[INFO]at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[INFO]at java.lang.reflect.Method.invoke(Method.java:597)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[INFO] Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
deploy artifacts: Could not transfer artifact mycompany:myartifact:pom:4.4.4
from/to dxmaven01 (http://maven.mycompany.net/libs-releases-local): Failed to
transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found.
[INFO]at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:193)
[INFO]at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
[jira] (MRELEASE-748) trailing whitespace is stripped from scmCommentPrefix
[ https://jira.codehaus.org/browse/MRELEASE-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294123#comment-294123 ] Dennis Lundberg commented on MRELEASE-748: -- Without looking at the code I think that this is not possible due to the XML parser. Whitespace inside elements are usually disposed of by the parser. Another way to solve this would be to insert an explicit space between the comment prefix and the actual commit message. trailing whitespace is stripped from scmCommentPrefix - Key: MRELEASE-748 URL: https://jira.codehaus.org/browse/MRELEASE-748 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.2.2 Environment: Any Reporter: Jakub Skoczen Priority: Minor When configuring custom scmCommentPrefix any trailing whitespaces are trimmed resulting in ugly commit mesages, eg: scmCommentPrefixMaven: /scmCommentPrefix Maven:prepare for next development iteration sCP should honor whitespaces -- 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] (MRELEASE-748) trailing whitespace is stripped from scmCommentPrefix
[ https://jira.codehaus.org/browse/MRELEASE-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-748. --- Resolution: Not A Bug Assignee: Robert Scholte To be precise: it's not a maven-release-plugin bug, so we can't fix it. It is caused by the way the pom.xml is parsed, so every xml-value within the pom has this problem. See PLX-461 for further details. Once fixed there we could add a FAQ-entry to upgrade to Maven X if you want to keep trailing whitespaces. That's all we can do. trailing whitespace is stripped from scmCommentPrefix - Key: MRELEASE-748 URL: https://jira.codehaus.org/browse/MRELEASE-748 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.2.2 Environment: Any Reporter: Jakub Skoczen Assignee: Robert Scholte Priority: Minor When configuring custom scmCommentPrefix any trailing whitespaces are trimmed resulting in ugly commit mesages, eg: scmCommentPrefixMaven: /scmCommentPrefix Maven:prepare for next development iteration sCP should honor whitespaces -- 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] (MRELEASE-748) trailing whitespace is stripped from scmCommentPrefix
[ https://jira.codehaus.org/browse/MRELEASE-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294127#comment-294127 ] Jakub Skoczen commented on MRELEASE-748: No sane XML parser will ever touch your trailing/leading whitespaces. Yes, you can call 'normalize' on a DOM document but that will only get rid of spurious text nodes -- entirely different story. Having said that, I have no idea whether Maven uses a sane XML parser. trailing whitespace is stripped from scmCommentPrefix - Key: MRELEASE-748 URL: https://jira.codehaus.org/browse/MRELEASE-748 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.2.2 Environment: Any Reporter: Jakub Skoczen Assignee: Robert Scholte Priority: Minor When configuring custom scmCommentPrefix any trailing whitespaces are trimmed resulting in ugly commit mesages, eg: scmCommentPrefixMaven: /scmCommentPrefix Maven:prepare for next development iteration sCP should honor whitespaces -- 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] (WAGON-370) Adding additional wagon provider as dependency does not work
[ https://jira.codehaus.org/browse/WAGON-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved MSITE-629 to WAGON-370: - Component/s: (was: site:deploy) wagon-webdav Affects Version/s: (was: 3.0) 2.2 Key: WAGON-370 (was: MSITE-629) Project: Maven Wagon (was: Maven 2.x and 3.x Site Plugin) Adding additional wagon provider as dependency does not work Key: WAGON-370 URL: https://jira.codehaus.org/browse/WAGON-370 Project: Maven Wagon Issue Type: Bug Components: wagon-webdav Affects Versions: 2.2 Environment: Mac OS 10.7.2, Apple Java 1.6.0_29, Maven 3.0.3/3.0.4 Windows XP, SUN Java 1.6.0_24, Maven 3.0.4 Reporter: Anders Hammar Attachments: console.txt, mvnsite-dav-dep-bug.zip According to http://maven.apache.org/plugins/maven-site-plugin/examples/adding-deploy-protocol.html is should be possible to add additional wagon provider as a dependency to the site plugin. For a project deploying via dav, doing so using the wagon-webdav-jackrabbit makes Maven through a NoClassDefFoundError. Of adding the wagon as a global extension it works. Not sure if this is a maven-site-plugin issue though, or possible something in the specific wagon. I'm attaching a test project as well as the console output showing the error. -- 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-2971) Variables are not replaced into installed pom file
[
https://jira.codehaus.org/browse/MNG-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294132#comment-294132
]
Gustavo Chaves commented on MNG-2971:
-
Hi. I noticed that MNG-4223, which is already related to this issue, seems to
be much more researched. Strictly speaking it is a restricted version of this,
because it cares only about the artifact coordinate tags with regards to
property expansion and not the whole POM. However, since the description of
this issue exemplifies the problem with the version tag I think that probably
the artifact coordinates are all this issue's reporter cares about.
Is that so?
If it is, I think it would be a good idea to close this issue marking it as a
duplicate of MNG-4223 in order to focus the efforts towards a solution.
Variables are not replaced into installed pom file
--
Key: MNG-2971
URL: https://jira.codehaus.org/browse/MNG-2971
Project: Maven 2 3
Issue Type: Bug
Components: Deployment, Inheritance and Interpolation
Environment: Windows, Solaris
Maven version 2.0.4
Reporter: Laurent Dauvilaire
Assignee: Ralph Goers
Fix For: Issues to be reviewed for 3.x
Attachments: pom.xml
Variables are not replaced into installed pom file.
Here is a sample pom file
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.xxx.root/groupId
artifactIdroot/artifactId
packagingpom/packaging
version${prop.version}/version
nameMy Project/name
...
properties
prop.version3.0.20/prop.version
/properties
/project
The installed pom is into
${localRepository}/com/xxx/root/root/3.0.20/root-3.0.20.pom
is the same as the project pom file but the version referenced into the
installed pom file is ${prop.version} instead of 3.0.20
which creates problem to artifacts depending of this one.
Thanks in advance
--
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-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294133#comment-294133 ] Gustavo Chaves commented on MNG-624: Hi. I propose to link this issue as dependent of (or at least related to) MNG-4223. It's the best researched open issue I could find regarding the need to expand properties in the artifact coordinate tags. (I think it's better researched than MNG-2971 which is already related to this issue.) automatic parent versioning --- Key: MNG-624 URL: https://jira.codehaus.org/browse/MNG-624 Project: Maven 2 3 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.1 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-5258) localRepository in settings.xml does not handle ~ as home.dir
[ https://jira.codehaus.org/browse/MNG-5258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNG-5258. --- Resolution: Fixed Fix Version/s: 3.0.5 Assignee: Robert Scholte (was: Olivier Lamy) Fixed in [rev. 1300694|http://svn.apache.org/viewvc?rev=1300694view=rev] localRepository in settings.xml does not handle ~ as home.dir - Key: MNG-5258 URL: https://jira.codehaus.org/browse/MNG-5258 Project: Maven 2 3 Issue Type: Bug Components: Bootstrap Build, Settings Affects Versions: 2.2.1, 3.0.4 Environment: Linux (Ubuntu 11.10), Java 6 Reporter: Thomas Zeeman Assignee: Robert Scholte Fix For: 3.0.5 My provided settings.xml contained a localRepository part with the value ~/.m2/repository and when invoking any maven command, this caused issues. Steps to reproduce: 1 - create a settings.xml with the following content: settings !-- localRepository | The path to the local repository maven will use to store artifacts. | | Default: ~/.m2/repository -- localRepository~/.m2/repository/localRepository /settings 2 - run mvn clean in an existing project 3 - maven will create a ~ directory in the project where it will download all artifacts to. Apart from essentially creating a private repository for each project (which can quickly take up way more space than necessary, cause issues about missing artifacts) it may also cause issues if you try to remove it and forget to escape the ~; ie if you do rm -rf ~ instead of rm -rf '~'. I also tested with maven 2.2.1 and that will blow up with errors about not being able to create /.m2/repository/some path to an artifact. Both 3.0.4 and 2.2.1 were downloaded from maven.apache.org, not installed via apt/dpkg. -- 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-5262) improve mvn dependency:tree - add optional xml output of the results
Kn Unk created MNG-5262: --- Summary: improve mvn dependency:tree - add optional xml output of the results Key: MNG-5262 URL: https://jira.codehaus.org/browse/MNG-5262 Project: Maven 2 3 Issue Type: Improvement Components: Command Line Affects Versions: 3.0.4 Environment: all Reporter: Kn Unk The output of mvn dependency:tree would be more useful to me if it was in a format that is machine readable. I would like to create some tooling to be able to easily determine what is causing a particular jar to be included. for example: mymvntool -why org.springframework:org.springframework.beans:3.0.5 org.springframework.beans-3.0.5 is being *dragged* in by: my.otherproject.core:1.1 %end of search another use: mymvntool -makeexclusionfor org.springframework:org.springframework.beans:3.0.5 exclusions exclusion groupIdorg.springframework/groupId artifactIdorg.springframework.beans/artifactId exclusion /exclusions or even: mymvntool -makeexclusionfor org.springframework:*:3.0.5 this would pickup all the included jars in the project and build exclusions for them. It may have been dumb to pick spring as the exclusion resource, but this is just an example. having xml output would be valuable to me and probably others too. -K -- 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] (WAGON-369) Maven deploy plugin doesn't follow HTTP 302 redirects
[
https://jira.codehaus.org/browse/WAGON-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294140#comment-294140
]
James Baldassari commented on WAGON-369:
Thanks very much! I'll try to find some time to test it out soon.
Maven deploy plugin doesn't follow HTTP 302 redirects
-
Key: WAGON-369
URL: https://jira.codehaus.org/browse/WAGON-369
Project: Maven Wagon
Issue Type: Bug
Affects Versions: 2.2
Reporter: James Baldassari
Assignee: Olivier Lamy
Fix For: 2.3
We have a reverse proxy server sitting in front of our Artifactory
repository. We've been running with this configuration for over a year with
no problems until we upgraded to Maven 3.0.4 and maven-deploy-plugin 2.7.
When deploying an artifact to a repository, if the request returns a 302
redirect, maven-deploy-plugin 2.7 does not follow the redirect and simply
fails. It seems like a regression was introduced in maven-deploy-plugin some
time after v2.5 (the default version used by Maven 3.0.3, which works). The
full stack trace follows:
{noformat}
[INFO] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
project myartifact: Failed to deploy artifacts: Could not transfer artifact
mycompany:myartifact:pom:4.4.4 from/to maven01
(http://maven.mycompany.net/libs-releases-local): Failed to transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found. - [Help 1]
[INFO] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
(default-deploy) on project myartifact: Failed to deploy artifacts: Could not
transfer artifact mycompany:myartifact:pom:4.4.4 from/to dxmaven01
(http://maven.mycompany.net/libs-releases-local): Failed to transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found.
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
[INFO]at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
[INFO]at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
[INFO]at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
[INFO]at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
[INFO]at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
[INFO]at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
[INFO]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO]at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[INFO]at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[INFO]at java.lang.reflect.Method.invoke(Method.java:597)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
[INFO]at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[INFO] Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
deploy artifacts: Could not transfer artifact mycompany:myartifact:pom:4.4.4
from/to dxmaven01 (http://maven.mycompany.net/libs-releases-local): Failed to
transfer file:
http://maven.mycompany.net/libs-releases-local/mycompany/myartifact/4.4.4/myartifact-4.4.4.pom.
Return code is: 302, ReasonPhrase:Found.
[INFO]at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:193)
[INFO]at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
[INFO]at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
[INFO]... 19 more
[INFO] Caused by:
[jira] (MRELEASE-358) CheckDependencySnapshotsPhase fails when resolving all dependencies
[
https://jira.codehaus.org/browse/MRELEASE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294149#comment-294149
]
Robert Scholte commented on MRELEASE-358:
-
The patch is not complete, it's missing the unversioned files. The code has
changed quite a lot since this issue was filed, so I can't say it's fixed by
only looking at the patch.
@Rich, could you confirm this is fixed? Otherwise attach the test with the
missing files.
If there's no response I'll have to close it as {{incomplete}}.
CheckDependencySnapshotsPhase fails when resolving all dependencies
---
Key: MRELEASE-358
URL: https://jira.codehaus.org/browse/MRELEASE-358
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0-beta-7
Reporter: Rich Seller
Attachments: patch.txt
In CheckDependencySnapshotsPhase, if '0' (All) is selected in response to the
prompt specify the selection number ... the dependencies are not removed
from the original set, so a ReleaseFailureException is thrown at the end of
checkProject().
In the attached patch the dependencies are removed from the original set, and
the snapshotSet is returned from resolveSnapshots() to be checked in
checkProject().
In the tests, I implemented a custom Prompter because I don't know how to set
multiple conditional responses on JMock1 mocks.
One other change made while testing: in processSnapshot, What is the next
development version? is set with a singleton list so a different value has
been entered. I removed the list to make the supplied value the default but
allow different responses. I can raise this as a separate issue if required
--
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-844) test parameter no longer working with JUnit in 2.12 (worked in 2.9 - 2.11)
[ https://jira.codehaus.org/browse/SUREFIRE-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294150#comment-294150 ] Scott Bartram commented on SUREFIRE-844: In my environment, this is broken on Windows but works on Mac. I haven't tested Linux yet. test parameter no longer working with JUnit in 2.12 (worked in 2.9 - 2.11) Key: SUREFIRE-844 URL: https://jira.codehaus.org/browse/SUREFIRE-844 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.12 Environment: JDK 1.7.0_02, Windows 7. Reporter: Mark Ziesemer Attachments: SUREFIRE-844-2.11.txt, SUREFIRE-844-2.12.txt, SUREFIRE-844.zip Maven is configured with JUnit 4.10. Assume a 'MyTest' class with public, non-static, 0-arg methods annotated with org.junit.Test. This was working with Surefire 2.9, 2.10, and 2.11 (and probably earlier): plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.11/version configuration testcom.example.MyTest/test /configuration /plugin With only updating the Surefire version from 2.11 to 2.12, the tests no longer execute: --- T E S T S --- Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 I don't see anything in the release announcement that should account for this. If I remove the 'test' parameter entirely, it will again successfully run - but will run all tests that it finds instead of what I'm expecting it to run. I can't attach any additional details from what I'm currently working on, but will work on providing a proper minimal test case over the weekend. -- 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] (MSHADE-107) ArrayIndexOutOfBoundsException when using minimizeJar with shade plugin
[
https://jira.codehaus.org/browse/MSHADE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294155#comment-294155
]
Shane StClair commented on MSHADE-107:
--
I get a slightly different ArrayIndexOutOfBoundsException, but I believe the
example pom I attached illustrates the same problem. It looks like dependencies
with malformed classes will trip up the asm ClassReader. See similar problem
here:
http://jira.codehaus.org/browse/MANIMALSNIFFER-9
Maybe the best solution is just to catch the ArrayIndexOutOfBoundsException and
not include the problem dependencies in the list of candidate classes to be
removed?
ArrayIndexOutOfBoundsException when using minimizeJar with shade plugin
---
Key: MSHADE-107
URL: https://jira.codehaus.org/browse/MSHADE-107
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.5
Environment: Apache Maven 2.2.1 (rdebian-1)
Java version: 1.6.0_26
Reporter: Thomas Kruse
Labels: moreinfo
Attachments: pom.xml
The shade plugin fails with error message
{code}
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error creating shaded jar: 26
{code}
Running maven with -e on the project yields
{code}
[ERROR] BUILD ERROR
[INFO]
[INFO] Error creating shaded jar: 26
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error creating shaded
jar: 26
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: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)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating
shaded jar: 26
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:503)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: 26
at org.objectweb.asm.ClassReader.readClass(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.vafer.jdependency.Clazzpath.addClazzpathUnit(Clazzpath.java:94)
at
org.apache.maven.plugins.shade.filter.MinijarFilter.init(MinijarFilter.java:74)
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.getFilters(ShadeMojo.java:696)
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:438)
... 19 more
{code}
The failing module is part of a multi module build, has a quite large number
of transitive dependencies.
--
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] (MSHADE-107) ArrayIndexOutOfBoundsException when using minimizeJar with shade plugin
[
https://jira.codehaus.org/browse/MSHADE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294156#comment-294156
]
Shane StClair commented on MSHADE-107:
--
Also, it might be worth noting that it seems like the offending array index is
usually restricted to specific values (48188 and 26 are the only ones I've seen
so far), so maybe only these values should be trapped?
ArrayIndexOutOfBoundsException when using minimizeJar with shade plugin
---
Key: MSHADE-107
URL: https://jira.codehaus.org/browse/MSHADE-107
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.5
Environment: Apache Maven 2.2.1 (rdebian-1)
Java version: 1.6.0_26
Reporter: Thomas Kruse
Labels: moreinfo
Attachments: pom.xml
The shade plugin fails with error message
{code}
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error creating shaded jar: 26
{code}
Running maven with -e on the project yields
{code}
[ERROR] BUILD ERROR
[INFO]
[INFO] Error creating shaded jar: 26
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error creating shaded
jar: 26
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: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)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating
shaded jar: 26
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:503)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: 26
at org.objectweb.asm.ClassReader.readClass(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.vafer.jdependency.Clazzpath.addClazzpathUnit(Clazzpath.java:94)
at
org.apache.maven.plugins.shade.filter.MinijarFilter.init(MinijarFilter.java:74)
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.getFilters(ShadeMojo.java:696)
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:438)
... 19 more
{code}
The failing module is part of a multi module build, has a quite large number
of transitive dependencies.
--
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] (MANTTASKS-174) Mirror declaration replaces url from distributionManagement
[
https://jira.codehaus.org/browse/MANTTASKS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=294159#comment-294159
]
Jonathan Kinred commented on MANTTASKS-174:
---
This is a quite annoying problem especially as many people would be using
Nexus/Artifactory and would therefore have a mirror section in settings.xml.
Will you accept a patch for this?
Mirror declaration replaces url from distributionManagement
---
Key: MANTTASKS-174
URL: https://jira.codehaus.org/browse/MANTTASKS-174
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Components: deploy task
Affects Versions: 2.1.0
Environment: Ant 1.7.1, Maven ant tasks 2.1.0
Reporter: Robert Munteanu
Given a ~/.m2/settings.xml file containing a mirror element
{code}
mirrors
mirror
idnexus/id
mirrorOfexternal:*/mirrorOf
urlhttps://xxx.com/nexus/content/groups/public/url
/mirror
/mirrors
{code}
a pom.xml file with a distributionManagement section
{code}
distributionManagement
snapshotRepository
idsonatype-nexus-snapshots/id
nameSonatype Nexus Snapshots/name
urlhttp://oss.sonatype.org/content/repositories/snapshots/url
/snapshotRepository
/distributionManagement
{code}
and a build.xml file with the following deploy task:
{code}
target name=deploy depends=-check
artifact:pom id=gin-pom file=pom.xml /
artifact:deploy file=${gin.jar.file}
pom refid=gin-pom /
attach file=${gin.javadoc.file} classifier=javadoc
/
/artifact:deploy
/target
{code}
When running ant deploy the deployment is done on xxx.com instead of
oss.sonatype.org . Removing the mirror from the settings file solves 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] (MSHADE-107) ArrayIndexOutOfBoundsException when using minimizeJar with shade plugin
[
https://jira.codehaus.org/browse/MSHADE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane StClair updated MSHADE-107:
-
Attachment: mshade-107.patch
Suggested patch, implemented as described above.
ArrayIndexOutOfBoundsException when using minimizeJar with shade plugin
---
Key: MSHADE-107
URL: https://jira.codehaus.org/browse/MSHADE-107
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.5
Environment: Apache Maven 2.2.1 (rdebian-1)
Java version: 1.6.0_26
Reporter: Thomas Kruse
Labels: moreinfo
Attachments: mshade-107.patch, pom.xml
The shade plugin fails with error message
{code}
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error creating shaded jar: 26
{code}
Running maven with -e on the project yields
{code}
[ERROR] BUILD ERROR
[INFO]
[INFO] Error creating shaded jar: 26
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error creating shaded
jar: 26
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: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)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating
shaded jar: 26
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:503)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: java.lang.ArrayIndexOutOfBoundsException: 26
at org.objectweb.asm.ClassReader.readClass(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.vafer.jdependency.Clazzpath.addClazzpathUnit(Clazzpath.java:94)
at
org.apache.maven.plugins.shade.filter.MinijarFilter.init(MinijarFilter.java:74)
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.getFilters(ShadeMojo.java:696)
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:438)
... 19 more
{code}
The failing module is part of a multi module build, has a quite large number
of transitive dependencies.
--
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
