[jira] (MNGSITE-201) Broken links under public repositories FAQ item
[ https://jira.codehaus.org/browse/MNGSITE-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar closed MNGSITE-201. - Resolution: Fixed Thanks for the report! Non-working items removed and site updated (sync pending currently). Broken links under public repositories FAQ item - Key: MNGSITE-201 URL: https://jira.codehaus.org/browse/MNGSITE-201 Project: Maven Project Web Site Issue Type: Bug Environment: Safari on OS X 10.9 Reporter: Andrew Janke Assignee: Anders Hammar Priority: Minor Under the FAQ (Official) page at https://maven.apache.org/general.html, the last item, How to find dependencies on public Maven repositories?, has some links that are broken for me. www.artifact-repository.org is not responding to HTML requests, though it resolves via DNS. www.mvnbrowser.com now redirects to a rotating list of junk or content farm sites, apparently run by parkingcrew.com, based on some dnslookup and whois research. www.jarvana.com is dead. (See http://jarvana.blogspot.com/2013/08/goodbye-jarvana.html). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5523) support actual incremental build
[
https://jira.codehaus.org/browse/MNG-5523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=343998#comment-343998
]
Anders Hammar commented on MNG-5523:
Jason and Igor is working on this in a separate library. It is still not
finalized, but you can read more on his blog:
http://takari.io/2014/03/25/incremental-build.html
support actual incremental build
Key: MNG-5523
URL: https://jira.codehaus.org/browse/MNG-5523
Project: Maven 2 3
Issue Type: Improvement
Components: Bootstrap Build, Performance
Reporter: Jigar Joshi
h2. Background:
We have project structure of around 200 project in the maven tree, every
single build takes around 13 minute of time (clean, compile, test install,
deploy)
With current version of maven {{3.1}}, you can skip clean phase and it will
do incremental build, which is not bullet proof incremental build actually
h2. Problem example
{code}
--root (module)
\
|
|---foo (jar project)
|
|---bar (jar project, it consumes foo as dependency)
{code}
before
{code}
public class Foo{
public static void sayHello(){
System.out.println(hello from foo);
}
}
public class Bar{
public static void main(String arg[]){
Foo.sayHello();
}
}
{code}
I do {{mvn clean install}} from root module, it would go successful, I launch
the {{main()}} method of {{Bar}} now, it will be succesful
now I modify {{sayHello()}} to
{code}
public static void sayHello(String name){
System.out.println(hello from foo to + name);
}
{code}
and I execute {{mvn install}} (incremental build) from root module, it will
still compile and execute successfully because it takes previously built
artifact for {{Foo}} at compile phase, now if I attempt to run it in IDE or
in a packaged build it will fail with
{code}
Exception in thread main java.lang.NoSuchMethodError:
{code}
h2. Proposal:
- somewhere in pre execution phase, it needs to calculate the modified
source and artifacts and it should be able to detect all the consumers in
dependency tree (compile, runtime, test all scopes) and flag all the
artifacts to treat as modified and it should re do build for those
- all the maven plugins should support incremental build as well
- plugin needs to be marked to execute incrementally by adding a {{boolean}}
parameter to {{AbstractMOJO}} to declare that plugin execution needs to be
calculated in effective incremental way
- all plugins which are marked as {{incremental}} needs to take the same
approach as mentioned in first point
- also in parallel build when it fans out in multiple threads it should have
knowledge of what plugins to execute effectively
It would be totally useful to have this feature corrected
Some other people who wants this as well
- http://stackoverflow.com/questions/6281699/maven-incremental-building
-
http://stackoverflow.com/questions/8918165/does-maven-support-incremental-builds
*Also See*
- http://jira.codehaus.org/browse/MCOMPILER-213
-
http://blog.jetbrains.com/teamcity/2012/03/incremental-building-with-maven-and-teamcity/
Thanks!
Jigar
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-871) Release Tag wrongly created when invoked pom.xml path contains a '.'
[
https://jira.codehaus.org/browse/MRELEASE-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gertjan Gaillet updated MRELEASE-871:
-
Description:
*Issue*
When invoking the maven release plugin on a pom.xml referenced by a path
including a '.', the release tag created is incorrect.
Example: mvn clean release:clean release:prepare release:perform \[options\] -f
./pom.xml
This is true for both modular and hierarchical projects:
{code}/parent-pom/pom.xml
/module-a/pom.xml
/module-b/pom.xml{code}
and
{code}/pom.xml -- this is the parent pom
/module-a/pom.xml
/module-b/pom.xml{code}
When releasing projects with either structure, invoking maven with -f
./parent-pom/pom.xml and -f ./pom.xml respectively, the tag operation copies
from one level too high. For example if the svn structure is as follows:
{code}/trunk (at v 1.0.0-SNAPSHOT)
/branches/project-0.1.x (at v 0.1.0-SNAPSHOT)
/branches/project-0.2.x (at v 0.2.0-SNAPSHOT)
/tags/project-0.1.0{code}
and a release is being made from trunk, the tag project-1.0.0 would contain the
complete svn structure. When a release is being made from
/branches/project-0.1.x, the tag project-0.1.0 would contain the two branches:
{code}/branches/project-0.1.x
/branches/project-0.2.x{code}
*Root cause*
After some debugging, I've found that the issue is caused by function
getBaseWorkingDirectoryParentCount in
org.apache.maven.shared.release.util.ReleaseUtil.
I've created a patch (for trunk and 2.5), as attached, and tested it
successfully on Windows7 and RHEL, with jdk1.6.0_26 and maven 3.0.4.
Let me know if the patch is OK (we are currently using it without any issue,
and resolving this bug) and I'll commit it accordingly.
was:
*Issue*
When invoking the maven release plugin on a pom.xml referenced by a path
including a '.', the release tag created is incorrect.
Example: mvn clean release:clean release:prepare release:perform \[options\] -f
./pom.xml
This is true for both modular and hierarchical projects:
{code}/parent-pom/pom.xml
/module-a/pom.xml
/module-b/pom.xml{code}
and
{code}/pom.xml -- this is the parent pom
/module-a/pom.xml
/module-b/pom.xml{code}
When releasing projects with either structure, invoking maven with -f
./parent-pom/pom.xml and -f ./pom.xml respectively, the tag operation copies
from one level too high. For example if the svn structure is as follows:
{code}/trunk (at v 1.0.0-SNAPSHOT)
/branches/project-0.1.x (at v 0.1.0-SNAPSHOT)
/branches/project-0.2.x (at v 0.2.0-SNAPSHOT)
/tags/project-0.1.0{code}
and a release is being made from trunk, the tag project-1.0.0 would contain the
complete svn structure. When a release is being made from
/branches/project-0.1.x, the tag project-0.1.0 would contain the two branches:
{code}/branches/project-0.1.x
/branches/project-0.2.x{code}
*Root cause*
After some debugging, I've found that the issue is caused by function
getBaseWorkingDirectoryParentCount in
org.apache.maven.shared.release.util.ReleaseUtil.
I've created a patch, as attached, and tested it successfully on Windows7 and
RHEL, with jdk1.6.0_26.
Let me know if the patch is OK (we are currently using it without any issue,
and resolving this bug) and I'll commit it accordingly.
Release Tag wrongly created when invoked pom.xml path contains a '.'
Key: MRELEASE-871
URL: https://jira.codehaus.org/browse/MRELEASE-871
Project: Maven Release Plugin
Issue Type: Bug
Components: perform, scm
Affects Versions: 2.5
Environment: RHEL Linux, Windows 7, most probably others
Reporter: Gertjan Gaillet
Attachments: ReleaseUtil.java.patch
*Issue*
When invoking the maven release plugin on a pom.xml referenced by a path
including a '.', the release tag created is incorrect.
Example: mvn clean release:clean release:prepare release:perform \[options\]
-f ./pom.xml
This is true for both modular and hierarchical projects:
{code}/parent-pom/pom.xml
/module-a/pom.xml
/module-b/pom.xml{code}
and
{code}/pom.xml -- this is the parent pom
/module-a/pom.xml
/module-b/pom.xml{code}
When releasing projects with either structure, invoking maven with -f
./parent-pom/pom.xml and -f ./pom.xml respectively, the tag operation
copies from one level too high. For example if the svn structure is as
follows:
{code}/trunk (at v 1.0.0-SNAPSHOT)
/branches/project-0.1.x (at v 0.1.0-SNAPSHOT)
/branches/project-0.2.x (at v 0.2.0-SNAPSHOT)
/tags/project-0.1.0{code}
and a release is being made from trunk, the tag project-1.0.0 would contain
the complete svn structure. When a release is being made from
/branches/project-0.1.x, the tag project-0.1.0 would contain the two branches:
{code}/branches/project-0.1.x
/branches/project-0.2.x{code}
*Root cause*
After some debugging, I've found that the issue
[jira] (MRELEASE-871) Release Tag wrongly created when invoked pom.xml path contains a '.'
Gertjan Gaillet created MRELEASE-871:
Summary: Release Tag wrongly created when invoked pom.xml path
contains a '.'
Key: MRELEASE-871
URL: https://jira.codehaus.org/browse/MRELEASE-871
Project: Maven Release Plugin
Issue Type: Bug
Components: perform, scm
Affects Versions: 2.5
Environment: RHEL Linux, Windows 7, most probably others
Reporter: Gertjan Gaillet
Attachments: ReleaseUtil.java.patch
*Issue*
When invoking the maven release plugin on a pom.xml referenced by a path
including a '.', the release tag created is incorrect.
Example: mvn clean release:clean release:prepare release:perform \[options\] -f
./pom.xml
This is true for both modular and hierarchical projects:
{code}/parent-pom/pom.xml
/module-a/pom.xml
/module-b/pom.xml{code}
and
{code}/pom.xml -- this is the parent pom
/module-a/pom.xml
/module-b/pom.xml{code}
When releasing projects with either structure, invoking maven with -f
./parent-pom/pom.xml and -f ./pom.xml respectively, the tag operation copies
from one level too high. For example if the svn structure is as follows:
{code}/trunk (at v 1.0.0-SNAPSHOT)
/branches/project-0.1.x (at v 0.1.0-SNAPSHOT)
/branches/project-0.2.x (at v 0.2.0-SNAPSHOT)
/tags/project-0.1.0{code}
and a release is being made from trunk, the tag project-1.0.0 would contain the
complete svn structure. When a release is being made from
/branches/project-0.1.x, the tag project-0.1.0 would contain the two branches:
{code}/branches/project-0.1.x
/branches/project-0.2.x{code}
*Root cause*
After some debugging, I've found that the issue is caused by function
getBaseWorkingDirectoryParentCount in
org.apache.maven.shared.release.util.ReleaseUtil.
I've created a patch, as attached, and tested it successfully on Windows7 and
RHEL, with jdk1.6.0_26.
Let me know if the patch is OK (we are currently using it without any issue,
and resolving this bug) and I'll commit it accordingly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-144) Using compiler API instead of tools.jar
[ https://jira.codehaus.org/browse/MCOMPILER-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=344028#comment-344028 ] Jesse Glick commented on MCOMPILER-144: --- I guess so. It would still be great for the OpenJDK compiler to be published in Central somehow, and a ?compiler plugin plugin? implementation published which uses it. Ideally this would be coördinated somehow with the OpenJDK tools team so it is considered an official build, though this might get into thorny TCK territory. Using compiler API instead of tools.jar --- Key: MCOMPILER-144 URL: https://jira.codehaus.org/browse/MCOMPILER-144 Project: Maven Compiler Plugin Issue Type: New Feature Reporter: Markus KARG Priority: Minor Currently (MVN 3.0) java compilation needs tools.jar provided by the Sun JDK: [ERROR] Unable to locate the Javac Compiler in: [ERROR] C:\Program Files\Java\jre6\..\lib\tools.jar [ERROR] Please ensure you are using JDK 1.4 or above and [ERROR] not a JRE (the com.sun.tools.javac.Main class is required). [ERROR] In most cases you can change the location of your Java [ERROR] installation by setting the JAVA_HOME environment variable. In fact, this is bad because (a) it assumes that a full JDK is installed just for this sole tool where a JRE would be sufficient, (b) tools.jar is not contained in any standards documents and such possibly is not existing on future or non-sun JDK. Since JRE 6 (i. e. for many years) the JRE (not JDK!) comes with a standardized (!) API for compilation: The Java Compiler API. It would make sense to use that standardized API instead of forcing the user to have Sun JDK installed. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-225) javac.bat and args file added to archive when fork and -X used
Jeffrey Hagelberg created MCOMPILER-225: --- Summary: javac.bat and args file added to archive when fork and -X used Key: MCOMPILER-225 URL: https://jira.codehaus.org/browse/MCOMPILER-225 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 3.1, 2.3.2 Environment: Windows 7 x64 Reporter: Jeffrey Hagelberg When you compile a java project with -X flag and forktrue/fork in the maven-compiler-plugin configuration, the following extra files are written to target\classes and bundled in the root directory of the jar: javac.bat org.codehaus.plexus.compiler.javac.JavacCompiler8515975925044691799arguments The precise name of the arguments file varies from build to build. The exact configuration we are using is: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.1/version configuration source1.6/source target1.6/target forktrue/fork showDeprecationtrue/showDeprecation showWarningstrue/showWarnings /configuration /plugin We originally saw this in version 2.3.2 of the maven-compiler-plugin. I've verified that it also occurs in version 3.1. We are able to work around this issue by setting fork to false. This can be reproduced in any maven java project. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-104) JAVA_HOME pointing to JDK but /usr/lib/java/../lib/tools.jar being used
[
https://jira.codehaus.org/browse/MCOMPILER-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=344029#comment-344029
]
Anders Hammar commented on MCOMPILER-104:
-
Is this a problem with plugin v3.0+? If not it should be closed.
JAVA_HOME pointing to JDK but /usr/lib/java/../lib/tools.jar being used
-
Key: MCOMPILER-104
URL: https://jira.codehaus.org/browse/MCOMPILER-104
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 2.0.2
Environment: Linux sombriks 2.6.24.5-smp #2 SMP Wed Apr 30 13:41:38
CDT 2008 i686 Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz GenuineIntel
GNU/Linux
java version 1.6.0_10
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)
echo $JAVA_HOME
/usr/lib/java
which javac
/usr/lib/java/bin/javac
Reporter: sombriks
using command line or netbeans plugin it's happening:
leonardo@sombriks:~/NetBeansProjects/arena/arena-client$ mvn compile
[INFO] Scanning for projects...
[INFO]
[INFO] Building Arena PUJ Client (jar)
[INFO]task-segment: [compile]
[INFO]
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (ISO-8859-1 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 1 source file to
/home/leonardo/NetBeansProjects/arena/arena-client/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
Unable to locate the Javac Compiler in:
/usr/lib/java/../lib/tools.jar
Please ensure you are using JDK 1.4 or above and
not a JRE (the com.sun.tools.javac.Main class is required).
In most cases you can change the location of your Java
installation by setting the JAVA_HOME environment variable.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 3 seconds
[INFO] Finished at: Wed Aug 19 11:10:59 BRT 2009
[INFO] Final Memory: 9M/65M
[INFO]
leonardo@sombriks:~/NetBeansProjects/arena/arena-client$
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-225) javac.bat and args file added to archive when fork and -X used
[ https://jira.codehaus.org/browse/MCOMPILER-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeffrey Hagelberg updated MCOMPILER-225: Description: When you compile a java project with -X flag and forktrue/fork in the maven-compiler-plugin configuration, the following extra files are written to target\classes and bundled in the root directory of the jar: javac.bat org.codehaus.plexus.compiler.javac.JavacCompiler8515975925044691799arguments The precise name of the arguments file varies from build to build. The exact configuration we are using is: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.1/version configuration source1.6/source target1.6/target forktrue/fork showDeprecationtrue/showDeprecation showWarningstrue/showWarnings /configuration /plugin We originally saw this in version 2.3.2 of the maven-compiler-plugin. I've verified that it also occurs in version 3.1. We are able to work around this issue by setting fork to false. This can be reproduced in any maven java project. The issue also only occurs when the -X maven option is used to enable debug output. was: When you compile a java project with -X flag and forktrue/fork in the maven-compiler-plugin configuration, the following extra files are written to target\classes and bundled in the root directory of the jar: javac.bat org.codehaus.plexus.compiler.javac.JavacCompiler8515975925044691799arguments The precise name of the arguments file varies from build to build. The exact configuration we are using is: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.1/version configuration source1.6/source target1.6/target forktrue/fork showDeprecationtrue/showDeprecation showWarningstrue/showWarnings /configuration /plugin We originally saw this in version 2.3.2 of the maven-compiler-plugin. I've verified that it also occurs in version 3.1. We are able to work around this issue by setting fork to false. This can be reproduced in any maven java project. javac.bat and args file added to archive when fork and -X used -- Key: MCOMPILER-225 URL: https://jira.codehaus.org/browse/MCOMPILER-225 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 2.3.2, 3.1 Environment: Windows 7 x64 Reporter: Jeffrey Hagelberg When you compile a java project with -X flag and forktrue/fork in the maven-compiler-plugin configuration, the following extra files are written to target\classes and bundled in the root directory of the jar: javac.bat org.codehaus.plexus.compiler.javac.JavacCompiler8515975925044691799arguments The precise name of the arguments file varies from build to build. The exact configuration we are using is: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.1/version configuration source1.6/source target1.6/target forktrue/fork showDeprecationtrue/showDeprecation showWarningstrue/showWarnings /configuration /plugin We originally saw this in version 2.3.2 of the maven-compiler-plugin. I've verified that it also occurs in version 3.1. We are able to work around this issue by setting fork to false. This can be reproduced in any maven java project. The issue also only occurs when the -X maven option is used to enable debug output. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-225) javac.bat and args file added to archive when fork and -X used
[ https://jira.codehaus.org/browse/MCOMPILER-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeffrey Hagelberg updated MCOMPILER-225: Description: When you compile a java project with -X maven option and forktrue/fork in the maven-compiler-plugin configuration, the following extra files are written to target\classes and bundled in the root directory of the jar: javac.bat org.codehaus.plexus.compiler.javac.JavacCompiler8515975925044691799arguments The precise name of the arguments file varies from build to build. The exact configuration we are using is: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.1/version configuration source1.6/source target1.6/target forktrue/fork showDeprecationtrue/showDeprecation showWarningstrue/showWarnings /configuration /plugin We originally saw this in version 2.3.2 of the maven-compiler-plugin. I've verified that it also occurs in version 3.1. We are able to work around this issue by setting fork to false. The issue also does not occur if -X is not used. This can be reproduced in any maven java project. was: When you compile a java project with -X flag and forktrue/fork in the maven-compiler-plugin configuration, the following extra files are written to target\classes and bundled in the root directory of the jar: javac.bat org.codehaus.plexus.compiler.javac.JavacCompiler8515975925044691799arguments The precise name of the arguments file varies from build to build. The exact configuration we are using is: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.1/version configuration source1.6/source target1.6/target forktrue/fork showDeprecationtrue/showDeprecation showWarningstrue/showWarnings /configuration /plugin We originally saw this in version 2.3.2 of the maven-compiler-plugin. I've verified that it also occurs in version 3.1. We are able to work around this issue by setting fork to false. This can be reproduced in any maven java project. The issue also only occurs when the -X maven option is used to enable debug output. javac.bat and args file added to archive when fork and -X used -- Key: MCOMPILER-225 URL: https://jira.codehaus.org/browse/MCOMPILER-225 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 2.3.2, 3.1 Environment: Windows 7 x64 Reporter: Jeffrey Hagelberg When you compile a java project with -X maven option and forktrue/fork in the maven-compiler-plugin configuration, the following extra files are written to target\classes and bundled in the root directory of the jar: javac.bat org.codehaus.plexus.compiler.javac.JavacCompiler8515975925044691799arguments The precise name of the arguments file varies from build to build. The exact configuration we are using is: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.1/version configuration source1.6/source target1.6/target forktrue/fork showDeprecationtrue/showDeprecation showWarningstrue/showWarnings /configuration /plugin We originally saw this in version 2.3.2 of the maven-compiler-plugin. I've verified that it also occurs in version 3.1. We are able to work around this issue by setting fork to false. The issue also does not occur if -X is not used. This can be reproduced in any maven java project. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-144) Using compiler API instead of tools.jar
[ https://jira.codehaus.org/browse/MCOMPILER-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=344033#comment-344033 ] Anders Hammar commented on MCOMPILER-144: - @David: I think this was fixed as part of MCOMPILER-184. Using compiler API instead of tools.jar --- Key: MCOMPILER-144 URL: https://jira.codehaus.org/browse/MCOMPILER-144 Project: Maven Compiler Plugin Issue Type: New Feature Reporter: Markus KARG Priority: Minor Currently (MVN 3.0) java compilation needs tools.jar provided by the Sun JDK: [ERROR] Unable to locate the Javac Compiler in: [ERROR] C:\Program Files\Java\jre6\..\lib\tools.jar [ERROR] Please ensure you are using JDK 1.4 or above and [ERROR] not a JRE (the com.sun.tools.javac.Main class is required). [ERROR] In most cases you can change the location of your Java [ERROR] installation by setting the JAVA_HOME environment variable. In fact, this is bad because (a) it assumes that a full JDK is installed just for this sole tool where a JRE would be sufficient, (b) tools.jar is not contained in any standards documents and such possibly is not existing on future or non-sun JDK. Since JRE 6 (i. e. for many years) the JRE (not JDK!) comes with a standardized (!) API for compilation: The Java Compiler API. It would make sense to use that standardized API instead of forcing the user to have Sun JDK installed. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-144) Using compiler API instead of tools.jar
[ https://jira.codehaus.org/browse/MCOMPILER-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar closed MCOMPILER-144. --- Resolution: Fixed Using compiler API instead of tools.jar --- Key: MCOMPILER-144 URL: https://jira.codehaus.org/browse/MCOMPILER-144 Project: Maven Compiler Plugin Issue Type: New Feature Reporter: Markus KARG Priority: Minor Currently (MVN 3.0) java compilation needs tools.jar provided by the Sun JDK: [ERROR] Unable to locate the Javac Compiler in: [ERROR] C:\Program Files\Java\jre6\..\lib\tools.jar [ERROR] Please ensure you are using JDK 1.4 or above and [ERROR] not a JRE (the com.sun.tools.javac.Main class is required). [ERROR] In most cases you can change the location of your Java [ERROR] installation by setting the JAVA_HOME environment variable. In fact, this is bad because (a) it assumes that a full JDK is installed just for this sole tool where a JRE would be sufficient, (b) tools.jar is not contained in any standards documents and such possibly is not existing on future or non-sun JDK. Since JRE 6 (i. e. for many years) the JRE (not JDK!) comes with a standardized (!) API for compilation: The Java Compiler API. It would make sense to use that standardized API instead of forcing the user to have Sun JDK installed. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHADE-120) createSourceJar does not include sources from current module
[
https://jira.codehaus.org/browse/MSHADE-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=344053#comment-344053
]
Matt Benson commented on MSHADE-120:
Sounds like this should be resolved {{INVALID}}
createSourceJar does not include sources from current module
Key: MSHADE-120
URL: https://jira.codehaus.org/browse/MSHADE-120
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 1.6
Reporter: Saurabh Ajmera
Attachments: maven-shade-problem-solution.zip, maven-shade-problem.zip
{quote}
In such case the best approach is to create an issue with a sample project
to reproduce the trouble .
And the best of the best attaching a patch which fix the issue :-)
--
Olivier
Le 25 mai 2012 17:40, Saurabh Ajmera sajm...@usc.edu a écrit :
Hi,
Is there anyone using the shade plugin? are you facing this issue?
On May 22, 2012, at 11:06 AM, Saurabh Ajmera wrote:
Hi,
I am using the maven shade plugin to produce a jar which includes
contents of one dependency artifact plus the contents of my current maven
module, such that the contents of my maven module override the files with
the same name in the dependency jar.
The shade plugin generates the jar file correctly as needed. However,
the source files from the current maven modules does not get included in
the generated source jar. Am I doing something wrong?
Following is the extract from my pom.xml
{code:xml}
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-shade-plugin/artifactId
version${maven.shade.plugin.version}/version
configuration
createSourcesJartrue/createSourcesJar
artifactSet
includes
include
org.kuali.rice:rice-impl
/include
/includes
/artifactSet
/configuration
executions
execution
phasepackage/phase
goals
goalshade/goal
/goals
/execution
/executions
/plugin
/plugins
{code}
Thank you,
Saurabh Ajmera.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHADE-78) Possibility to rename classes, e.g. to define a name prefix, to avoid classes with same names
[
https://jira.codehaus.org/browse/MSHADE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=344055#comment-344055
]
Matt Benson commented on MSHADE-78:
---
Note that you _can_ rename classes, if a bit clumsily, by specifying e.g.:
{code}
relocation
patterncom.example.foo./pattern
shadedPatterncom.uber._foo.__/shadedPattern
/relocation
{code}
I do agree that there should be some mechanism for smarter relocations. It's
very likely that someone well-versed in the art of Maven plugin configuration
customization could figure out a way to direct the {{ShadeMojo}} to, e.g., use
a custom {{Relocator}} implementation specified by the user.
Possibility to rename classes, e.g. to define a name prefix, to avoid classes
with same names
-
Key: MSHADE-78
URL: https://jira.codehaus.org/browse/MSHADE-78
Project: Maven Shade Plugin
Issue Type: New Feature
Reporter: Tim Ducheyne
Priority: Minor
It would be nice if there was an option to, next to relocating the classes,
also rename them, for example by giving them a certain prefix.
Suppose you bundle a third-party lib in your own lib. Suppose a project uses
your lib and also uses the third-party lib. If you then start looking up
classes in your IDE, 2 classes with the same name (but different package)
will pop-up.
Renaming them would avoid this.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-871) Release Tag wrongly created when invoked pom.xml path contains a '.'
[
https://jira.codehaus.org/browse/MRELEASE-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=344054#comment-344054
]
Robert Scholte commented on MRELEASE-871:
-
Hi,
first of all: thanks for the patch. It's a start, but I don't think it's
correct yet.
When handling directories, you should also be aware of the following:
- a directoryName can also start with a dot ( /a/b/c/.hiddendirectory )
- two dots means one directory back. ( /a/b/../b/c )
If you write expand the
{{org.apache.maven.shared.release.util.ReleaseUtilTest}} with these usecases,
you'll see that your fix isn't complete.
I think that if you wrap workingDirectory (and basedir?) with
{{org.codehaus.plexus.util.FileUtils.normalize(String)}} it should already be
better.
Release Tag wrongly created when invoked pom.xml path contains a '.'
Key: MRELEASE-871
URL: https://jira.codehaus.org/browse/MRELEASE-871
Project: Maven Release Plugin
Issue Type: Bug
Components: perform, scm
Affects Versions: 2.5
Environment: RHEL Linux, Windows 7, most probably others
Reporter: Gertjan Gaillet
Attachments: ReleaseUtil.java.patch
*Issue*
When invoking the maven release plugin on a pom.xml referenced by a path
including a '.', the release tag created is incorrect.
Example: mvn clean release:clean release:prepare release:perform \[options\]
-f ./pom.xml
This is true for both modular and hierarchical projects:
{code}/parent-pom/pom.xml
/module-a/pom.xml
/module-b/pom.xml{code}
and
{code}/pom.xml -- this is the parent pom
/module-a/pom.xml
/module-b/pom.xml{code}
When releasing projects with either structure, invoking maven with -f
./parent-pom/pom.xml and -f ./pom.xml respectively, the tag operation
copies from one level too high. For example if the svn structure is as
follows:
{code}/trunk (at v 1.0.0-SNAPSHOT)
/branches/project-0.1.x (at v 0.1.0-SNAPSHOT)
/branches/project-0.2.x (at v 0.2.0-SNAPSHOT)
/tags/project-0.1.0{code}
and a release is being made from trunk, the tag project-1.0.0 would contain
the complete svn structure. When a release is being made from
/branches/project-0.1.x, the tag project-0.1.0 would contain the two branches:
{code}/branches/project-0.1.x
/branches/project-0.2.x{code}
*Root cause*
After some debugging, I've found that the issue is caused by function
getBaseWorkingDirectoryParentCount in
org.apache.maven.shared.release.util.ReleaseUtil.
I've created a patch (for trunk and 2.5), as attached, and tested it
successfully on Windows7 and RHEL, with jdk1.6.0_26 and maven 3.0.4.
Let me know if the patch is OK (we are currently using it without any issue,
and resolving this bug) and I'll commit it accordingly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-555) update versions does not update intermodule dependencies
[ https://jira.codehaus.org/browse/MRELEASE-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MRELEASE-555: Patch Submitted: Yes update versions does not update intermodule dependencies Key: MRELEASE-555 URL: https://jira.codehaus.org/browse/MRELEASE-555 Project: Maven Release Plugin Issue Type: Bug Components: update-versions Affects Versions: 2.0 Environment: Maven 2.2.1, JDK 6, XP SP3 Reporter: Michael Osipov Attachments: MRELEASE-555.patch I recently tried the update-versions goal which is really nice and worked well. I cleaned my local repo today and reran mvn package on a multi-module project. It failed due tue a depenceny error. My project was previously on version 2.6.1-SNAPSHOT. Module war depends on module jar with the same version. When doing a release:prepare, the plugin perfectly bumps this intermodule dependency. The release:update-versions missed that dep spot. My build process failed. The goal should crawl for those deps too and update them if autoVersionSubmodules is on. (Same behavior as the prepare goal) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHADE-167) [PATCH] When individual classes are renamed, they are not debuggable
Matt Benson created MSHADE-167:
--
Summary: [PATCH] When individual classes are renamed, they are not
debuggable
Key: MSHADE-167
URL: https://jira.codehaus.org/browse/MSHADE-167
Project: Maven Shade Plugin
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Matt Benson
Attachments: shade-srcfile.patch.txt
One can rename a given class using, e.g.:
{code}
relocation
patterncom.example.foo./pattern
shadedPatterncom.uber._foo.__/shadedPattern
/relocation
{code}
Using the above relocation, {{com.example.foo.Bar}} will be relocated to
{{com.uber._foo.__Bar}} and this is fine. If the source jar is generated, the
{{.java}} file will be moved accordingly. The proposed patch changes the source
information in the relocated class to use the new basename of the Java source
file, making it possible to debug again. My Apache ICLA is on file, rights are
granted, and a test of the functionality is included.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHADE-120) createSourceJar does not include sources from current module
[
https://jira.codehaus.org/browse/MSHADE-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=344056#comment-344056
]
Saurabh Ajmera commented on MSHADE-120:
---
Matt,
Yes, i will resolve this jira
createSourceJar does not include sources from current module
Key: MSHADE-120
URL: https://jira.codehaus.org/browse/MSHADE-120
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 1.6
Reporter: Saurabh Ajmera
Attachments: maven-shade-problem-solution.zip, maven-shade-problem.zip
{quote}
In such case the best approach is to create an issue with a sample project
to reproduce the trouble .
And the best of the best attaching a patch which fix the issue :-)
--
Olivier
Le 25 mai 2012 17:40, Saurabh Ajmera sajm...@usc.edu a écrit :
Hi,
Is there anyone using the shade plugin? are you facing this issue?
On May 22, 2012, at 11:06 AM, Saurabh Ajmera wrote:
Hi,
I am using the maven shade plugin to produce a jar which includes
contents of one dependency artifact plus the contents of my current maven
module, such that the contents of my maven module override the files with
the same name in the dependency jar.
The shade plugin generates the jar file correctly as needed. However,
the source files from the current maven modules does not get included in
the generated source jar. Am I doing something wrong?
Following is the extract from my pom.xml
{code:xml}
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-shade-plugin/artifactId
version${maven.shade.plugin.version}/version
configuration
createSourcesJartrue/createSourcesJar
artifactSet
includes
include
org.kuali.rice:rice-impl
/include
/includes
/artifactSet
/configuration
executions
execution
phasepackage/phase
goals
goalshade/goal
/goals
/execution
/executions
/plugin
/plugins
{code}
Thank you,
Saurabh Ajmera.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHADE-120) createSourceJar does not include sources from current module
[
https://jira.codehaus.org/browse/MSHADE-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Saurabh Ajmera closed MSHADE-120.
-
Resolution: Not A Bug
createSourceJar does not include sources from current module
Key: MSHADE-120
URL: https://jira.codehaus.org/browse/MSHADE-120
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 1.6
Reporter: Saurabh Ajmera
Attachments: maven-shade-problem-solution.zip, maven-shade-problem.zip
{quote}
In such case the best approach is to create an issue with a sample project
to reproduce the trouble .
And the best of the best attaching a patch which fix the issue :-)
--
Olivier
Le 25 mai 2012 17:40, Saurabh Ajmera sajm...@usc.edu a écrit :
Hi,
Is there anyone using the shade plugin? are you facing this issue?
On May 22, 2012, at 11:06 AM, Saurabh Ajmera wrote:
Hi,
I am using the maven shade plugin to produce a jar which includes
contents of one dependency artifact plus the contents of my current maven
module, such that the contents of my maven module override the files with
the same name in the dependency jar.
The shade plugin generates the jar file correctly as needed. However,
the source files from the current maven modules does not get included in
the generated source jar. Am I doing something wrong?
Following is the extract from my pom.xml
{code:xml}
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-shade-plugin/artifactId
version${maven.shade.plugin.version}/version
configuration
createSourcesJartrue/createSourcesJar
artifactSet
includes
include
org.kuali.rice:rice-impl
/include
/includes
/artifactSet
/configuration
executions
execution
phasepackage/phase
goals
goalshade/goal
/goals
/execution
/executions
/plugin
/plugins
{code}
Thank you,
Saurabh Ajmera.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-294) java.lang.NoClassDefFoundError: org/sonatype/aether/graph/Dependency
Eric Kolotyluk created MPIR-294: --- Summary: java.lang.NoClassDefFoundError: org/sonatype/aether/graph/Dependency Key: MPIR-294 URL: https://jira.codehaus.org/browse/MPIR-294 Project: Maven Project Info Reports Plugin Issue Type: Bug Components: dependencies Affects Versions: 2.6 Environment: Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 08:22:22-0700) Maven home: D:\bin\Apache\apache-maven-3.1.1 Java version: 1.7.0_51, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.7.0_51\jre Default locale: en_US, platform encoding: utf-8 OS name: windows 8, version: 6.2, arch: amd64, family: windows Reporter: Eric Kolotyluk Priority: Minor [WARNING] An issue has occurred with report org.apache.maven.report.projectinfo.DependenciesReport, skip LinkageError org/sonatype/aether/graph/Dependency, please report an issue to Maven dev team. [INFO] --- maven-site-plugin:3.3:site (default-site) @ csharp-windows-elevate --- [INFO] configuring report plugin org.apache.maven.plugins:maven-project-info-reports-plugin:2.6 [INFO] Parent project loaded from repository: org.sonatype.oss:oss-parent:pom:7 [INFO] Relativizing decoration links with respect to project URL: http://kolotyluk.github.io/csharp-windows-elevate [INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0 skin. [INFO] Generating About report--- maven-project-info-reports-plugin:2.6 [INFO] Generating Project Team report--- maven-project-info-reports-plugin:2.6 [INFO] Generating Dependency Information report--- maven-project-info-reports-plugin:2.6 [INFO] Generating Project Plugins report--- maven-project-info-reports-plugin:2.6 [INFO] Generating Continuous Integration report--- maven-project-info-reports-plugin:2.6 [INFO] Generating Issue Tracking report--- maven-project-info-reports-plugin:2.6 [INFO] Generating Source Repository report--- maven-project-info-reports-plugin:2.6 [INFO] Generating Project License report--- maven-project-info-reports-plugin:2.6 [INFO] Generating Plugin Management report--- maven-project-info-reports-plugin:2.6 [INFO] Generating Distribution Management report--- maven-project-info-reports-plugin:2.6 [INFO] Generating Project Summary report--- maven-project-info-reports-plugin:2.6 [INFO] Generating Mailing Lists report--- maven-project-info-reports-plugin:2.6 [INFO] Generating Dependencies report--- maven-project-info-reports-plugin:2.6 [WARNING] Error injecting: org.apache.maven.shared.dependency.graph.internal.Maven3DependencyGraphBuilder java.lang.NoClassDefFoundError: org/sonatype/aether/graph/Dependency at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2531) at java.lang.Class.getDeclaredMethods(Class.java:1855) at com.google.inject.spi.InjectionPoint.getInjectionPoints(InjectionPoint.java:674) at com.google.inject.spi.InjectionPoint.forInstanceMethodsAndFields(InjectionPoint.java:366) at com.google.inject.internal.ConstructorBindingImpl.getInternalDependencies(ConstructorBindingImpl.java:165) at com.google.inject.internal.InjectorImpl.getInternalDependencies(InjectorImpl.java:609) at com.google.inject.internal.InjectorImpl.cleanup(InjectorImpl.java:565) at com.google.inject.internal.InjectorImpl.initializeJitBinding(InjectorImpl.java:551) at com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:865) at com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:790) at com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:278) at com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:210) at com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:986) at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1019) at com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:982) at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1032) at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48) at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86) at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:55) at com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70) at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100) at
[jira] [Created] (MPOM-49) configure standard plugin-tools goals in parent pom
Hervé Boutemy created MPOM-49: - Summary: configure standard plugin-tools goals in parent pom Key: MPOM-49 URL: https://issues.apache.org/jira/browse/MPOM-49 Project: Maven POMs Issue Type: Improvement Components: maven-plugins Affects Versions: MAVEN-PLUGINS-25 Reporter: Hervé Boutemy Fix For: MAVEN-PLUGINS-26 actually, plugin descriptor creation, annotations dependency... are copy/pasted to every plugin pom.xml even if they are the same creating a profile in parent based on site-pom.xml file inexistence (to avoid activation during parent pom build) would permit to configure everything common in parent pom -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] (MDEPLOY-177) Maven release:perform hangs when downloading maven-metadata.xml
[
https://jira.codehaus.org/browse/MDEPLOY-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=344061#comment-344061
]
Michael Heuer commented on MDEPLOY-177:
---
It turns out the successful biojava version 3.0.8 release was performed with
maven version 3.0.4.
I tried the biojava-legacy 1.8.5 release with maven version 3.0.5 and was also
successful (see attached release-perform-3.0.5.txt).
This identifies a regression, although if that is in maven proper, or wagon, or
wagon-ssh, or release, or deploy I cannot say. I would appreciate advice on
what to do next with this issue. Thank you.
Maven release:perform hangs when downloading maven-metadata.xml
---
Key: MDEPLOY-177
URL: https://jira.codehaus.org/browse/MDEPLOY-177
Project: Maven Deploy Plugin
Issue Type: Bug
Components: deploy:deploy
Affects Versions: 2.8.1
Environment: $ mvn -v
Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
2014-02-14T11:37:52-06:00)
Maven home: /usr/local/Cellar/maven/3.2.1/libexec
Java version: 1.7.0_51, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: mac os x, version: 10.9.2, arch: x86_64, family: mac
Reporter: Michael Heuer
Priority: Critical
Attachments: deploy-debug.txt, release-perform-debug.txt
When attempting to mvn release:perform
{code:none}
$ mvn release:perform
...
[INFO] [INFO]
[INFO] [INFO] Building biojava-legacy 1.8.5
[INFO] [INFO]
[INFO] [INFO]
[INFO] [INFO] maven-source-plugin:2.2.1:jar (attach-sources) @
biojava-legacy
[INFO] [INFO]
[INFO] [INFO] maven-source-plugin:2.2.1:jar (attach-sources) @
biojava-legacy
[INFO] [INFO]
[INFO] [INFO] --- maven-source-plugin:2.2.1:jar (attach-sources) @
biojava-legacy ---
[INFO] [INFO]
[INFO] [INFO] --- maven-javadoc-plugin:2.9.1:jar (attach-javadocs) @
biojava-legacy ---
[INFO] [INFO] Not executing Javadoc as the project is not a Java
classpath-capable package
[INFO] [INFO]
[INFO] [INFO] --- maven-install-plugin:2.4:install (default-install) @
biojava-legacy ---
[INFO] [INFO] Installing
/Users/xxx/working/biojava-legacy/target/checkout/pom.xml to
/Users/xxx/.m2/repository/org/biojava/biojava-legacy/1.8.5/biojava-legacy-1.8.5.pom
[INFO] [INFO]
[INFO] [INFO] --- maven-deploy-plugin:2.8.1:deploy (default-deploy) @
biojava-legacy ---
[INFO] Uploading:
scp://cloudportal.open-bio.org/home/websites/biojava.org/html/static/download/maven/org/biojava/biojava-legacy/1.8.5/biojava-legacy-1.8.5.pom
[INFO] 4/9 KB
[INFO] 8/9 KB
[INFO] 9/9 KB
[INFO]
[INFO] Uploaded:
scp://cloudportal.open-bio.org/home/websites/biojava.org/html/static/download/maven/org/biojava/biojava-legacy/1.8.5/biojava-legacy-1.8.5.pom
(9 KB at 3.0 KB/sec)
[INFO] Downloading:
scp://cloudportal.open-bio.org/home/websites/biojava.org/html/static/download/maven/org/biojava/biojava-legacy/maven-metadata.xml
[INFO] 750/750 B
[INFO] 751/750 B
{code}
the build hangs at this point. It appears there might be a difference
between the expected file size and the downloaded file size, but no
warning/error messages appear, the build just hangs.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEPLOY-177) Maven release:perform hangs when downloading maven-metadata.xml
[
https://jira.codehaus.org/browse/MDEPLOY-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Heuer updated MDEPLOY-177:
--
Attachment: release-perform-3.0.5.txt
release:perform fails with maven 3.2.1, succeeds with maven 3.0.5
Maven release:perform hangs when downloading maven-metadata.xml
---
Key: MDEPLOY-177
URL: https://jira.codehaus.org/browse/MDEPLOY-177
Project: Maven Deploy Plugin
Issue Type: Bug
Components: deploy:deploy
Affects Versions: 2.8.1
Environment: $ mvn -v
Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
2014-02-14T11:37:52-06:00)
Maven home: /usr/local/Cellar/maven/3.2.1/libexec
Java version: 1.7.0_51, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: mac os x, version: 10.9.2, arch: x86_64, family: mac
Reporter: Michael Heuer
Priority: Critical
Attachments: deploy-debug.txt, release-perform-3.0.5.txt,
release-perform-debug.txt
When attempting to mvn release:perform
{code:none}
$ mvn release:perform
...
[INFO] [INFO]
[INFO] [INFO] Building biojava-legacy 1.8.5
[INFO] [INFO]
[INFO] [INFO]
[INFO] [INFO] maven-source-plugin:2.2.1:jar (attach-sources) @
biojava-legacy
[INFO] [INFO]
[INFO] [INFO] maven-source-plugin:2.2.1:jar (attach-sources) @
biojava-legacy
[INFO] [INFO]
[INFO] [INFO] --- maven-source-plugin:2.2.1:jar (attach-sources) @
biojava-legacy ---
[INFO] [INFO]
[INFO] [INFO] --- maven-javadoc-plugin:2.9.1:jar (attach-javadocs) @
biojava-legacy ---
[INFO] [INFO] Not executing Javadoc as the project is not a Java
classpath-capable package
[INFO] [INFO]
[INFO] [INFO] --- maven-install-plugin:2.4:install (default-install) @
biojava-legacy ---
[INFO] [INFO] Installing
/Users/xxx/working/biojava-legacy/target/checkout/pom.xml to
/Users/xxx/.m2/repository/org/biojava/biojava-legacy/1.8.5/biojava-legacy-1.8.5.pom
[INFO] [INFO]
[INFO] [INFO] --- maven-deploy-plugin:2.8.1:deploy (default-deploy) @
biojava-legacy ---
[INFO] Uploading:
scp://cloudportal.open-bio.org/home/websites/biojava.org/html/static/download/maven/org/biojava/biojava-legacy/1.8.5/biojava-legacy-1.8.5.pom
[INFO] 4/9 KB
[INFO] 8/9 KB
[INFO] 9/9 KB
[INFO]
[INFO] Uploaded:
scp://cloudportal.open-bio.org/home/websites/biojava.org/html/static/download/maven/org/biojava/biojava-legacy/1.8.5/biojava-legacy-1.8.5.pom
(9 KB at 3.0 KB/sec)
[INFO] Downloading:
scp://cloudportal.open-bio.org/home/websites/biojava.org/html/static/download/maven/org/biojava/biojava-legacy/maven-metadata.xml
[INFO] 750/750 B
[INFO] 751/750 B
{code}
the build hangs at this point. It appears there might be a difference
between the expected file size and the downloaded file size, but no
warning/error messages appear, the build just hangs.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
