[jira] (MNG-5605) ssh-wagon hangs
[ https://jira.codehaus.org/browse/MNG-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344066#comment-344066 ] Parolini Antonio commented on MNG-5605: --- Same here. I tried to upgrade to the latest wagon ssh (2.6), same bug using maven 3.2.1. Fine with maven 3.1.1, thus this looks a maven core issue. Will be great if this is corrected in next maven release. > ssh-wagon hangs > --- > > Key: MNG-5605 > URL: https://jira.codehaus.org/browse/MNG-5605 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Deployment >Affects Versions: 3.2.1 >Reporter: Frank Cornelis >Priority: Blocker > > When releasing (using maven-release-plugin) via Maven 3.1.1 everything works > as expected. When doing the same via Maven 3.2.1, ssh-wagon all of the sudden > hangs on the second ssh upload. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] Commented: (MJAVADOC-246) ExceptionInInitializerError
[ http://jira.codehaus.org/browse/MJAVADOC-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185831#action_185831 ] Parolini Antonio commented on MJAVADOC-246: --- Same here. My workaround is to force version 2.5 of the maven-javadoc-plugin > ExceptionInInitializerError > --- > > Key: MJAVADOC-246 > URL: http://jira.codehaus.org/browse/MJAVADOC-246 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: Hudson or command-line > Maven 2.1.0 or 2.2.0 > JDK 1.6 or JDK 1.7 > OpenSolaris >Reporter: Malachi de AElfweald >Priority: Blocker > Fix For: 2.6.1 > > > This bug only happens if I have maven-javadoc-plugin enabled. If I comment it > out site generation works. The POM is not specifying a particular version so > I am not sure which one it is using. > These bugs seem to report the same problem against other plugins: > http://jira.codehaus.org/browse/MOJO-1118 > http://jira.codehaus.org/browse/MOJO-1101 > Based on the error message, I checked the repository after successfully > building without JavaDoc and it shows these versions of commons-logging were > used: > 1.0 > 1.0.3 > 1.0.4 > 1.1 > The only SNAPSHOT dependency is 2.1-SNAPSHOT of the maven-site-plugin (to get > around site generation bugs). I am using the -U during building. > [INFO] Generating "JavaDocs" report. > [FATAL ERROR] org.apache.maven.plugins.site.SiteMojo#execute() caused a > linkage error (java.lang.ExceptionInInitializerError) and may be out-of-date. > Check the realms: > [FATAL ERROR] Plugin realm = > app0.child-container[org.apache.maven.plugins:maven-site-plugin:2.1-SNAPSHOT] > urls[0] = > file:/home/hudson/.m2/repository/org/apache/maven/plugins/maven-site-plugin/2.1-SNAPSHOT/maven-site-plugin-2.1-SNAPSHOT.jar > urls[1] = > file:/home/hudson/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar > urls[2] = > file:/home/hudson/.m2/repository/org/apache/maven/doxia/doxia-module-xhtml/1.1.2-SNAPSHOT/doxia-module-xhtml-1.1.2-SNAPSHOT.jar > urls[3] = > file:/home/hudson/.m2/repository/org/apache/maven/doxia/doxia-core/1.1.2-SNAPSHOT/doxia-core-1.1.2-SNAPSHOT.jar > urls[4] = > file:/home/hudson/.m2/repository/xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar > urls[5] = > file:/home/hudson/.m2/repository/xml-apis/xml-apis/1.3.03/xml-apis-1.3.03.jar > urls[6] = > file:/home/hudson/.m2/repository/commons-lang/commons-lang/2.4/commons-lang-2.4.jar > urls[7] = > file:/home/hudson/.m2/repository/commons-httpclient/commons-httpclient/3.1/commons-httpclient-3.1.jar > urls[8] = > file:/home/hudson/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar > urls[9] = > file:/home/hudson/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar > urls[10] = > file:/home/hudson/.m2/repository/org/apache/maven/doxia/doxia-module-apt/1.1.2-SNAPSHOT/doxia-module-apt-1.1.2-SNAPSHOT.jar > urls[11] = > file:/home/hudson/.m2/repository/org/apache/maven/doxia/doxia-module-xdoc/1.1.2-SNAPSHOT/doxia-module-xdoc-1.1.2-SNAPSHOT.jar > urls[12] = > file:/home/hudson/.m2/repository/org/apache/maven/doxia/doxia-module-fml/1.1.2-SNAPSHOT/doxia-module-fml-1.1.2-SNAPSHOT.jar > urls[13] = > file:/home/hudson/.m2/repository/org/apache/maven/doxia/doxia-decoration-model/1.1.2-SNAPSHOT/doxia-decoration-model-1.1.2-SNAPSHOT.jar > urls[14] = > file:/home/hudson/.m2/repository/org/apache/maven/doxia/doxia-site-renderer/1.1.2-SNAPSHOT/doxia-site-renderer-1.1.2-SNAPSHOT.jar > urls[15] = > file:/home/hudson/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-7/plexus-i18n-1.0-beta-7.jar > urls[16] = > file:/home/hudson/.m2/repository/org/codehaus/plexus/plexus-velocity/1.1.7/plexus-velocity-1.1.7.jar > urls[17] = > file:/home/hudson/.m2/repository/org/apache/velocity/velocity/1.5/velocity-1.5.jar > urls[18] = > file:/home/hudson/.m2/repository/commons-collections/commons-collections/3.2/commons-collections-3.2.jar > urls[19] = file:/home/hudson/.m2/repository/oro/oro/2.0.8/oro-2.0.8.jar > urls[20] = > file:/home/hudson/.m2/repository/org/apache/maven/shared/maven-doxia-tools/1.1-SNAPSHOT/maven-doxia-tools-1.1-SNAPSHOT.jar > urls[21] = > file:/home/hudson/.m2/repository/commons-io/commons-io/1.4/commons-io-1.4.jar > urls[22] = > file:/home/hudson/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-7/plexus-archiver-1.0-alpha-7.jar > urls[23] = > file:/home/hudson/.m2/repository/org/mortbay/jetty/jetty/6.1.5/jetty-6.1.5.jar > urls[24] = > file:/home/hudson/.m2/repository/org/mortbay/jetty/jetty-util/6.1.5/jetty-util-6.1.5.jar > urls[25] = > file:/home/hudson/.m2/repository/org/mortbay/jetty/servlet-api-2.5/6.1.5/servlet-api-2.5-6.1.5.jar > [FATAL ERROR] Container realm = plexus.core > urls[0] = file:/opt/apache-m
[jira] Commented: (WAGON-80) Attempt to use proxySettings even when nonProxyHosts is defined
[ http://jira.codehaus.org/browse/WAGON-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103628 ] Parolini Antonio commented on WAGON-80: --- how great it would be that someone take care of this issue eventually.. cheers. > Attempt to use proxySettings even when nonProxyHosts is defined > --- > > Key: WAGON-80 > URL: http://jira.codehaus.org/browse/WAGON-80 > Project: wagon > Issue Type: Bug > Components: wagon-file, wagon-ftp, wagon-http, wagon-provider-api, > wagon-provider-test, wagon-scm, wagon-ssh, wagon-ssh-external, wagon-webdav > Environment: Maven 2.0.5 or maven 2.0.6, this report is based on 2.0.6 >Reporter: David J. M. Karlsen > > site-deploy hangs because of proxy-settings: > [INFO] Generate "Project Team" report. > [DEBUG] Generating > /tmp/mobilebank/mobilebank-ear/target/site/project-info.html > [DEBUG] Generating > /tmp/mobilebank/mobilebank-ear/target/site/project-reports.html > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-5:deploy' --> > [DEBUG] (f) inputDirectory = /tmp/mobilebank/mobilebank-ear/target/site > [DEBUG] (f) project = [EMAIL PROTECTED] > [DEBUG] (f) settings = [EMAIL PROTECTED] > [DEBUG] -- end configuration -- > [INFO] [site:deploy] > If I remove the proxies/proxy element[s] from my settings.xml it works. > Scp is used for deployment. > mvn -X site-deply|grep -i wagon gives: > [DEBUG] org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-5 > [DEBUG] > org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected > for runtime) > [DEBUG] > org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected > for runtime) > [DEBUG] > org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected > for runtime) > [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-6 > [DEBUG] org.apache.maven.wagon:wagon-ssh:jar:1.0-alpha-6 > [DEBUG] org.apache.maven.wagon:wagon-ssh-external:jar:1.0-alpha-6 > [DEBUG] org.apache.maven.wagon:wagon-file:jar:1.0-alpha-6 > [DEBUG] org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-6 > [DEBUG] > org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected > for runtime) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-145) release:prepare requires all modules to be SNAPSHOTS
[ http://jira.codehaus.org/browse/MRELEASE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90842 ] Parolini Antonio commented on MRELEASE-145: --- I agree with Jorg: the release-plugin should be have the ability to make partial release without touching the not-snapshot poms. My workaround for this issue so far as been to use profiles, in order to choose what module are released. > release:prepare requires all modules to be SNAPSHOTS > > > Key: MRELEASE-145 > URL: http://jira.codehaus.org/browse/MRELEASE-145 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-4 >Reporter: Jörg Hohwiller > > The biggest need for the maven-release-plugin is in complex projects with a > lot of modules (that may again have modules). If I do not get it wrong, the > current released version forces all modules to be snapshots and releases them > individually. This is completely useless in my situation because in the end > this forces me to release alle modules together for every change that is to > be released and more or less causes that all modules have the same version > number. When I call mvn replease:prepare on my toplevel project this is no > snapshot, it fails with this error: > The project : isn't a snapshot (). > I would expect release:prepare to leave non SNAPSHOT modules untouched (and > only verify that they do not have SNAPSHOT dependencies, what should never be > the case if the version is no snapshot). > All reactor projects that have a "-SNAPHSOT" version should be released and > theier project-internal dependencies should also be set to the acording > released version (and later be set to the new SNAPSHOT). > Additionally I want to have the complete project to be tagged as a whole > instead of each module. This could potentially be configureable (especially > which directory is actually tagged, e.g. if the toplevel project is not in > trunk/ but somewhere deeper say trunk/develop because other directories in > trunk are huge but do not need to be checked out by every developer but need > to be tagged). > I personally think that the best flexibility and final freedom would be to > split off the release:prepare goal into 3 goals: > -create release version(s) > -create tag(s) > -update to snapshot version(s) > These goals could be used individually and one could add some custom steps or > replace one with something else. > For creating the snapshot versions there is also the problem, that you do not > know right away which project will be modified when in the future. The > coolest thing would be if this would happen automatically when the first > change is commited to the module. But this is of cause not praticable in > reality (maybe if all commits would be done with maven). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-153) Multiproject CVS uncommitted changes not checked
[ http://jira.codehaus.org/browse/MRELEASE-153?page=comments#action_73793 ] Parolini Antonio commented on MRELEASE-153: --- I meant: dosen't check uncommitted changes for sub-modules. > Multiproject CVS uncommitted changes not checked > > > Key: MRELEASE-153 > URL: http://jira.codehaus.org/browse/MRELEASE-153 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Reporter: Parolini Antonio > > When using the "release plugin" on a flat multi-project struture, the plugin > dosen't check uncommitted changes with CVS, and perfome the release. > The module section of the master pom.xml: > > ../ejb > ../web > Maybe this is related to MRELEASE-6. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-153) Multiproject CVS uncommitted changes not checked
Multiproject CVS uncommitted changes not checked Key: MRELEASE-153 URL: http://jira.codehaus.org/browse/MRELEASE-153 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: Parolini Antonio When using the "release plugin" on a flat multi-project struture, the plugin dosen't check uncommitted changes with CVS, and perfome the release. The module section of the master pom.xml: ../ejb ../web http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
