[jira] Commented: (MDEP-230) Performance is really bad for large artifacts
[ http://jira.codehaus.org/browse/MDEP-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191279#action_191279 ] Mark Bowman commented on MDEP-230: -- I've been having a quick look into this by checking out the maven-dependency-plugin source code and adding debug:- http://svn.apache.org/repos/asf/maven/plugins/tags/maven-dependency-plugin-2.1 It appears to be slowing down in the extract method within the TarUnArchiver class. This class is part of the plexus-archiver-1.0-alpha-9 package. Checking this package out and inserting debug:- http://svn.codehaus.org/plexus/plexus-components/tags/plexus-archiver-1.0-alpha-9 shows that the TarUnarchiver class is extracting individual files and taking ~50ms per file. > Performance is really bad for large artifacts > - > > Key: MDEP-230 > URL: http://jira.codehaus.org/browse/MDEP-230 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: unpack >Affects Versions: 2.1 > Environment: linux >Reporter: Jason Chaffee >Assignee: Brian Fox > > I have a 300mb tar.gz file that I need to unpack for one of my builds. I > takes over 10 minutes to unpack with the unpack goal. If I do it on the > cmd-line it takes less than 1 minute. -- 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: (MRESOURCES-103) copy-resources does not work with multi-module maven project
copy-resources does not work with multi-module maven project
Key: MRESOURCES-103
URL: http://jira.codehaus.org/browse/MRESOURCES-103
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Affects Versions: 2.4
Environment: Maven version: 2.0.9
Java version: 1.6.0_16
Reporter: Jan Tietjens
Having a multi-module project the copy-resources task does run. It works in
version 2.3.
Example config:
{noformat}
org.apache.maven.plugins
maven-resources-plugin
2.3
copy-resources
package
copy-resources
target/extracted-config/
target/dependency/WEB-INF//
bla.xml
{noformat}
Error message:
{noformat}
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] 'copy-resources' was specified in an execution, but not found in the
plugin
[INFO]
{noformat}
--
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] Closed: (MRESOURCES-103) copy-resources does not work with multi-module maven project
[
http://jira.codehaus.org/browse/MRESOURCES-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Tietjens closed MRESOURCES-103.
---
Resolution: Not A Bug
Fix Version/s: 2.4
Seems to be a problem with the standard maven version of the resources plugin.
Fixed this issue by including following entry into the pluginManagement section
of my maven configuration:
org.apache.maven.plugins
maven-resources-plugin
2.4
> copy-resources does not work with multi-module maven project
>
>
> Key: MRESOURCES-103
> URL: http://jira.codehaus.org/browse/MRESOURCES-103
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: Maven version: 2.0.9
> Java version: 1.6.0_16
>Reporter: Jan Tietjens
> Fix For: 2.4
>
>
> Having a multi-module project the copy-resources task does run. It works in
> version 2.3.
> Example config:
> {noformat}
>
> org.apache.maven.plugins
> maven-resources-plugin
> 2.3
>
>
> copy-resources
> package
>
> copy-resources
>
>
> target/extracted-config/
>
>
> target/dependency/WEB-INF//
>
> bla.xml
>
>
>
>
>
>
>
> {noformat}
> Error message:
> {noformat}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] 'copy-resources' was specified in an execution, but not found in the
> plugin
> [INFO]
>
> {noformat}
--
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: (MEAR-66) finalName taken into account for full build but not for ear build
[ http://jira.codehaus.org/browse/MEAR-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191310#action_191310 ] Maarten Billemont commented on MEAR-66: --- This *IS* a bug. If only because of its inconsistent behavior. Building an EAR artifact with dependencies that are in the reactor and have a finalName specified results in a *different* resulting EAR artifact than building the EAR artifact without the dependencies in the reactor. This is not only a problem with the manifest, but, for instance, JBoss uses the archive name to build the JNDI mapping of EJBs. If the name of the archive is unpredictable (because you don't know how it will be built; either with or without the dependencies in the reactor), the JNDI mapping that JBoss will use when deploying the archive is unpredictable and your EJBs are inaccessible half the time. When copying the dependencies, their finalName should be considered and their destination name should conform to it. > finalName taken into account for full build but not for ear build > - > > Key: MEAR-66 > URL: http://jira.codehaus.org/browse/MEAR-66 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Windows XP; JDK1.5 >Reporter: Mark Jeffery >Assignee: Stephane Nicoll > Attachments: build.zip, j2ee-1.0.jar > > > If I force a build of all projects via a parent pom (which build 2 EARS), > then the finalName attribute of the jar plugin is taken into account for the > dependencies when they are built. > If I quickly build one EAR only, via its pom, it retrieves the dependencies > from the repository, the finalName in the dependency pom is not taken into > account and the version number is added to the jar name. > This breaks the manifest entries for the jars that were built with the forced > build as they still reference the specified name but the jars included in the > EAR have the version on the name. -- 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: (MEAR-66) finalName taken into account for full build but not for ear build
[ http://jira.codehaus.org/browse/MEAR-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191316#action_191316 ] Stephane Nicoll commented on MEAR-66: - It's not an ear plugin bug, that's whay I meant. > finalName taken into account for full build but not for ear build > - > > Key: MEAR-66 > URL: http://jira.codehaus.org/browse/MEAR-66 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Windows XP; JDK1.5 >Reporter: Mark Jeffery >Assignee: Stephane Nicoll > Attachments: build.zip, j2ee-1.0.jar > > > If I force a build of all projects via a parent pom (which build 2 EARS), > then the finalName attribute of the jar plugin is taken into account for the > dependencies when they are built. > If I quickly build one EAR only, via its pom, it retrieves the dependencies > from the repository, the finalName in the dependency pom is not taken into > account and the version number is added to the jar name. > This breaks the manifest entries for the jars that were built with the forced > build as they still reference the specified name but the jars included in the > EAR have the version on the name. -- 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] Issue Comment Edited: (MEAR-66) finalName taken into account for full build but not for ear build
[ http://jira.codehaus.org/browse/MEAR-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191316#action_191316 ] Stephane Nicoll edited comment on MEAR-66 at 9/17/09 6:32 AM: -- It's not an ear plugin bug, that's what I meant. was (Author: sni): It's not an ear plugin bug, that's whay I meant. > finalName taken into account for full build but not for ear build > - > > Key: MEAR-66 > URL: http://jira.codehaus.org/browse/MEAR-66 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Windows XP; JDK1.5 >Reporter: Mark Jeffery >Assignee: Stephane Nicoll > Attachments: build.zip, j2ee-1.0.jar > > > If I force a build of all projects via a parent pom (which build 2 EARS), > then the finalName attribute of the jar plugin is taken into account for the > dependencies when they are built. > If I quickly build one EAR only, via its pom, it retrieves the dependencies > from the repository, the finalName in the dependency pom is not taken into > account and the version number is added to the jar name. > This breaks the manifest entries for the jars that were built with the forced > build as they still reference the specified name but the jars included in the > EAR have the version on the name. -- 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: (MJAVADOC-252) javadoc link : nonproxyhosts not used
[
http://jira.codehaus.org/browse/MJAVADOC-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191328#action_191328
]
Vincent Siveton commented on MJAVADOC-252:
--
Fixed in [r816155|http://svn.apache.org/viewvc?rev=816155&view=rev], snapshot
deployed. Please review it so I could close it. Thanks!
@Martijn For NTLM, I guess you need to add Joption param, ie
{noformat}
-J-Dhttp.auth.ntlm.domain=MYDOMAIN
...
{noformat}
> javadoc link : nonproxyhosts not used
> -
>
> Key: MJAVADOC-252
> URL: http://jira.codehaus.org/browse/MJAVADOC-252
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.6
> Environment: maven-2.0.10
> jdk 1.6_014
>Reporter: Maxime Gréau
>Priority: Minor
> Fix For: 2.6.1
>
> Attachments: link_nonproxy_2.0.10.patch, link_nonproxy_2.2.0.patch
>
>
> - Prerequisite :
>
> - web access via http proxy
> - javadoc-plugin configuration with true
> - $MVN_HOME/conf/settings.xml with configuration above ( internal-host is
> host to access the internal javadoc web sites )
>
>
> true
> http
> myproxyhost
> myproxyport
> internal-host
>
>
> Launch the mvn site-deploy command.
> If you have a dependency with an internal javadoc web site, the plugin tried
> to link this javadoc with the http proxy and logged:
> "Error fetching link: http://internal-host//apidocs/package-list. Ignored
> it."
> This is a bug because this javadoc isn't accessible via http proxy.
> So I attached 2 patches :
> - the first one (link_nonproxy_2.0.10.patch) is compatible (and tested) with
> mvn 2.0.9 and 2.0.10 but included a method directly copied from
> ProxyUtils.java (wagon-provider-api-1.0-beta-6.jar)
> - the second (link_nonproxy_2.2.0.patch) used 2 classes from
> wagon-provider-api-1.0-beta-6.jar dependency so it requires mvn 2.2
--
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] Updated: (MJAVADOC-252) javadoc link : nonproxyhosts not used
[ http://jira.codehaus.org/browse/MJAVADOC-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MJAVADOC-252: - Assignee: Vincent Siveton Fix Version/s: 2.6.1 > javadoc link : nonproxyhosts not used > - > > Key: MJAVADOC-252 > URL: http://jira.codehaus.org/browse/MJAVADOC-252 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: maven-2.0.10 > jdk 1.6_014 >Reporter: Maxime Gréau >Assignee: Vincent Siveton >Priority: Minor > Fix For: 2.6.1 > > Attachments: link_nonproxy_2.0.10.patch, link_nonproxy_2.2.0.patch > > > - Prerequisite : > > - web access via http proxy > - javadoc-plugin configuration with true > - $MVN_HOME/conf/settings.xml with configuration above ( internal-host is > host to access the internal javadoc web sites ) > > > true > http > myproxyhost > myproxyport > internal-host > > > Launch the mvn site-deploy command. > If you have a dependency with an internal javadoc web site, the plugin tried > to link this javadoc with the http proxy and logged: > "Error fetching link: http://internal-host//apidocs/package-list. Ignored > it." > This is a bug because this javadoc isn't accessible via http proxy. > So I attached 2 patches : > - the first one (link_nonproxy_2.0.10.patch) is compatible (and tested) with > mvn 2.0.9 and 2.0.10 but included a method directly copied from > ProxyUtils.java (wagon-provider-api-1.0-beta-6.jar) > - the second (link_nonproxy_2.2.0.patch) used 2 classes from > wagon-provider-api-1.0-beta-6.jar dependency so it requires mvn 2.2 -- 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: (MJAVADOC-253) Http proxy does not work any more
[
http://jira.codehaus.org/browse/MJAVADOC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191330#action_191330
]
Vincent Siveton commented on MJAVADOC-253:
--
In 2.6, the implementation uses HttpClient and not wagon.
For NTLM, I guess you need to add Joption param, ie
{noformat}
-J-Dhttp.auth.ntlm.domain=MYDOMAIN
...
{noformat}
> Http proxy does not work any more
> -
>
> Key: MJAVADOC-253
> URL: http://jira.codehaus.org/browse/MJAVADOC-253
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.6
> Environment: Maven 2.0.9
> JDK5 (Sun)
>Reporter: Mohan K
>Priority: Critical
>
> It appears the update of Wagon Provider in 2.6 is not compatible with Maven
> 2.0.x. Here is the
> email snippet as posted to maven users group (no responses)
> I am using Maven 2.0.9 and maven-javadoc-plugin 2.6. I have the "links"
> configured in my
> plugin config. Now all resolution of external links fail (we are behind a
> proxy *not* NTLM)
> with this:
> Aug 12, 2009 12:02:31 AM
> org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme
> INFO: ntlm authentication scheme selected
> Aug 12, 2009 12:02:31 AM org.apache.commons.httpclient.HttpMethodDirector
> authenticate
> The wagon provider appears to have been upgraded to 1.0-beta-6 in the
> maven-javadoc-plugin 2.6
> (as opposed to 1.0-beta-2 in 2.5). I seem to remember that (maybe it is
> wrong) that wagon 1.0-beta-6
> requires Maven 2.1.x and above? If that is the case, I don't understand how
> the plugin was released with
> prerequisite of 2.0.9?
> Is there a workaround to disable the default ntlm auth scheme via a magical
> system property? TIA
--
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: (MJAVADOC-263) No respect for JAVA_HOME or PATH in locating javadoc executable
[
http://jira.codehaus.org/browse/MJAVADOC-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191332#action_191332
]
Vincent Siveton commented on MJAVADOC-263:
--
As described in [1], you could always specify the javadoc tool using the
javadocExecutable param, ie
{noformat}
C:\jdk1.6.0\bin\javadoc.exe
...
{noformat}
For other people's machines, just use env variables, ie:
{noformat}
${env.JAVA_1.6_HOME}/bin/javadoc
{noformat}
Does it help you?
[1]
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/site/apt/examples/alternate-javadoc-tool.apt.vm
> No respect for JAVA_HOME or PATH in locating javadoc executable
> ---
>
> Key: MJAVADOC-263
> URL: http://jira.codehaus.org/browse/MJAVADOC-263
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Benson Margulies
>
> I have code that runs into a java 1.6 bug in javadoc, so I'm trying to be
> sure to use the 1.5 version of javadoc.
> In my .mavenrc, I set JAVA_HOME to point to 1.5. I set PATH to find a 1.5
> version of javadoc. I set my PATH in my shell to find the 1.5 version of
> Javadoc. Still, somehow, the maven-javadoc-plugin finds and runs the 1.6.0
> version.
> Command line
> was:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bin/javadoc
> @options @packages
> I cannot embed a shared pathname in the POM which won't work on other
> people's machines.
--
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-485) release:branch miscalculated target location in svn and misedited working copy svn elements
release:branch miscalculated target location in svn and misedited working copy svn elements --- Key: MRELEASE-485 URL: http://jira.codehaus.org/browse/MRELEASE-485 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.0-beta-10 Reporter: Benson Margulies scm:svn:http://svn.basistech.net/engineering/rex2009/trunk/java scm:svn:http://svn.basistech.net/engineering/rex2009/trunk/java I ran mvn release:branch -DbranchName=rlp-7.0 -DupdateWorkingCopyVersions=true -DremoteTagging=true -DupdateBranchVersions=true -DautoVersionSubmodules=true The result of this was, in effect: svn cp http://svn.basistech.net/engineering/rex2009/trunk/java http://svn.basistech.net/engineering/rex2009/branches/rlp-7.0 Note the disappearance of the 'java' directory. As an extra added benefit, all the trunk scm elements got left with the branch SVN url, not the trunk SVN url. -- 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] Closed: (MNG-4048) Allow to resolve dependencies using version range from reactor
[ http://jira.codehaus.org/browse/MNG-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4048. -- Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: (was: 2.2.x) 3.0-alpha-3 Done in [r816180|http://svn.apache.org/viewvc?view=rev&revision=816180]. > Allow to resolve dependencies using version range from reactor > -- > > Key: MNG-4048 > URL: http://jira.codehaus.org/browse/MNG-4048 > Project: Maven 2 > Issue Type: Improvement > Components: Dependencies >Affects Versions: 2.0.10, 2.1.0-M1 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann > Fix For: 3.0-alpha-3 > > > Currently, the reactor can only resolve dependencies that are specified using > a simple version like "1.1-SNAPSHOT". If a consumer declares the dependeny > version as "[1.0,)", reactor resolution is no longer possible. -- 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: (MNG-4362) improve documentation
improve documentation - Key: MNG-4362 URL: http://jira.codehaus.org/browse/MNG-4362 Project: Maven 2 Issue Type: Improvement Components: Documentation: Guides Reporter: Albert Kurucz "Guide to uploading artifacts to the Central Repository" needs to specify some requirements for multi-module Maven projects. Many of the project's POM configurations are inherited by the modules of the project. It is unspecified by this guide, whether the modules POMs also need to specify those settings explicitly or not, in case the developers' intention is to release those on Central. As of "Last Published: 2009-09-09" this information is missing from this guide. -- 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: (MNG-4362) improve documentation
[ http://jira.codehaus.org/browse/MNG-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191340#action_191340 ] Albert Kurucz commented on MNG-4362: If a Report plugin would exist, which checks a Maven project whether it complies to the requirements of the compliance with Central, then "Guide to uploading artifacts to the Central Repository" specification should show a link to this Report plugin. Is there such a Report plugin somewhere? Don't you think we need that? > improve documentation > - > > Key: MNG-4362 > URL: http://jira.codehaus.org/browse/MNG-4362 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: Guides >Reporter: Albert Kurucz > > "Guide to uploading artifacts to the Central Repository" needs to specify > some requirements for multi-module Maven projects. > Many of the project's POM configurations are inherited by the modules of the > project. > It is unspecified by this guide, whether the modules POMs also need to > specify those settings explicitly or not, in case the developers' intention > is to release those on Central. > As of "Last Published: 2009-09-09" this information is missing from this > guide. -- 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] Issue Comment Edited: (MNG-4362) improve documentation
[ http://jira.codehaus.org/browse/MNG-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191340#action_191340 ] Albert Kurucz edited comment on MNG-4362 at 9/17/09 8:46 AM: - If a Report plugin would exist, which checks a Maven project whether it complies to the requirements of the Central, then "Guide to uploading artifacts to the Central Repository" specification should show a link to this Report plugin. Is there such a Report plugin somewhere? Don't you think we need that? was (Author: ali65): If a Report plugin would exist, which checks a Maven project whether it complies to the requirements of the compliance with Central, then "Guide to uploading artifacts to the Central Repository" specification should show a link to this Report plugin. Is there such a Report plugin somewhere? Don't you think we need that? > improve documentation > - > > Key: MNG-4362 > URL: http://jira.codehaus.org/browse/MNG-4362 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: Guides >Reporter: Albert Kurucz > > "Guide to uploading artifacts to the Central Repository" needs to specify > some requirements for multi-module Maven projects. > Many of the project's POM configurations are inherited by the modules of the > project. > It is unspecified by this guide, whether the modules POMs also need to > specify those settings explicitly or not, in case the developers' intention > is to release those on Central. > As of "Last Published: 2009-09-09" this information is missing from this > guide. -- 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: (MNG-4362) improve documentation
[ http://jira.codehaus.org/browse/MNG-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191341#action_191341 ] Albert Kurucz commented on MNG-4362: The link: http://maven.apache.org/guides/mini/guide-central-repository-upload.html > improve documentation > - > > Key: MNG-4362 > URL: http://jira.codehaus.org/browse/MNG-4362 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: Guides >Reporter: Albert Kurucz > > "Guide to uploading artifacts to the Central Repository" needs to specify > some requirements for multi-module Maven projects. > Many of the project's POM configurations are inherited by the modules of the > project. > It is unspecified by this guide, whether the modules POMs also need to > specify those settings explicitly or not, in case the developers' intention > is to release those on Central. > As of "Last Published: 2009-09-09" this information is missing from this > guide. -- 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: (WAGON-285) Repository constructor NPE should be more verbose
[
http://jira.codehaus.org/browse/WAGON-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191343#action_191343
]
Nicolas Frenay commented on WAGON-285:
--
Just got hit by this problem again. Is someone from the project watching this?
> Repository constructor NPE should be more verbose
> -
>
> Key: WAGON-285
> URL: http://jira.codehaus.org/browse/WAGON-285
> Project: Maven Wagon
> Issue Type: Improvement
> Components: wagon-provider-api
>Reporter: Nicolas Frenay
> Fix For: 1.0
>
>
> After having the following problem while trying to maven install my project,
> I suggest that the Repository constructor should be more verbose in case the
> "id" or "url" are null.
> {code:none}
> [INFO] Scanning for projects...
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] id can not be null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException: id can not be null
> at
> org.apache.maven.wagon.repository.Repository.(Repository.java:81)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepository.(DefaultArtifactRepository.java:70)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepositoryFactory.createDeploymentArtifactRepository(DefaultArtifactRepositoryFactory.java:44)
> at
> org.apache.maven.project.ProjectUtils.buildDeploymentArtifactRepository(ProjectUtils.java:80)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:1029)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:880)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:508)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200)
> at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:604)
> at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:487)
> at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:560)
> at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:560)
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:391)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:272)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {code}
> I haven't created a patch because I currently don't have the SVN plugin
> installed on my Eclipse (and I'm running out of time), but it should as
> simple as changing the Repository.java constructor to:
> {code}
> public Repository( String id, String url )
> {
> if ( id == null )
> {
> throw new NullPointerException( "id can not be null for
> Repository with url=" + url );
> }
>
> setId( id );
> if ( url == null )
> {
> throw new NullPointerException( "url can not be null for
> Repository with id=" + id );
> }
>
> setUrl( url );
> }
> {code}
--
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: (WAGON-285) Repository constructor NPE should be more verbose
[
http://jira.codehaus.org/browse/WAGON-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191344#action_191344
]
Olivier Lamy commented on WAGON-285:
the message "id can not be null" doesn't help ?
> Repository constructor NPE should be more verbose
> -
>
> Key: WAGON-285
> URL: http://jira.codehaus.org/browse/WAGON-285
> Project: Maven Wagon
> Issue Type: Improvement
> Components: wagon-provider-api
>Reporter: Nicolas Frenay
> Fix For: 1.0
>
>
> After having the following problem while trying to maven install my project,
> I suggest that the Repository constructor should be more verbose in case the
> "id" or "url" are null.
> {code:none}
> [INFO] Scanning for projects...
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] id can not be null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException: id can not be null
> at
> org.apache.maven.wagon.repository.Repository.(Repository.java:81)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepository.(DefaultArtifactRepository.java:70)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepositoryFactory.createDeploymentArtifactRepository(DefaultArtifactRepositoryFactory.java:44)
> at
> org.apache.maven.project.ProjectUtils.buildDeploymentArtifactRepository(ProjectUtils.java:80)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:1029)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:880)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:508)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200)
> at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:604)
> at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:487)
> at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:560)
> at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:560)
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:391)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:272)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {code}
> I haven't created a patch because I currently don't have the SVN plugin
> installed on my Eclipse (and I'm running out of time), but it should as
> simple as changing the Repository.java constructor to:
> {code}
> public Repository( String id, String url )
> {
> if ( id == null )
> {
> throw new NullPointerException( "id can not be null for
> Repository with url=" + url );
> }
>
> setId( id );
> if ( url == null )
> {
> throw new NullPointerException( "url can not be null for
> Repository with id=" + id );
> }
>
> setUrl( url );
> }
> {code}
--
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: (WAGON-285) Repository constructor NPE should be more verbose
[
http://jira.codehaus.org/browse/WAGON-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191345#action_191345
]
Nicolas Frenay commented on WAGON-285:
--
It does a bit, but it could be better, showing which Repository we are talking
about.
Would definitelly help finding out what is wrong when you have bigger projects
(multi-module).
Thanks!
> Repository constructor NPE should be more verbose
> -
>
> Key: WAGON-285
> URL: http://jira.codehaus.org/browse/WAGON-285
> Project: Maven Wagon
> Issue Type: Improvement
> Components: wagon-provider-api
>Reporter: Nicolas Frenay
> Fix For: 1.0
>
>
> After having the following problem while trying to maven install my project,
> I suggest that the Repository constructor should be more verbose in case the
> "id" or "url" are null.
> {code:none}
> [INFO] Scanning for projects...
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] id can not be null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException: id can not be null
> at
> org.apache.maven.wagon.repository.Repository.(Repository.java:81)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepository.(DefaultArtifactRepository.java:70)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepositoryFactory.createDeploymentArtifactRepository(DefaultArtifactRepositoryFactory.java:44)
> at
> org.apache.maven.project.ProjectUtils.buildDeploymentArtifactRepository(ProjectUtils.java:80)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:1029)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:880)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:508)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200)
> at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:604)
> at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:487)
> at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:560)
> at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:560)
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:391)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:272)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {code}
> I haven't created a patch because I currently don't have the SVN plugin
> installed on my Eclipse (and I'm running out of time), but it should as
> simple as changing the Repository.java constructor to:
> {code}
> public Repository( String id, String url )
> {
> if ( id == null )
> {
> throw new NullPointerException( "id can not be null for
> Repository with url=" + url );
> }
>
> setId( id );
> if ( url == null )
> {
> throw new NullPointerException( "url can not be null for
> Repository with id=" + id );
> }
>
> setUrl( url );
> }
> {code}
--
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: (WAGON-285) Repository constructor NPE should be more verbose
[
http://jira.codehaus.org/browse/WAGON-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191358#action_191358
]
Nicolas Frenay commented on WAGON-285:
--
Quick tip for those having problems: run your mvn command with --debug. You'll
have an idea on which module it crashes (it won't show the bad one, but one
before).
> Repository constructor NPE should be more verbose
> -
>
> Key: WAGON-285
> URL: http://jira.codehaus.org/browse/WAGON-285
> Project: Maven Wagon
> Issue Type: Improvement
> Components: wagon-provider-api
>Reporter: Nicolas Frenay
> Fix For: 1.0
>
>
> After having the following problem while trying to maven install my project,
> I suggest that the Repository constructor should be more verbose in case the
> "id" or "url" are null.
> {code:none}
> [INFO] Scanning for projects...
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] id can not be null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException: id can not be null
> at
> org.apache.maven.wagon.repository.Repository.(Repository.java:81)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepository.(DefaultArtifactRepository.java:70)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepositoryFactory.createDeploymentArtifactRepository(DefaultArtifactRepositoryFactory.java:44)
> at
> org.apache.maven.project.ProjectUtils.buildDeploymentArtifactRepository(ProjectUtils.java:80)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:1029)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:880)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:508)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200)
> at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:604)
> at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:487)
> at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:560)
> at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:560)
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:391)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:272)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {code}
> I haven't created a patch because I currently don't have the SVN plugin
> installed on my Eclipse (and I'm running out of time), but it should as
> simple as changing the Repository.java constructor to:
> {code}
> public Repository( String id, String url )
> {
> if ( id == null )
> {
> throw new NullPointerException( "id can not be null for
> Repository with url=" + url );
> }
>
> setId( id );
> if ( url == null )
> {
> throw new NullPointerException( "url can not be null for
> Repository with id=" + id );
> }
>
> setUrl( url );
> }
> {code}
--
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: (MAVENUPLOAD-2604) Upload JFreeChart 1.0.13 and JCommon 1.0.16 dependent project
Upload JFreeChart 1.0.13 and JCommon 1.0.16 dependent project - Key: MAVENUPLOAD-2604 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2604 Project: Maven Upload Requests Issue Type: Wish Reporter: Javier Moran Attachments: jcommon-1.0.16-bundle.jar, jfreechart-1.0.13-bundle.jar -- 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: (MANTTASKS-161) SSH Wagon Provider for remote repository does not working with anttask deploy
SSH Wagon Provider for remote repository does not working with anttask deploy - Key: MANTTASKS-161 URL: http://jira.codehaus.org/browse/MANTTASKS-161 Project: Maven 2.x Ant Tasks Issue Type: Bug Affects Versions: 2.0.10 Reporter: Richard Bock This works when I create the full path in the remote server. When I do not create the path I am getting the following error: deploy: [artifact:install-provider] Installing provider: org.apache.maven.wagon:wagon-ssh:jar:1.0-beta-2:runtime [artifact:deploy] Deploying to scp://svne1.access.nokiasiemensnetworks.com/isource/mvnroot/SDF_SCE [artifact:deploy] Uploading: com/nsn/see/sce/core/maventools/5.0.0/maventools-5.0.0.jar to remote [artifact:deploy] An error has occurred while processing the Maven artifact tasks. [artifact:deploy] Diagnosis: [artifact:deploy] [artifact:deploy] Error deploying artifact 'com.nsn.see.sce.core:maventools:jar': Error deploying artifact: SCP terminated with error: 'scp: /isource/mvnroot/SDF_SCE/com/nsn/see/sce/core/maventools/5.0.0/maventools-5.0.0.jar: No such file or directory' [artifact:deploy] BUILD FAILED D:\work\sce\sce\sce.maven\build.xml:127: Error deploying artifact 'com.nsn.see.sce.core:maventools:jar': Error deploying artifact: SCP terminated with error: 'scp: /isource/mvnroot/SDF_SCE/com/nsn/see/sce/core/maventools/5.0.0/maventools-5.0.0.jar: No such file or directory' Either I did not understand the example how to use the scp wagon and deploy task or the wagon does not create the folder automatically before it uses scp to copy the files. In the first case please let me know how to fix this using a proper configuration and in the second case can you provide a bugfix? -- 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: (MEAR-66) finalName taken into account for full build but not for ear build
[ http://jira.codehaus.org/browse/MEAR-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191371#action_191371 ] Joerg Schaible commented on MEAR-66: Do it the other way round. Drop the final name thing in the EJB pom and configure the ear plugin to use a constant name for the EJB. > finalName taken into account for full build but not for ear build > - > > Key: MEAR-66 > URL: http://jira.codehaus.org/browse/MEAR-66 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Windows XP; JDK1.5 >Reporter: Mark Jeffery >Assignee: Stephane Nicoll > Attachments: build.zip, j2ee-1.0.jar > > > If I force a build of all projects via a parent pom (which build 2 EARS), > then the finalName attribute of the jar plugin is taken into account for the > dependencies when they are built. > If I quickly build one EAR only, via its pom, it retrieves the dependencies > from the repository, the finalName in the dependency pom is not taken into > account and the version number is added to the jar name. > This breaks the manifest entries for the jars that were built with the forced > build as they still reference the specified name but the jars included in the > EAR have the version on the name. -- 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-323) Release plugin (prepare goal) doesn't update more than one snapshot dependencies
[ http://jira.codehaus.org/browse/MRELEASE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191372#action_191372 ] John Davis commented on MRELEASE-323: - We have found the same issue with the projects comprising our products: version 2.0-beta-9 of the Release Plugin does not update all of a project's dependencies when used in an interactive mode. It did not matter whether the dependencies were part of a section or a section in the POM. For example, here is the section from one of our POMs. openmap openmap 4.6.5 com.echostorm.commons commons-security-api 1.1.5-SNAPSHOT com.echostorm.commons commons-xbroadcaster 1.7.5-SNAPSHOT log4j log4j com.echostorm.adlib adlib-chat-service-api 1.0.5-SNAPSHOT After excuting "mvn release:prepare -Dtag="adlib-3.6-rc5" -DaddSchema=false -DpreparationGoals="clean install" ", the tagged version of the POM was: openmap openmap 4.6.5 com.echostorm.commons commons-security-api 1.1.5-SNAPSHOT com.echostorm.commons commons-xbroadcaster 1.7.5-SNAPSHOT log4j log4j com.echostorm.adlib adlib-chat-service-api 1.0.5 and the next development version was: openmap openmap 4.6.5 com.echostorm.commons commons-security-api 1.1.5-SNAPSHOT com.echostorm.commons commons-xbroadcaster 1.7.5-SNAPSHOT log4j log4j com.echostorm.adlib adlib-chat-service-api 1.0.6-SNAPSHOT Notice that only the last dependency (adlib-chat-service-api) was updated in the tagged and next development versions of the POM. I applied the patch supplied by Alessandro Zucchi to version 2.0-beta-9 and performed: mvn release:prepare -Dtag="adlib-3.6-rc5" -DaddSchema=false -DpreparationGoals="clean install" The tagged version is now: openmap openmap 4.6.5 com.echostorm.commons commons-security-api 1.1.5 com.echostorm.commons commons-xbroadcaster 1.7.5 log4j log4j com.echostorm.adlib adlib-chat-service-api 1.0.5 and the next development version: openmap openmap 4.6.5 com.echostorm.commons commons-security-api 1.1.6-SNAPSHOT com.echostorm.commons commons-xbroadcaster 1.7.6-SNAPSHOT log4j log4j com.echostorm.adlib adlib-chat-service-api 1.0.6-SNAPSHOT After applying the patch, all dependencies are updated. This was also the cases with several other projects. Hopefully version 2.0-beta-10 will contain this or another similar patch resolving the issue. Please let me know if I can be of further assistance. Thanks, John Davis EchoStorm Worldwide, LLC > Release plugin (prepare goal) doesn't update more than one snapshot > dependencies > > > Key: MRELEASE-323 > URL: http://jira.codehaus.org/browse/MRELEASE-323 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-7 > Environment: Any >Reporter: Alessandro Zucchi >Priority: Blocker > Attachments: patch.txt, test.zip > > > I have a project so structured: > au au-business > | > | au-sistema > Dependencies in au are: > ... > > > >
[jira] Commented: (MRELEASE-370) release:prepare is not updating inter-modules dependencies to the next version snapshot identifier correctly (-DdryRun=true).
[ http://jira.codehaus.org/browse/MRELEASE-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191378#action_191378 ] John Davis commented on MRELEASE-370: - We have found the same issue with the projects comprising our products with version 2.0-beta-9 of the Release Plugin. Given the following multi-module project: data-service-parent-pom (1.1-SNAPSHOT) data-service-api (1.1-SNAPSHOT) data-service-impl (1.1-SNAPSHOT) where data-service-impl (1.1-SNAPSHOT) depends upon data-service-api (1.1-SNAPSHOT) The section of the data-service-impl (1.1-SNAPSHOT) looks like: com.echostorm.adlib data-service-api 1.1-SNAPSHOT . stuff deleted .. After executing mvn release:prepare -Dtag="adlib-3.6-rc5" -DaddSchema=false -DpreparationGoals="clean install", the tagged version of the POM was: com.echostorm.adlib data-service-api 1.1 . stuff deleted .. which was as expected, and the next development version was: com.echostorm.adlib data-service-api 1.1-SNAPSHOT . stuff deleted .. Which was not as expected. We had expected this dependency to be at 1.2-SNAPSHOT which was the next development version of data-service-api as advanced by the release plugin. The method updateDomVersion() in AbstractRewritePomsPhase.java of the maven-release-manager project was modified (see attached patch for details) changing the tests that trigger the updateVersion() method. Now executing mvn release:prepare -Dtag="adlib-3.6-rc5" -DaddSchema=false -DpreparationGoals="clean install" gives these results for the section on the tagged and next development version POMS of data-service-impl: TAGGED: com.echostorm.adlib data-service-api 1.1 . stuff deleted .. NEXT DEVELOPMENT: com.echostorm.adlib data-service-api 1.2-SNAPSHOT . stuff deleted .. which was the expected results. I tested several other of our projects which are similar from an "internal" dependency viewpoint using the modified version of the Release Plugin and the results were the same. No side effects were noted within our small set of tests. How this affects reports, plugins, etc is unknown. The following JIRA tickets may be related to this issue: MRELEASE-295 MRELEASE-444 Since I am fully familiar with the Release Plugin and supporting modules architecture and code, the attached patch may not be the optimum solution. Hopefully version 2.0-beta-10 will contain this or another similar patch resolving the issue. Please let me know if I can be of further assistance. Thanks, John Davis EchoStorm Worldwide, LLC > release:prepare is not updating inter-modules dependencies to the next > version snapshot identifier correctly (-DdryRun=true). > - > > Key: MRELEASE-370 > URL: http://jira.codehaus.org/browse/MRELEASE-370 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-7 > Environment: maven 2.0.9 on windows >Reporter: David Van den Brande > > Case: > project (version 1.0.4-SNAPSHOT) > - pom.xml with > > module1 > module2 > > project/module1 (version 1.0.4-SNAPSHOT) > - pom.xml with "project" as its parent > - dependency on module2 > project/module2 (version 1.0.4-SNAPSHOT) > - pom.xml with "project" as its parent > In the "project" folder run > - mvn -DdryRun=true release:prepare -DpreparationGoals=clean > => release version: 1.0.4 > => next dev version: 1.0.5-SNAPSHOT > Result: > * "project" pom has two correct pom versions: pom.xml.tag & pom.xml.next > * "module" pom: >- correct pom.xml.tag, meaning: >=> correct parent/version: 1.0.4-SNAPSHOT >=> correct module2 dependency moved from 1.0.4-SNAPSHOT to > 1.0.5-SNAPSHOT >- pom.xml.next: >=> correct parent/version: 1.0.5-SNAPSHOT >=> wrong module2 dependency 1.0.4-SNAPSHOT (it should be > 1.0.5-SNAPSHOT) -- This message is automatically
[jira] Updated: (MRELEASE-370) release:prepare is not updating inter-modules dependencies to the next version snapshot identifier correctly (-DdryRun=true).
[ http://jira.codehaus.org/browse/MRELEASE-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Davis updated MRELEASE-370: Attachment: AbstractRewritePomsPhase.patch > release:prepare is not updating inter-modules dependencies to the next > version snapshot identifier correctly (-DdryRun=true). > - > > Key: MRELEASE-370 > URL: http://jira.codehaus.org/browse/MRELEASE-370 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-7 > Environment: maven 2.0.9 on windows >Reporter: David Van den Brande > Attachments: AbstractRewritePomsPhase.patch > > > Case: > project (version 1.0.4-SNAPSHOT) > - pom.xml with > > module1 > module2 > > project/module1 (version 1.0.4-SNAPSHOT) > - pom.xml with "project" as its parent > - dependency on module2 > project/module2 (version 1.0.4-SNAPSHOT) > - pom.xml with "project" as its parent > In the "project" folder run > - mvn -DdryRun=true release:prepare -DpreparationGoals=clean > => release version: 1.0.4 > => next dev version: 1.0.5-SNAPSHOT > Result: > * "project" pom has two correct pom versions: pom.xml.tag & pom.xml.next > * "module" pom: >- correct pom.xml.tag, meaning: >=> correct parent/version: 1.0.4-SNAPSHOT >=> correct module2 dependency moved from 1.0.4-SNAPSHOT to > 1.0.5-SNAPSHOT >- pom.xml.next: >=> correct parent/version: 1.0.5-SNAPSHOT >=> wrong module2 dependency 1.0.4-SNAPSHOT (it should be > 1.0.5-SNAPSHOT) -- 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] Closed: (MSITE-428) site skin configurable also via POM (not only via site descriptor)
[ http://jira.codehaus.org/browse/MSITE-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-428. - Resolution: Won't Fix > site skin configurable also via POM (not only via site descriptor) > -- > > Key: MSITE-428 > URL: http://jira.codehaus.org/browse/MSITE-428 > Project: Maven 2.x Site Plugin > Issue Type: New Feature > Environment: environment independent >Reporter: Christoph Pickl >Priority: Minor > > as far as i can see the only possibility to define the skin of your site is > via the site.xml descriptor. > it would be nice if one could configure the skin within the pom.xml (below > reporting/plugins/site-plugin/configuration). this would mean that specifying > the skin in one of your super POMs would also immediately affect all your sub > POMs. > if someone could tell me where to change what, i would like to offer my help > as a developer and write the necessary code myself... > ~christoph -- 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: (MSITE-428) site skin configurable also via POM (not only via site descriptor)
[ http://jira.codehaus.org/browse/MSITE-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191380#action_191380 ] Dennis Lundberg commented on MSITE-428: --- You don't need to have the skin configuration in the POM for it to be inherited. The site.xml file is also inherited from a parent to its children. > site skin configurable also via POM (not only via site descriptor) > -- > > Key: MSITE-428 > URL: http://jira.codehaus.org/browse/MSITE-428 > Project: Maven 2.x Site Plugin > Issue Type: New Feature > Environment: environment independent >Reporter: Christoph Pickl >Priority: Minor > > as far as i can see the only possibility to define the skin of your site is > via the site.xml descriptor. > it would be nice if one could configure the skin within the pom.xml (below > reporting/plugins/site-plugin/configuration). this would mean that specifying > the skin in one of your super POMs would also immediately affect all your sub > POMs. > if someone could tell me where to change what, i would like to offer my help > as a developer and write the necessary code myself... > ~christoph -- 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: (MJAVADOC-253) Http proxy does not work any more
[ http://jira.codehaus.org/browse/MJAVADOC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191397#action_191397 ] Mohan K commented on MJAVADOC-253: -- Hi vincent, the problem is I am using 2.0.9. I *don't* have NTLM proxy, but if you look at the error message, the httpclient is *defaulting* to it and I cannot change it? > Http proxy does not work any more > - > > Key: MJAVADOC-253 > URL: http://jira.codehaus.org/browse/MJAVADOC-253 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: Maven 2.0.9 > JDK5 (Sun) >Reporter: Mohan K >Priority: Critical > > It appears the update of Wagon Provider in 2.6 is not compatible with Maven > 2.0.x. Here is the > email snippet as posted to maven users group (no responses) > I am using Maven 2.0.9 and maven-javadoc-plugin 2.6. I have the "links" > configured in my > plugin config. Now all resolution of external links fail (we are behind a > proxy *not* NTLM) > with this: > Aug 12, 2009 12:02:31 AM > org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme > INFO: ntlm authentication scheme selected > Aug 12, 2009 12:02:31 AM org.apache.commons.httpclient.HttpMethodDirector > authenticate > The wagon provider appears to have been upgraded to 1.0-beta-6 in the > maven-javadoc-plugin 2.6 > (as opposed to 1.0-beta-2 in 2.5). I seem to remember that (maybe it is > wrong) that wagon 1.0-beta-6 > requires Maven 2.1.x and above? If that is the case, I don't understand how > the plugin was released with > prerequisite of 2.0.9? > Is there a workaround to disable the default ntlm auth scheme via a magical > system property? TIA -- 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-486) Unable to release project with nested path
Unable to release project with nested path
--
Key: MRELEASE-486
URL: http://jira.codehaus.org/browse/MRELEASE-486
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform, prepare
Affects Versions: 2.0-beta-9
Reporter: Maria Catherine Tan
Releasing a multi-module project with "/" in it's module name fails with this
error:
{noformat}
[ERROR] org.apache.maven.shared.release.scm.ReleaseScmCommandException: Unable
to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: '/home/user/project/working-directory' is not a working copy
at
org.apache.maven.shared.release.phase.ScmTagPhase.execute(ScmTagPhase.java:139)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:210)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepareWithResult(DefaultReleaseManager.java:123)
at
org.apache.maven.continuum.release.executors.PrepareReleaseTaskExecutor.execute(PrepareReleaseTaskExecutor.java:60)
at
org.apache.maven.continuum.release.executors.AbstractReleaseTaskExecutor.executeTask(AbstractReleaseTaskExecutor.java:84)
at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
at
edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
at
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528)
at java.lang.Thread.run(Unknown Source)
{noformat}
The correct working directory should be '/home/user/project/working-directory/1'
--
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] Updated: (MRELEASE-486) Unable to release project with nested path
[
http://jira.codehaus.org/browse/MRELEASE-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maria Catherine Tan updated MRELEASE-486:
-
Attachment: MRELEASE-486.patch
Attached patch that corrects the baseWorkingDirectory and baseScmUrl based on
the longest relative path of modules.
> Unable to release project with nested path
> --
>
> Key: MRELEASE-486
> URL: http://jira.codehaus.org/browse/MRELEASE-486
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform, prepare
>Affects Versions: 2.0-beta-9
>Reporter: Maria Catherine Tan
> Attachments: MRELEASE-486.patch
>
>
> Releasing a multi-module project with "/" in it's module name fails with this
> error:
> {noformat}
> [ERROR] org.apache.maven.shared.release.scm.ReleaseScmCommandException:
> Unable to tag SCM
> Provider message:
> The svn tag command failed.
> Command output:
> svn: '/home/user/project/working-directory' is not a working copy
> at
> org.apache.maven.shared.release.phase.ScmTagPhase.execute(ScmTagPhase.java:139)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:210)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.prepareWithResult(DefaultReleaseManager.java:123)
> at
> org.apache.maven.continuum.release.executors.PrepareReleaseTaskExecutor.execute(PrepareReleaseTaskExecutor.java:60)
> at
> org.apache.maven.continuum.release.executors.AbstractReleaseTaskExecutor.executeTask(AbstractReleaseTaskExecutor.java:84)
> at
> org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
> at
> edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
> at
> edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
> The correct working directory should be
> '/home/user/project/working-directory/1'
--
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: (MJAVADOC-264) mvn clean install site doesn't work
mvn clean install site doesn't work
---
Key: MJAVADOC-264
URL: http://jira.codehaus.org/browse/MJAVADOC-264
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.6, 2.5
Reporter: Arnaud Brunet
Attachments: build.log, myTest.zip
Hi,
I tried to generate a maven site for a projet with multiple modules using
maven-javadoc-plugin in version 2.6. But i got this error :
{quote}
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) mygroup:myartifact:jar:1.0-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=mygroup -DartifactId=myartifact
-Dversion=1.0-SNAPSHOT -Dpa
ckaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=mygroup -DartifactId=myartifact
-Dversion=1.0-SNAPSHOT -Dpack
aging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) mygroup:moduleA:jar:1.0-SNAPSHOT
2) mygroup:myartifact:jar:1.0-SNAPSHOT
{quote}
I tried downgrade to 2.5 but I had always the error. With the 2.4 version, it
works.
I attach a test projet. Before each build, you must delete mygroup directory in
your maven repository.
--
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-323) Release plugin (prepare goal) doesn't update more than one snapshot dependencies
[
http://jira.codehaus.org/browse/MRELEASE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=191417#action_191417
]
Alessandro Zucchi commented on MRELEASE-323:
<<<>>>
I hope so !!!
It's annoying apply the patch on every newer version
Thanks
Alex.
> Release plugin (prepare goal) doesn't update more than one snapshot
> dependencies
>
>
> Key: MRELEASE-323
> URL: http://jira.codehaus.org/browse/MRELEASE-323
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-7
> Environment: Any
>Reporter: Alessandro Zucchi
>Priority: Blocker
> Attachments: patch.txt, test.zip
>
>
> I have a project so structured:
> au au-business
> |
> | au-sistema
> Dependencies in au are:
> ...
>
>
>
> com.zucchetti.qweb.au
> au-business
> ${project.version}
>
>
>
>
> com.zucchetti.qweb.framework
> sistema
> 03.00.02-SNAPSHOT
>
>
> com.zucchetti.qweb.framework
> business
> 03.00.02-SNAPSHOT
>
>
>
> ...
> Dependencies in au-business are:
> ...
>
>
> com.zucchetti.qweb.framework
> business
>
>
> ...
> Dependencies in au-sistema are:
> ...
>
>
> com.zucchetti.qweb.au
> au-business
>
>
> com.zucchetti.qweb.framework
> sistema
>
>
> ...
> When I make a mvn release:clean release:prepare of au project the plugin,
> correctly, ask me to resolve SNAPSHOTs dependencies. (framework-business &&
> framework-sistema)
> Unfortunatly at the end of the process only framework-sistema dependency (in
> au project) has been modified, while framework-business no.
> I've debuged the problem and I found that if I force the two dependencies
> (framework-sistema, framework-business) in the parent pom (pom of "au") all
> run fine (also if the process to resolve SNAPSHOT dependencies get prompted
> tree times ... too much I say ...).But I can't do this change in production.
> So, I tryed to resolve the problem.
> I've attached a patch.
> Best regards
> Alex
--
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
