date:20090914


 [ 
http://jira.codehaus.org/browse/MNG-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bentmann closed MNG-4355.
--

 Assignee: Benjamin Bentmann
   Resolution: Fixed
Fix Version/s: 3.0-alpha-3

Fixed in [r814571|http://svn.apache.org/viewvc?view=revrevision=814571].

 [regression] Extensions without version in the POM are not resolved to the 
 RELEASE artifact
 ---

 Key: MNG-4355
 URL: http://jira.codehaus.org/browse/MNG-4355
 Project: Maven 2
  Issue Type: Bug
  Components: Plugins and Lifecycle
Affects Versions: 3.0-alpha-3
Reporter: Benjamin Bentmann
Assignee: Benjamin Bentmann
 Fix For: 3.0-alpha-3


 In Maven 2, an extension declaration without version like below successfully 
 resolved the last release version of the artifact whereas trunk errors out.
 {code:xml}
 extension
   groupIdorg.apache.maven.archetype/groupId
   artifactIdarchetype-packaging/artifactId
 /extension
 {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] Updated: (MJAVADOC-246) ExceptionInInitializerError with maven-site-plugin:2.1-SNAPSHOT and mvn 2.1


 [ 
http://jira.codehaus.org/browse/MJAVADOC-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vincent Siveton updated MJAVADOC-246:
-

Description: 
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.

{noformat}
# mvn site
...
[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-maven-2.1.0/lib/maven-2.1.0-uber.jar
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] null
Invalid class loader hierarchy.  You have more than one version of 
'org.apache.commons.logging.Log' visible, which is not allowed.
[INFO] 
[INFO] Trace
java.lang.ExceptionInInitializerError
at 
org.apache.maven.plugin.javadoc.JavadocUtil.fetchURL(JavadocUtil.java:730)
at 
org.apache.maven.plugin.javadoc.AbstractJavadocMojo.isValidJavadocLink(AbstractJavadocMojo.java:4680)
at

[jira] Updated: (MJAVADOC-246) ExceptionInInitializerError with maven-site-plugin:2.1-SNAPSHOT and mvn 2.1


 [ 
http://jira.codehaus.org/browse/MJAVADOC-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vincent Siveton updated MJAVADOC-246:
-

Description: 
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.

{noformat}
# mvn site
...
[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-maven-2.1.0/lib/maven-2.1.0-uber.jar
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] null
Invalid class loader hierarchy.  You have more than one version of 
'org.apache.commons.logging.Log' visible, which is not allowed.
[INFO] 
[INFO] Trace
java.lang.ExceptionInInitializerError
at 
org.apache.maven.plugin.javadoc.JavadocUtil.fetchURL(JavadocUtil.java:730)
at 
org.apache.maven.plugin.javadoc.AbstractJavadocMojo.isValidJavadocLink(AbstractJavadocMojo.java:4680)
at

[jira] Closed: (MJAVADOC-246) ExceptionInInitializerError with maven-site-plugin:2.1-SNAPSHOT and mvn 2.1


 [ 
http://jira.codehaus.org/browse/MJAVADOC-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vincent Siveton closed MJAVADOC-246.


  Assignee: Vincent Siveton
Resolution: Fixed

Fixed in [r814574|http://svn.apache.org/viewvc?rev=814574view=rev], snapshot 
deployed

 ExceptionInInitializerError with maven-site-plugin:2.1-SNAPSHOT and mvn  2.1
 -

 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
 maven-site-plugin:2.1-SNAPSHOT
 OpenSolaris
Reporter: Malachi de AElfweald
Assignee: Vincent Siveton
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.
 {noformat}
 # mvn site
 ...
 [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] =

[jira] Closed: (MJAVADOC-245) Aggregate does not work


 [ 
http://jira.codehaus.org/browse/MJAVADOC-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vincent Siveton closed MJAVADOC-245.


Resolution: Not A Bug

Seems to work for you so I close it. You could always create a new issue.

 Aggregate does not work
 ---

 Key: MJAVADOC-245
 URL: http://jira.codehaus.org/browse/MJAVADOC-245
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.5, 2.6
Reporter: Jörg Hohwiller
 Attachments: MJAVADOC-245.zip


 I want to have an aggregated javadoc for the entire project as well as per 
 module.
 Therefore I followed instructions at:
 http://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate.html
 When I do mvn site:stage I get no aggregated javadoc but just per module.
 This does not even change if I only do
   reportSets
   reportSet
 reports
   reportaggregate/report
 /reports
   /reportSet
 /reportSets
 So to me this looks as if reportSets is magically ignored here.
 I have tested 2.5 as well as 2.6 from
 https://repository.apache.org/content/repositories/maven-staging-027/org/apache/maven/plugins/maven-javadoc-plugin/2.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] Commented: (MJAVADOC-134) Support aggregated reports at each level in the multi-module hierarchy


[ 
http://jira.codehaus.org/browse/MJAVADOC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=190853#action_190853
 ] 

Vincent Siveton commented on MJAVADOC-134:
--

Martin, FYI MJAVADOC-257 should fix your problem

 Support aggregated reports at each level in the multi-module hierarchy
 --

 Key: MJAVADOC-134
 URL: http://jira.codehaus.org/browse/MJAVADOC-134
 Project: Maven 2.x Javadoc Plugin
  Issue Type: New Feature
Affects Versions: 2.2
Reporter: John Allen

 The current system makes the assumption that if one wants aggregated reports 
 one does not want further javadoc reports (aggregated ones) down the 
 hierarchy. We do require this functionality and in fact do the same for all 
 our reports (PMD, Checkstyle, Clover, JXR, Surefire, etc):
 A-B-C-D1 (JAR)
 A-B-C-D2 (JAR)
 A-B-E(JAR)
 A-F (JAR)
 A - javadoc for D1,D2,E,F
 B - javadoc for D1,D2,E
 C - javadoc for D1,D2
 D1 - javadoc for D1
 D2 - javadoc for D2
 E - javadoc for E
 F - javadoc for F
 This way there is the required info at the appropriate level throughout the 
 hierarchy. And nope we dont care about space or generation times:)

-- 
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-4357) [regression] Custom packagings from build extensions are not reliably loaded during a reactor build

[regression] Custom packagings from build extensions are not reliably loaded 
during a reactor build
---

 Key: MNG-4357
 URL: http://jira.codehaus.org/browse/MNG-4357
 Project: Maven 2
  Issue Type: Bug
  Components: Plugins and Lifecycle, Reactor and workspace
Reporter: Benjamin Bentmann


Building XWiki platform with trunk in one go produces
{noformat}
[ERROR] Unknown packaging: maven-archetype @ 
org.xwiki.platform.tools:xwiki-archetype-macro:1.1-SNAPSHOT
{noformat}
The mentioned project properly declares the required build extensions in its 
POM and builds fine in isolation.

The issue boils down to the active component map 
{{DefaultLifecycleExecutor.lifecycleMappings}} not being properly updated when 
switching the projects in the reactor. In detail, 
{{AbstractComponentCollection.checkUpdate()}} from Plexus doesn't update the 
map if the number of component descriptors hasn't changed. This apparently 
misses the situation where the total count of component descriptors from two 
different class realms is the same but the set of role hints has changed, e.g. 
{{[one, two]}} vs. {{[one, three]}}.

-- 
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: (MNG-4357) [regression] Custom packagings from build extensions are not reliably loaded during a reactor build


 [ 
http://jira.codehaus.org/browse/MNG-4357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bentmann updated MNG-4357:
---

Affects Version/s: 3.0-alpha-3

 [regression] Custom packagings from build extensions are not reliably loaded 
 during a reactor build
 ---

 Key: MNG-4357
 URL: http://jira.codehaus.org/browse/MNG-4357
 Project: Maven 2
  Issue Type: Bug
  Components: Plugins and Lifecycle, Reactor and workspace
Affects Versions: 3.0-alpha-3
Reporter: Benjamin Bentmann

 Building XWiki platform with trunk in one go produces
 {noformat}
 [ERROR] Unknown packaging: maven-archetype @ 
 org.xwiki.platform.tools:xwiki-archetype-macro:1.1-SNAPSHOT
 {noformat}
 The mentioned project properly declares the required build extensions in its 
 POM and builds fine in isolation.
 The issue boils down to the active component map 
 {{DefaultLifecycleExecutor.lifecycleMappings}} not being properly updated 
 when switching the projects in the reactor. In detail, 
 {{AbstractComponentCollection.checkUpdate()}} from Plexus doesn't update the 
 map if the number of component descriptors hasn't changed. This apparently 
 misses the situation where the total count of component descriptors from two 
 different class realms is the same but the set of role hints has changed, 
 e.g. {{[one, two]}} vs. {{[one, three]}}.

-- 
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-4358) Multi-projects seem to send interrupt signals to some tasks

2009-09-14 Thread Gustavo Hexsel (JIRA)

Multi-projects seem to send interrupt signals to some tasks
---

 Key: MNG-4358
 URL: http://jira.codehaus.org/browse/MNG-4358
 Project: Maven 2
  Issue Type: Bug
  Components: Plugins and Lifecycle
Affects Versions: 2.2.1
 Environment: All 64 bit.  Ubuntu 9.10 b5, OpenJDK Runtime Environment 
(IcedTea6 1.6) (6b16-1.6-1ubuntu1).
Reporter: Gustavo Hexsel


Tasks like exec:exec and surefire (testing) seem to receive an occasional 
interrupt signal, causing the test or task to fail.  This only happens on 
multi-module projects (i.e. if I run it a module at a time, it works).

Here's an example stacktrace from exec:exec (I can try to reproduce the 
surefire one as well):

[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Command execution failed.

Embedded error: Error while executing external command, process killed.
[INFO] 
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Command execution 
failed.
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:584)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Command execution 
failed.
at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:288)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
... 16 more
Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while 
executing external command, process killed.
at 
org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:199)
at 
org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:93)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:437)
at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:279)
... 18 more
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at java.lang.UNIXProcess.waitFor(UNIXProcess.java:181)
at 
org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:147)
... 21 more


-- 
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: (SCM-497) Please improve documentation on http://maven.apache.org/scm/guide/usage.html

2009-09-14 Thread Albert Kurucz (JIRA)

Please improve documentation on http://maven.apache.org/scm/guide/usage.html


 Key: SCM-497
 URL: http://jira.codehaus.org/browse/SCM-497
 Project: Maven SCM
  Issue Type: Improvement
Affects Versions: 1.2
 Environment: dependency
groupIdorg.apache.maven/groupId
artifactIdmaven-embedder/artifactId
version2.0.4/version
typejar/type
/dependency
dependency
groupIdorg.apache.maven.scm/groupId
artifactIdmaven-scm-api/artifactId
version1.2/version
scopetest/scope
typejar/type
/dependency

Reporter: Albert Kurucz
 Attachments: TestEmbedder.java

Trying to  use Maven-SCM in my application I have selected the With Plexus 
IOC method as provided on http://maven.apache.org/scm/guide/usage.html.
I have made this to a small unit test (attached to this issue), which failed as:

Testsuite: com.jtstand.TestEmbedder
at 
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:323)
at org.codehaus.plexus.embed.Embedder.lookup(Embedder.java:78)
at com.jtstand.TestEmbedder.init(TestEmbedder.java:24)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at junit.framework.TestSuite.createTest(TestSuite.java:54)
at junit.framework.TestSuite.addTestMethod(TestSuite.java:280)
at junit.framework.TestSuite.init(TestSuite.java:140)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:481)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1031)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:888)
))
Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.032 sec

Please improve usage doc on http://maven.apache.org/scm/guide/usage.html.
Please provide me help getting started in this direction.
Thx.


-- 
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: (MNG-4358) Multi-projects seem to send interrupt signals to some tasks

2009-09-14 Thread Gustavo Hexsel (JIRA)


 [ 
http://jira.codehaus.org/browse/MNG-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gustavo Hexsel updated MNG-4358:


Attachment: out.tar.bz

This is the full output of mvn clean install -X

 Multi-projects seem to send interrupt signals to some tasks
 ---

 Key: MNG-4358
 URL: http://jira.codehaus.org/browse/MNG-4358
 Project: Maven 2
  Issue Type: Bug
  Components: Plugins and Lifecycle
Affects Versions: 2.2.1
 Environment: All 64 bit.  Ubuntu 9.10 b5, OpenJDK Runtime Environment 
 (IcedTea6 1.6) (6b16-1.6-1ubuntu1).
Reporter: Gustavo Hexsel
 Attachments: out.tar.bz


 Tasks like exec:exec and surefire (testing) seem to receive an occasional 
 interrupt signal, causing the test or task to fail.  This only happens on 
 multi-module projects (i.e. if I run it a module at a time, it works).
 Here's an example stacktrace from exec:exec (I can try to reproduce the 
 surefire one as well):
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Command execution failed.
 Embedded error: Error while executing external command, process killed.
 [INFO] 
 
 [DEBUG] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: Command execution 
 failed.
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:584)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.apache.maven.plugin.MojoExecutionException: Command execution 
 failed.
   at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:288)
   at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
   ... 16 more
 Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while 
 executing external command, process killed.
   at 
 org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:199)
   at 
 org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:93)
   at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:437)
   at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:279)
   ... 18 more
 Caused by: java.lang.InterruptedException
   at java.lang.Object.wait(Native Method)
   at java.lang.Object.wait(Object.java:502)
   at java.lang.UNIXProcess.waitFor(UNIXProcess.java:181)
   at 
 org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:147)
   ... 21 more

-- 
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-293) Value of ${project.version} is captured before version resolution

2009-09-14 Thread Dmitry Katsubo (JIRA)


[ 
http://jira.codehaus.org/browse/MRELEASE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=190879#action_190879
 ] 

Dmitry Katsubo commented on MRELEASE-293:
-

Currently I see only one workaround for the issue:

1. Specify {{project.rel.org.codehaus.mojo}} and/or 
{{project.dev.org.codehaus.mojo}} from the commend line (see here 
http://maven.apache.org/plugins/maven-release-plugin/examples/non-interactive-release.html
 for more details):

-Dproject.rel.org.codehaus.mojo:jaxws-maven-plugin=1.12.1 
-Dproject.dev.org.codehaus.mojo:jaxws-maven-plugin=1.13-SNAPSHOT

2. Refer then this information from {{pom.xml}}:

  build
plugins
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
configuration
  
tagBasehttps://myserver.com/svn/public/tags/java/jaxws-maven-plugin//tagBase
  tag${project.rel.org.codehaus.mojo:jaxws-maven-plugin}/tag
/configuration
  /plugin
/plugins
  /build


 Value of ${project.version} is captured before version resolution
 -

 Key: MRELEASE-293
 URL: http://jira.codehaus.org/browse/MRELEASE-293
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
  Components: scm
Affects Versions: 2.0-beta-6
 Environment: OS X 10.4.9, Java 5, Maven 2.0.6
Reporter: Jarrod Carlson

 Our organization uses tags in which are the product version and only the 
 product version:
 /tags
 /2.0.1
 /2.0.2
 
 /2.1.12
 The default value of tag is ${project.artifactId}-${project.version} as 
 specified in MRELEASE-53.
 However, when I specify the value of tag as follows:
 tag${project.version}/tag--or--   tag${version}/tag
 release:prepare resolves this to artifact-x.y.z-SNAPSHOT.
 In other words, when a tag is specified, it is taken before the release 
 process finalizes the release number.
 While I can specify the release on the command line, I need to be able to 
 batch mode this process.
 tag${project.version}/tag should resolve to: 2.0.2 (or x.y.z).

-- 
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-4357) [regression] Custom packagings from build extensions are not reliably loaded during a reactor build


 [ 
http://jira.codehaus.org/browse/MNG-4357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bentmann closed MNG-4357.
--

 Assignee: Benjamin Bentmann
   Resolution: Fixed
Fix Version/s: 3.0-alpha-3

Fixed by updating to plexus-container-default:1.2.1+ which contains the 
required fix.

 [regression] Custom packagings from build extensions are not reliably loaded 
 during a reactor build
 ---

 Key: MNG-4357
 URL: http://jira.codehaus.org/browse/MNG-4357
 Project: Maven 2
  Issue Type: Bug
  Components: Plugins and Lifecycle, Reactor and workspace
Affects Versions: 3.0-alpha-3
Reporter: Benjamin Bentmann
Assignee: Benjamin Bentmann
 Fix For: 3.0-alpha-3


 Building XWiki platform with trunk in one go produces
 {noformat}
 [ERROR] Unknown packaging: maven-archetype @ 
 org.xwiki.platform.tools:xwiki-archetype-macro:1.1-SNAPSHOT
 {noformat}
 The mentioned project properly declares the required build extensions in its 
 POM and builds fine in isolation.
 The issue boils down to the active component map 
 {{DefaultLifecycleExecutor.lifecycleMappings}} not being properly updated 
 when switching the projects in the reactor. In detail, 
 {{AbstractComponentCollection.checkUpdate()}} from Plexus doesn't update the 
 map if the number of component descriptors hasn't changed. This apparently 
 misses the situation where the total count of component descriptors from two 
 different class realms is the same but the set of role hints has changed, 
 e.g. {{[one, two]}} vs. {{[one, three]}}.

-- 
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-481) prepare goal no longer errors on subversion files

2009-09-14 Thread Arnaud DOSTES (JIRA)


[ 
http://jira.codehaus.org/browse/MRELEASE-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=190888#action_190888
 ] 

Arnaud DOSTES commented on MRELEASE-481:


Could not reproduce. In dry mode or in normal.

Here are the different outputs I'm getting

2.0-beta-7
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Cannot prepare the release because you have local modifications :
[src\main\java\com\test\App.java:modified]
[pom.xml:modified]

[INFO] 

2.0-beta-8
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Cannot prepare the release because you have local modifications :
[src\main\java\com\test\App.java:modified]
[pom.xml:modified]

[INFO] 

2.0-beta-9
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Cannot prepare the release because you have local modifications :
[src\main\java\com\test\App.java:modified]
[pom.xml:modified]

[INFO] 

2.0-beta-10-SNAPSHOT
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Cannot prepare the release because you have local modifications :
[src\main\java\com\test\App.java:modified]
[pom.xml:modified]

[INFO] 


 prepare goal  no longer errors on subversion files 
 ---

 Key: MRELEASE-481
 URL: http://jira.codehaus.org/browse/MRELEASE-481
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-8
Reporter: Paul Hammant
 Fix For: 2.0-beta-10


 Snow Leopard / Maven 2.2.0 / Svn 1.6.3 (via macports)
 release:prepare used to error telling you that you had files not checked in.
 It no longer does, or no longer does by default :-(
 -ph

-- 
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-2199) Version ranges not supported for parent artifacts

2009-09-14 Thread Todor Boev (JIRA)

[
http://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=190889#action_190889
]

Todor Boev commented on MNG-2199:
-

I think there is an acceptable alternative: Make relativePath pick up the
maven coordinates of the parent pom automatically.

Most multi-module builds form a monolithic tree of poms that is always checked
out atomically. I.e. we have a specific tree layout in the file system that has
module for forwards links and parent for backlinks. If module does not
need full maven coordinates why should parent? Imagine we can use either maven
coordinates or a single relativePath as parent:

parent
relativePath../pom.xml/relativePath
/parent

Than the entire multi-module project can have a single groupId and version set
in the root pom. We would be able to control the common version of this
logical set of artifacts from one file - no more need to edit dozens of
parent clauses for every trivial change. All that is needed is for Maven to
replace relativePath with the actual maven coordinates when we install/deploy.

For that matter why don't we make module accept a set of maven coordinates as
well? Than both the forward and backward links would support two modes: maven
coordinates and the repo or local file system and automatic maven coordinate
interpolation upon install/deploy.

Version ranges not supported for parent artifacts
-

Key: MNG-2199
URL: http://jira.codehaus.org/browse/MNG-2199
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
Fix For: 3.x

It would be great if Maven supports version ranges when specifying parent
artifacts in a multi-module build. Currently this does not work.
parent
artifactIdartifactId/artifactId
groupIdgroupId/groupId
version[2.0, 2.0.1]/version
/parent
[INFO] Scanning for projects...
Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0,
2.0.1]/artifactId-[2.0, 2.0.1].pom
Additionally it would be great if this
parent
artifactIdartifactId/artifactId
groupIdgroupId/groupId
version[2.0, ${pom.version}]/version
/parent
[INFO] Scanning for projects...
Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0,
${pom.version}]/artifactId-[2.0, ${pom.version}].pom
would also work, if the version is specified in the same pom.xml which
defines this parent definition.

--
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-263) No respect for JAVA_HOME or PATH in locating javadoc executable

2009-09-14 Thread Benson Margulies (JIRA)

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] Updated: (MRELEASE-324) There should be a way to update POM version numbers without tagging/branching

2009-09-14 Thread Paul Gier (JIRA)

[
http://jira.codehaus.org/browse/MRELEASE-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Paul Gier updated MRELEASE-324:
---

Fix Version/s: 2.0-beta-10

There should be a way to update POM version numbers without tagging/branching
-

Key: MRELEASE-324
URL: http://jira.codehaus.org/browse/MRELEASE-324
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Components: prepare
Reporter: Dan Fabulich
Assignee: Paul Gier
Fix For: 2.0-beta-10

Updating versions is useful; sometimes you just want to change the version
numbers in your POMs without checking in right away. There should be a way
to do that. It could either be a new goal (release:update-versions) or
simply an option on release:prepare to avoid tagging.
Why would you want this?
... because you need to use svnmerge.py
http://www.orcaware.com/svn/wiki/Svnmerge.py
... because you're using an unsupported SCM MRELEASE-184
... because you need to take other manual steps before tagging (updating
other metadata files)
... because you need to make a branch instead of making a tag MRELEASE-203
... because you're skipping version numbers (I was calling this 1.1-SNAPSHOT,
but now I want to call it 2.0-SNAPSHOT)
... because you don't want to tag until after you've blessed the release (in
the Maven release process, if the vote fails, you have to delete the tag)
... because you want to update your version number to contain special
build-based metadata every time you build

[jira] Commented: (MRELEASE-324) There should be a way to update POM version numbers without tagging/branching

2009-09-14 Thread Paul Gier (JIRA)

[
http://jira.codehaus.org/browse/MRELEASE-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=190898#action_190898
]

Paul Gier commented on MRELEASE-324:

Added a new goal called update-versions in
[r814798|http://svn.apache.org/viewvc?view=revrevision=814798].

There should be a way to update POM version numbers without tagging/branching
-

[jira] Closed: (MRELEASE-324) There should be a way to update POM version numbers without tagging/branching

2009-09-14 Thread Paul Gier (JIRA)

[
http://jira.codehaus.org/browse/MRELEASE-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Paul Gier closed MRELEASE-324.
--

Resolution: Fixed

There should be a way to update POM version numbers without tagging/branching
-

[jira] Reopened: (MNG-4352) Misleading error when bootstrapping Maven build with unexpected installation directory


 [ 
http://jira.codehaus.org/browse/MNG-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey reopened MNG-4352:
-


Something isn't right after this fix. I'm seeing the following in the output 
from Hudson's Windows VM:

{noformat}
BUILD FAILED
C:\home\hudson\workspace\Maven-2.2.x-bootstrap\jdk\1.5\label\windows\maven-2.2.x\build.xml:92:
 Expected M2_HOME to end in apache-maven-2.2.2-RC1-SNAPSHOT but was 
C:\tmp\apache-maven-2.2.2-RC1-SNAPSHOT
{noformat}

The full output is here:

https://grid.sonatype.org/ci/job/Maven-2.2.x-bootstrap/86/jdk=1.5,label=windows/console

 Misleading error when bootstrapping Maven build with unexpected installation 
 directory
 --

 Key: MNG-4352
 URL: http://jira.codehaus.org/browse/MNG-4352
 Project: Maven 2
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.1
 Environment: OpenSUSE x86-64
Reporter: Jose Garcia
Assignee: Brett Porter
 Fix For: 2.2.2


 the execution of the command ant to build from source fails with this 
 message
 extract-assembly:
  [echo] Extracting assembly to /opt ...
[delete] Deleting directory /opt/maven
 [mkdir] Created dir: /opt/maven
 [unzip] Expanding: 
 /root/maven/apache-maven-2.2.1/apache-maven/target/apache-maven-2.2.1-bin.zip 
 into /opt
 BUILD FAILED
 /root/maven/apache-maven-2.2.1/build.xml:224: /opt/maven/bin not found.
 after the line mkdir dir=${maven.home}/bin/ at row 224 was added, it 
 compiles:
 extract-assembly:
  [echo] Extracting assembly to /opt ...
[delete] Deleting directory /opt/maven
 [mkdir] Created dir: /opt/maven
 [mkdir] Created dir: /opt/maven/bin
 [unzip] Expanding: 
 /root/maven/apache-maven-2.2.1/apache-maven/target/apache-maven-2.2.1-bin.zip 
 into /opt
 [chmod] Skipping fileset for directory /opt/maven/bin. It is empty.
 all:
 BUILD SUCCESSFUL
 Total time: 2 minutes 51 seconds

-- 
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-4211) [regression] proxy access broken between maven version 2.0.10 and 2.1. Probably due to addition of wagon 1.0-beta-4+

[
http://jira.codehaus.org/browse/MNG-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=190905#action_190905
]

John Casey commented on MNG-4211:
-

@Frank:

Do you have any information about what type of proxy is being used? Can you
attach a debug log from a failing build? If so, just run with -X and pipe or
redirect the output to a file, then attach that file to this issue.

On linux/mac, I'd do something like this:

{noformat}
mvn -X clean install 21 | tee build.log
{noformat}

[regression] proxy access broken between maven version 2.0.10 and 2.1.
Probably due to addition of wagon 1.0-beta-4+
-

Key: MNG-4211
URL: http://jira.codehaus.org/browse/MNG-4211
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.1.0, 2.2.0
Environment: WinXP SP2
Reporter: Robert Glover Jr
Priority: Blocker
Fix For: 2.2.2

Attachments: jira_files_4_total.zip

At a large company, maven become impossible to use via proxy when maven
upgraded from 1.0.10 to 2.1. maven has always worked fine via proxy in 2.0.9
and continues to work fine. however maven via proxy always fails in version
2.1.0 and higher.
Attached is a zip file containing 1) log of GMAIL chat between the
creater of this JIRA and a maven developer. 2) two console outputs of
running maven 2.2. RC3 showing the proxy failure messages. 3) setting.xml
(with comments stripped out)

[jira] Closed: (MNG-4328) [regression] plugin parameters of primitive types can't be populated from expression


 [ 
http://jira.codehaus.org/browse/MNG-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Bentmann closed MNG-4328.
--

 Assignee: Benjamin Bentmann
   Resolution: Fixed
Fix Version/s: 3.0-alpha-3

Fixed by updating to plexus-container-default:1.2.1+

 [regression] plugin parameters of primitive types can't be populated from 
 expression
 

 Key: MNG-4328
 URL: http://jira.codehaus.org/browse/MNG-4328
 Project: Maven 2
  Issue Type: Bug
  Components: Plugins and Lifecycle
Affects Versions: 3.0-alpha-3
Reporter: Benjamin Bentmann
Assignee: Benjamin Bentmann
 Fix For: 3.0-alpha-3


 {code:java}
 /**
  * @parameter default-value=${settings.offline}
  */
 private boolean offline;
 {code}
 doesn't work due to the changes for MNG-4312. The code doesn't take 
 primitive2wrapper conversions into account.

-- 
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: (MRRESOURCES-44) Document usage of runOnlyAtExecutionRoot and supplemental model features.


 [ 
http://jira.codehaus.org/browse/MRRESOURCES-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey closed MRRESOURCES-44.
-

Resolution: Fixed

 Document usage of runOnlyAtExecutionRoot and supplemental model features.
 -

 Key: MRRESOURCES-44
 URL: http://jira.codehaus.org/browse/MRRESOURCES-44
 Project: Maven 2.x Remote Resources Plugin
  Issue Type: Task
Affects Versions: 1.0, 1.1
Reporter: John Casey
Assignee: John Casey
 Fix For: 1.1


 new feature runOnlyAtExecutionRoot needs documentation, as does all of the 
 supplemental models stuff, from what I can see. In any case, the new 
 supplemental-model artifact feature needs documentation.

-- 
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-4352) Misleading error when bootstrapping Maven build with unexpected installation directory

2009-09-14 Thread Brett Porter (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=190924#action_190924
 ] 

Brett Porter commented on MNG-4352:
---

is it only on windows? it could be trying to compare / to \.

Sorry about that - if you haven't got to it already I'll fix later today with 
my windows machine to test.

 Misleading error when bootstrapping Maven build with unexpected installation 
 directory
 --

 Key: MNG-4352
 URL: http://jira.codehaus.org/browse/MNG-4352
 Project: Maven 2
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.1
 Environment: OpenSUSE x86-64
Reporter: Jose Garcia
Assignee: Brett Porter
 Fix For: 2.2.2


 the execution of the command ant to build from source fails with this 
 message
 extract-assembly:
  [echo] Extracting assembly to /opt ...
[delete] Deleting directory /opt/maven
 [mkdir] Created dir: /opt/maven
 [unzip] Expanding: 
 /root/maven/apache-maven-2.2.1/apache-maven/target/apache-maven-2.2.1-bin.zip 
 into /opt
 BUILD FAILED
 /root/maven/apache-maven-2.2.1/build.xml:224: /opt/maven/bin not found.
 after the line mkdir dir=${maven.home}/bin/ at row 224 was added, it 
 compiles:
 extract-assembly:
  [echo] Extracting assembly to /opt ...
[delete] Deleting directory /opt/maven
 [mkdir] Created dir: /opt/maven
 [mkdir] Created dir: /opt/maven/bin
 [unzip] Expanding: 
 /root/maven/apache-maven-2.2.1/apache-maven/target/apache-maven-2.2.1-bin.zip 
 into /opt
 [chmod] Skipping fileset for directory /opt/maven/bin. It is empty.
 all:
 BUILD SUCCESSFUL
 Total time: 2 minutes 51 seconds

-- 
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: (MRRESOURCES-45) Stage releases for dependencies that have changed


 [ 
http://jira.codehaus.org/browse/MRRESOURCES-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Casey closed MRRESOURCES-45.
-

Resolution: Fixed

 Stage releases for dependencies that have changed
 -

 Key: MRRESOURCES-45
 URL: http://jira.codehaus.org/browse/MRRESOURCES-45
 Project: Maven 2.x Remote Resources Plugin
  Issue Type: Task
Affects Versions: 1.1
Reporter: John Casey
Assignee: John Casey
Priority: Blocker
 Fix For: 1.1


 maven/shared maven-artifact-resolver 1.0
 maven/shared maven-verifier 1.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: (MNG-4352) Misleading error when bootstrapping Maven build with unexpected installation directory


[ 
http://jira.codehaus.org/browse/MNG-4352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=190936#action_190936
 ] 

John Casey commented on MNG-4352:
-

yeah, sorry, I didn't have the bandwidth to do any more than reopen the issue. 
I've been racing headlong to get the MRRESOURCES plugin ready for a release.

 Misleading error when bootstrapping Maven build with unexpected installation 
 directory
 --

 Key: MNG-4352
 URL: http://jira.codehaus.org/browse/MNG-4352
 Project: Maven 2
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.1
 Environment: OpenSUSE x86-64
Reporter: Jose Garcia
Assignee: Brett Porter
 Fix For: 2.2.2


 the execution of the command ant to build from source fails with this 
 message
 extract-assembly:
  [echo] Extracting assembly to /opt ...
[delete] Deleting directory /opt/maven
 [mkdir] Created dir: /opt/maven
 [unzip] Expanding: 
 /root/maven/apache-maven-2.2.1/apache-maven/target/apache-maven-2.2.1-bin.zip 
 into /opt
 BUILD FAILED
 /root/maven/apache-maven-2.2.1/build.xml:224: /opt/maven/bin not found.
 after the line mkdir dir=${maven.home}/bin/ at row 224 was added, it 
 compiles:
 extract-assembly:
  [echo] Extracting assembly to /opt ...
[delete] Deleting directory /opt/maven
 [mkdir] Created dir: /opt/maven
 [mkdir] Created dir: /opt/maven/bin
 [unzip] Expanding: 
 /root/maven/apache-maven-2.2.1/apache-maven/target/apache-maven-2.2.1-bin.zip 
 into /opt
 [chmod] Skipping fileset for directory /opt/maven/bin. It is empty.
 all:
 BUILD SUCCESSFUL
 Total time: 2 minutes 51 seconds

-- 
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-4352) Misleading error when bootstrapping Maven build with unexpected installation directory