[jira] (MNG-5523) support actual incremental build
[
https://jira.codehaus.org/browse/MNG-5523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 ca
[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-tabpanel&focusedCommentId=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 true 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: org.apache.maven.plugins maven-compiler-plugin 3.1 1.6 1.6 true true true 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-tabpanel&focusedCommentId=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 true 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: org.apache.maven.plugins maven-compiler-plugin 3.1 1.6 1.6 true true true 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 true 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: org.apache.maven.plugins maven-compiler-plugin 3.1 1.6 1.6 true true true 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 true 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: > > org.apache.maven.plugins > maven-compiler-plugin > 3.1 > > 1.6 > 1.6 > true > true > true > > > 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 true 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: org.apache.maven.plugins maven-compiler-plugin 3.1 1.6 1.6 true true true 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 true 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: org.apache.maven.plugins maven-compiler-plugin 3.1 1.6 1.6 true true true 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 true 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: > > org.apache.maven.plugins > maven-compiler-plugin > 3.1 > > 1.6 > 1.6 > true > true > true > > > 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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" 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}
>
>
> org.apache.maven.plugins
> maven-shade-plugin
> ${maven.shade.plugin.version}
>
> true
>
>
>
> org.kuali.rice:rice-impl
>
>
>
>
>
>
> package
>
> shade
>
>
>
>
>
> {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-tabpanel&focusedCommentId=344055#comment-344055
]
Matt Benson commented on MSHADE-78:
---
Note that you _can_ rename classes, if a bit clumsily, by specifying e.g.:
{code}
com.example.foo.
com.uber._foo.__
{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-tabpanel&focusedCommentId=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}
com.example.foo.
com.uber._foo.__
{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-tabpanel&focusedCommentId=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" 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}
>
>
> org.apache.maven.plugins
> maven-shade-plugin
> ${maven.shade.plugin.version}
>
> true
>
>
>
> org.kuali.rice:rice-impl
>
>
>
>
>
>
> package
>
> shade
>
>
>
>
>
> {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" 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}
>
>
> org.apache.maven.plugins
> maven-shade-plugin
> ${maven.shade.plugin.version}
>
> true
>
>
>
> org.kuali.rice:rice-impl
>
>
>
>
>
>
> package
>
> shade
>
>
>
>
>
> {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 org.eclipse.sisu.plexus.PlexusLifecycl
[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-tabpanel&focusedCommentId=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)
[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:
--
Comment: was deleted
(was: 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)
