[jira] Commented: (MNG-3685) Dependency can't be resolved but has been found in the reactor.

2009-07-20 Thread Antony Stubbs (JIRA)

[ 
http://jira.codehaus.org/browse/MNG-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=184082#action_184082
 ] 

Antony Stubbs commented on MNG-3685:


I've also hit the problem, even using
 mvn release:prepare -DautoVersionSubmodules=true -DpreparationGoals=clean 
install
work around I used was to checkout the commit with the release versions 
separately and do a mvn install

 Dependency can't be resolved but has been found in the reactor.
 ---

 Key: MNG-3685
 URL: http://jira.codehaus.org/browse/MNG-3685
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.0.9
Reporter: Jörg Hohwiller
 Fix For: 2.2.2

 Attachments: sample-MNG-3685.tgz


 Since I upgraded maven to 2.0.9, I get messages like the following endlessly:
 Downloading: 
 http://m-m-m.sourceforge.net/repository/net/sf/m-m-m/mmm-util-core/1.0.2-SNAPSHOT/mmm-util-core-1.0.2-SNAPSHOT.jar
 [WARNING] The dependency: net.sf.m-m-m:mmm-util-core:jar:1.0.2-SNAPSHOT can't 
 be resolved but has been found in the reactor.
 This dependency has been excluded from the plugin execution. You should rerun 
 this mojo after executing mvn install.
 This also happens, if someone checks out the project and does mvn 
 eclipse:eclipse. The process still works but takes extraordinary long to 
 proceed because it scales about n^2 with n beiing the number of modules in 
 your reactor.
 You should also take into account that mvn install aborts if some tests 
 fail.
 Sorry to say so, but this behaviour of maven is absolutely inacceptable. I 
 hope there is a chance to fix this in the next release(s). Thanks!

-- 
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: (MANTTASKS-157) Manven-ant-tasks do not use servers list from maven conf

2009-07-20 Thread Krashan Brahmanjara (JIRA)

[ 
http://jira.codehaus.org/browse/MANTTASKS-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=184107#action_184107
 ] 

Krashan Brahmanjara commented on MANTTASKS-157:
---

I  can not agree with Benjamin. 
In Maven 2.1 and 2.2 users can define mupltiple mirrors (for central too). This 
feature is well documented on maven pages. It really works.
You can see searching method on console log :
artifact:dependencies] Downloading: 
org/icefaces/icefaces/1.8.1/icefacs-1.8.1.pom from central
artifact:dependencies] Downloading: 
org/icefaces/icefaces/1.8.1/icefacs-1.8.1.pom from apache.releases
artifact:dependencies] Downloading: 
org/icefaces/icefaces/1.8.1/icefacs-1.8.1.pom from jboss.mirror
artifact:dependencies] Downloading: 
org/icefaces/icefaces/1.8.1/icefacs-1.8.1.pom from krokodylowy3.thirdparty
artifact:dependencies] Downloading: 
org/icefaces/icefaces/1.8.1/icefacs-1.8.1.pom from central


I suppose that maven-ant-tasks don't use maven install files so maven 
configuration is useless and all should be defined in pom or ant file

 Manven-ant-tasks do not use servers list from maven conf
 

 Key: MANTTASKS-157
 URL: http://jira.codehaus.org/browse/MANTTASKS-157
 Project: Maven 2.x Ant Tasks
  Issue Type: Bug
Affects Versions: 2.0.10
Reporter: Krashan Brahmanjara

 I got simply ant and pom project. Settings file for maven 2.1 contains list 
 of mirror servers.
 If I compile project by mvn package everything works ok - artifacts are 
 downloaded
 if I compile the same project by ant and maven-ant-tasks some artifacts are 
 not downloaded. it looks like the mirrors list are sometimes ignored.
 Current workaroud is add to pom.xml repository entries which are duplicate of 
 mirrors from maven configuration.
 maven settings
 mirrors
mirror
   idkrokodylowy3/id
   urlhttp://krokodylowy3.webpark.pl/maven/m2/repository/url
   mirrorOfcentral/mirrorOf
 /mirror
mirror
   idApache.releases/id
   urlhttps://repository.apache.org/content/repositories/releases//url
   mirrorOfcentral/mirrorOf
 /mirror
mirror
   idApache.snapshots/id
   urlhttps://repository.apache.org/content/repositories/snapshots//url
   mirrorOfcentral/mirrorOf
 /mirror
mirror
   idrepository.jboss.org/id
   urlhttp://repository.jboss.org/maven2/url
   mirrorOfcentral/mirrorOf
 /mirror
 mirror
   idrepo1.maven.org/id
   urlhttp://repo1.maven.org/maven2/url
   mirrorOf*/mirrorOf
 /mirror
   /mirrors
 workaround
   repositories
   repository
   idthirdparty/id
   namekrokodylowy3 thirdparty/name
   
 urlhttp://krokodylowy3.webpark.pl/maven/m2/repository/url
   /repository
   repository
   idjboss/id
   namejboss thirdparty/name
   urlhttp://repository.jboss.org/maven2/url
   /repository
   /repositories

-- 
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-460) Please upgrade to JDOM 1.1; current JDOM 1.0 contains a bug in parsing comments starting with hyphen

2009-07-20 Thread Andrew Lynch (JIRA)

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

Andrew Lynch updated MRELEASE-460:
--

Attachment: MRELEASE-460.patch

Patch attached with test case and fix (simple change to pom for 
maven-release-manager )

 Please upgrade to JDOM 1.1;  current JDOM 1.0 contains a bug in parsing 
 comments starting with hyphen
 -

 Key: MRELEASE-460
 URL: http://jira.codehaus.org/browse/MRELEASE-460
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
  Components: prepare
Affects Versions: 2.0-beta-9
Reporter: Andrew Lynch
 Attachments: MRELEASE-460.patch


 The current maven release plugin fails if an XML comment started with three 
 dashes, even though this is legal XML syntax.  This is dues to a bug in JDOM, 
 fixed in version 1.1 ( see http://jdom.markmail.org/message/b45honrv3crcmqux )
 An example:   
 !---dependency
 groupIdcom.p6spy/groupId
 artifactIdp6spy/artifactId
 version1.3/version
 /dependency--
 Fails with the following error:
 [INFO] Transforming 'BGC Refund Reader Service'...
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] The data -dependency
 groupIdcom.p6spy/groupId
 artifactIdp6spy/artifactId
 version1.3/version
 /dependency is not legal for a JDOM 
 comment: C
 omment data cannot start with a hyphen..
 [INFO] 
 
 [INFO] Trace
 org.jdom.IllegalDataException: The data -dependency
 groupIdcom.p6spy/groupId
 artifactIdp6spy/artifactId
 version1.3/version
 /dependency is not legal for a JDOM 
 comment: C
 omment data cannot start with a hyphen..
 at org.jdom.Comment.setText(Comment.java:120)
 at org.jdom.Comment.init(Comment.java:86)
 at org.jdom.DefaultJDOMFactory.comment(DefaultJDOMFactory.java:105)

-- 
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: (MANTTASKS-157) Manven-ant-tasks do not use servers list from maven conf

2009-07-20 Thread Benjamin Bentmann (JIRA)

[ 
http://jira.codehaus.org/browse/MANTTASKS-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=184114#action_184114
 ] 

Benjamin Bentmann commented on MANTTASKS-157:
-

bq. In Maven 2.1 and 2.2 users can define mupltiple mirrors (for central too). 
This feature is well documented on maven pages.
Could you give some pointers to this well documented feature?

 Manven-ant-tasks do not use servers list from maven conf
 

 Key: MANTTASKS-157
 URL: http://jira.codehaus.org/browse/MANTTASKS-157
 Project: Maven 2.x Ant Tasks
  Issue Type: Bug
Affects Versions: 2.0.10
Reporter: Krashan Brahmanjara

 I got simply ant and pom project. Settings file for maven 2.1 contains list 
 of mirror servers.
 If I compile project by mvn package everything works ok - artifacts are 
 downloaded
 if I compile the same project by ant and maven-ant-tasks some artifacts are 
 not downloaded. it looks like the mirrors list are sometimes ignored.
 Current workaroud is add to pom.xml repository entries which are duplicate of 
 mirrors from maven configuration.
 maven settings
 mirrors
mirror
   idkrokodylowy3/id
   urlhttp://krokodylowy3.webpark.pl/maven/m2/repository/url
   mirrorOfcentral/mirrorOf
 /mirror
mirror
   idApache.releases/id
   urlhttps://repository.apache.org/content/repositories/releases//url
   mirrorOfcentral/mirrorOf
 /mirror
mirror
   idApache.snapshots/id
   urlhttps://repository.apache.org/content/repositories/snapshots//url
   mirrorOfcentral/mirrorOf
 /mirror
mirror
   idrepository.jboss.org/id
   urlhttp://repository.jboss.org/maven2/url
   mirrorOfcentral/mirrorOf
 /mirror
 mirror
   idrepo1.maven.org/id
   urlhttp://repo1.maven.org/maven2/url
   mirrorOf*/mirrorOf
 /mirror
   /mirrors
 workaround
   repositories
   repository
   idthirdparty/id
   namekrokodylowy3 thirdparty/name
   
 urlhttp://krokodylowy3.webpark.pl/maven/m2/repository/url
   /repository
   repository
   idjboss/id
   namejboss thirdparty/name
   urlhttp://repository.jboss.org/maven2/url
   /repository
   /repositories

-- 
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-145) If Javadoc is set to aggregate, the build fails inside a Maven plugin module

2009-07-20 Thread Martin Desruisseaux (JIRA)

[ 
http://jira.codehaus.org/browse/MJAVADOC-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=184118#action_184118
 ] 

Martin Desruisseaux commented on MJAVADOC-145:
--

Is this bug really fixed? I'm using Maven 2.1 with {{maven-javadoc-plugin}} 2.5 
in a project having a few Maven plugins, and still get _Error extracting 
plugin descriptor: Goal already exists in the plugin descriptor_ when running 
{{mvn clean install site}}. The same command without the {{site}} goal works 
fine. Removing the aggregated javadoc configuration from the {{reporting}} 
section in the root {{pom.xml}} fixes the build as well.


 If Javadoc is set to aggregate, the build fails inside a Maven plugin module
 

 Key: MJAVADOC-145
 URL: http://jira.codehaus.org/browse/MJAVADOC-145
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Howard M. Lewis Ship
Assignee: Vincent Siveton
Priority: Critical
 Fix For: 2.4

 Attachments: ComponentReport.java, maven.out, pom.xml, pom.xml


 If your project contains a Maven plugin, then it is impossible to build 
 aggregated Javadoc.
 As the output (attached) shows, Maven seems to recusively build (what's with 
 all those skipping messages?).  When it reaches the plugin:
 [INFO] Error during page generation
 Embedded error: Error rendering Maven report: Error extracting plugin 
 descriptor: 'Goal: component-report already exists in the plugin descriptor 
 for prefix: tapestry-component-report
 Existing implementation is: org.apache.tapestry.mojo.ComponentReport
 Conflicting implementation is: org.apache.tapestry.mojo.ComponentReport'
 I  can get by this with the -fn (fail never) option.

-- 
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

2009-07-20 Thread Martin Desruisseaux (JIRA)

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

Martin Desruisseaux commented on MJAVADOC-134:
--

Actually I'm interrested in a variant of this request, where the javadoc is 
aggregated only starting from the submodule which ask for it. Such feature 
could (maybe) help to workaround MJAVADOC-145 (closed, but the issue reported 
in that task still occurs in my project and I have not yet found a workaround), 
if we can avoid the aggregation of javadoc for Maven plugins.


 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] Closed: (MJAVADOC-97) enable internal/external dependency references as links

2009-07-20 Thread Vincent Siveton (JIRA)

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

Vincent Siveton closed MJAVADOC-97.
---

 Assignee: Vincent Siveton  (was: Kenney Westerhof)
   Resolution: Fixed
Fix Version/s: 2.6

Fixed in [r795801|http://svn.apache.org/viewvc?rev=795801view=rev]

I added two new parameters: detectLinks and detectOfflineLinks
Using detectlinks parameter, it *tries* to add dependencies Javadoc links, ie  
if you have

{noformat}
dependency
   groupIdcommons-lang/groupId
   artifactIdcommons-lang/artifactId
 /dependency
{noformat}

The added Javadoc link will be http://commons.apache.org/lang/apidocs.

Using detectOfflineLinks, all modules javadoc dirs are added as offlinelinks.

 enable internal/external dependency references as links 
 

 Key: MJAVADOC-97
 URL: http://jira.codehaus.org/browse/MJAVADOC-97
 Project: Maven 2.x Javadoc Plugin
  Issue Type: New Feature
Affects Versions: 2.1
Reporter: Richard van Nieuwenhoven
Assignee: Vincent Siveton
Priority: Minor
 Fix For: 2.6

 Attachments: maven-javadoc-plugin-2.1.patch, 
 MJAVADOC-97-maven-javadoc-plugin.patch


 This patch enables the java doc plugin to autmaticaly connect the dependent 
 javadoc pages as links.
 There is no more need to add links in your pom's for internal and external 
 maven projects.
 The plugin resolves the dependencies and adds the defined project url's 
 extended with /apidocs to the links in the plugin.
 TODO: a warning occures when the project has no javadocs (or no maven 
 generated javadoc on its homepage) .. 

-- 
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-145) If Javadoc is set to aggregate, the build fails inside a Maven plugin module

2009-07-20 Thread Vincent Siveton (JIRA)

[ 
http://jira.codehaus.org/browse/MJAVADOC-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=184125#action_184125
 ] 

Vincent Siveton commented on MJAVADOC-145:
--

Martin, it should be. 
If you have an error, please create a new issue *with* a test project, I will 
have a look to.

 If Javadoc is set to aggregate, the build fails inside a Maven plugin module
 

 Key: MJAVADOC-145
 URL: http://jira.codehaus.org/browse/MJAVADOC-145
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Howard M. Lewis Ship
Assignee: Vincent Siveton
Priority: Critical
 Fix For: 2.4

 Attachments: ComponentReport.java, maven.out, pom.xml, pom.xml


 If your project contains a Maven plugin, then it is impossible to build 
 aggregated Javadoc.
 As the output (attached) shows, Maven seems to recusively build (what's with 
 all those skipping messages?).  When it reaches the plugin:
 [INFO] Error during page generation
 Embedded error: Error rendering Maven report: Error extracting plugin 
 descriptor: 'Goal: component-report already exists in the plugin descriptor 
 for prefix: tapestry-component-report
 Existing implementation is: org.apache.tapestry.mojo.ComponentReport
 Conflicting implementation is: org.apache.tapestry.mojo.ComponentReport'
 I  can get by this with the -fn (fail never) option.

-- 
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: (MSHARED-109) Add ranges in filters

2009-07-20 Thread Benoit Lafontaine (JIRA)
Add ranges in filters
-

 Key: MSHARED-109
 URL: http://jira.codehaus.org/browse/MSHARED-109
 Project: Maven Shared Components
  Issue Type: Improvement
  Components: maven-common-artifact-filters
Reporter: Benoit Lafontaine


To be able to have such a filter :

my.company:*:::[12.0,12.3)

-- 
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: (MINVOKER-87) Invoker install goal fails when used in eclipse

2009-07-20 Thread Benjamin Bentmann (JIRA)

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

Benjamin Bentmann closed MINVOKER-87.
-

  Assignee: Benjamin Bentmann
Resolution: Won't Fix

There's an option named [Resolve workspace 
artifacts|http://docs.codehaus.org/display/MAVEN/Running+and+debugging+Maven+2.1+from+m2e+workspace]
 in M2Eclipse. For Maven launch configurations that go beyond {{package}} 
phase, that should be disabled to restore Maven's original dependency 
resolution. See also 
[MNGECLIPSE-1134|https://issues.sonatype.org/browse/MNGECLIPSE-1134].

 Invoker install goal fails when used in eclipse
 ---

 Key: MINVOKER-87
 URL: http://jira.codehaus.org/browse/MINVOKER-87
 Project: Maven 2.x Invoker Plugin
  Issue Type: Bug
Affects Versions: 1.3
Reporter: Lee Thompson
Assignee: Benjamin Bentmann

 Using maven-invoker-plugin works great on the command line.
 When used with eclipse, the install goal will fail to install a previous 
 module's jar file into localRepositoryPath.  A workaround is to use 
 maven-install-plugin instead.
 [DEBUG] Configuring mojo 
 'org.apache.maven.plugins:maven-invoker-plugin:1.3:install' --
 [DEBUG]   (f) localRepository = 
 Repository[local|file:///Users/Lee/.m2/repository]
 [DEBUG]   (f) localRepositoryPath = 
 /Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/target/it-repo
 [DEBUG]   (f) project = MavenProject: 
 org.codehaus.mojo:patch-maven-plugin:1.0-beta-1-SNAPSHOT @ 
 /Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/pom.xml
 [DEBUG]   (f) reactorProjects = [MavenProject: 
 org.codehaus.mojo:cbuild-parent:1.0-beta-1-SNAPSHOT @ 
 /Users/Lee/Documents/workspace/c-builds/pom.xml, MavenProject: 
 org.codehaus.mojo:cbuild-tool-parent:1.0-beta-1-SNAPSHOT @ 
 /Users/Lee/Documents/workspace/c-builds/downloader/pom.xml, MavenProject: 
 org.codehaus.mojo:cbuild-utils:1.0-beta-1-SNAPSHOT @ 
 /Users/Lee/Documents/workspace/c-builds/cbuild-utils/pom.xml, MavenProject: 
 org.codehaus.mojo:cbuild-plugin-parent:1.0-beta-1-SNAPSHOT @ 
 /Users/Lee/Documents/workspace/c-builds/plugins/pom.xml, MavenProject: 
 org.codehaus.mojo:cbuild-lifecycles:1.0-beta-1-SNAPSHOT @ 
 /Users/Lee/Documents/workspace/c-builds/plugins/cbuild-lifecycles/pom.xml, 
 MavenProject: org.codehaus.mojo:rpm-cbuild-maven-plugin:1.0-beta-1-SNAPSHOT @ 
 /Users/Lee/Documents/workspace/c-builds/plugins/rpm-cbuild-maven-plugin/pom.xml,
  MavenProject: org.codehaus.mojo:patch-maven-plugin:1.0-beta-1-SNAPSHOT @ 
 /Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/pom.xml, 
 MavenProject: org.codehaus.mojo:make-maven-plugin:1.0-beta-1-SNAPSHOT @ 
 /Users/Lee/Documents/workspace/c-builds/plugins/make-maven-plugin/pom.xml, 
 MavenProject: org.codehaus.mojo:shell-maven-plugin:1.0-beta-1-SNAPSHOT @ 
 /Users/Lee/Documents/workspace/c-builds/plugins/shell-maven-plugin/pom.xml, 
 MavenProject: 
 org.codehaus.mojo:build-on-demand-maven-plugin:1.0-beta-1-SNAPSHOT @ 
 /Users/Lee/Documents/workspace/c-builds/plugins/build-on-demand-maven-plugin/pom.xml]
 [DEBUG] -- end configuration --
 [INFO] [invoker:install {execution: integration-test}]
 [DEBUG] On Install: Using artifact file for POM: 
 org.codehaus.mojo:patch-maven-plugin:pom:1.0-beta-1-SNAPSHOT
 [DEBUG] WARNING: Artifact: 
 org.codehaus.mojo:patch-maven-plugin:pom:1.0-beta-1-SNAPSHOT does not have 
 project-builder metadata (ProjectBuilderConfiguration) associated with it.
 Cannot access CLI properties for version transformation.
 [INFO] Installing 
 /Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/target/pom-transformed.xml
  to 
 /Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/target/it-repo/org/codehaus/mojo/patch-maven-plugin/1.0-beta-1-SNAPSHOT/patch-maven-plugin-1.0-beta-1-SNAPSHOT.pom
 [INFO] Installing 
 /Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/target/patch-maven-plugin-1.0-beta-1-SNAPSHOT.jar
  to 
 /Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/target/it-repo/org/codehaus/mojo/patch-maven-plugin/1.0-beta-1-SNAPSHOT/patch-maven-plugin-1.0-beta-1-SNAPSHOT.jar
 [DEBUG] On Install: Using artifact file for POM: 
 org.codehaus.mojo:cbuild-plugin-parent:pom:1.0-beta-1-SNAPSHOT
 [INFO] Installing 
 /Users/Lee/Documents/workspace/c-builds/plugins/target/pom-transformed.xml to 
 /Users/Lee/Documents/workspace/c-builds/plugins/patch-maven-plugin/target/it-repo/org/codehaus/mojo/cbuild-plugin-parent/1.0-beta-1-SNAPSHOT/cbuild-plugin-parent-1.0-beta-1-SNAPSHOT.pom
 [DEBUG] On Install: Using artifact file for POM: 
 org.codehaus.mojo:cbuild-parent:pom:1.0-beta-1-SNAPSHOT
 [INFO] Installing 
 /Users/Lee/Documents/workspace/c-builds/target/pom-transformed.xml to 
 

[jira] Commented: (MDEP-145) Outputting dependency resolution/tree in a well known _machine readable_ output format

2009-07-20 Thread luke w patterson (JIRA)

[ 
http://jira.codehaus.org/browse/MDEP-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=184141#action_184141
 ] 

luke w patterson commented on MDEP-145:
---

Any plans to output XML POMish format?

dependencies
  dependency
groupIdfooGroupId/groupId
artifactIdfooArtifactId/artifactId
version1/version
scopecompile/scope
  /dependency
  dependency
groupIdbarGroupId/groupId
artifactIdbarArtifactId/artifactId
version1/version
scopetest/scope
  /dependency
/dependencies

 Outputting dependency resolution/tree in a well known _machine readable_ 
 output format
 --

 Key: MDEP-145
 URL: http://jira.codehaus.org/browse/MDEP-145
 Project: Maven 2.x Dependency Plugin
  Issue Type: Improvement
  Components: resolve, tree
Affects Versions: 2.0
Reporter: Samuel Le Berrigaud
Assignee: Brian Fox
 Fix For: 2.2

 Attachments: MDEP-145.zip, treegraph.patch


 Currently (at least on trunk) one can output the dependencies in a file. 
 However the file output doesn't follow any specific format, except from being 
 the exact same output than on the console.
 I would be nice to have an easily parse-able, format  so that tools could 
 leverage the dependency resolution/tree. I am thinking for example of 
 continuous integration tools that could report on added/removed/updated 
 dependencies on modules.
 The format could be xml, json or something else. I've been playing with the 
 current output to make it so that:
 * the first line describes the current module for which dependency resolution 
 is done, formatted as such: {{groupId:artifactId:packaging:version}}
 * every following line is a dependency (indented by 2 or more spaces), 
 formatted as such: {{groupId:artifactId:packaging:version:scope}}
 This already is easy to parse.
 What do you think?

-- 
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: (WAGON-276) Read timed out during release:perform after updating to Maven 2.2

2009-07-20 Thread Dennis Kieselhorst (JIRA)
Read timed out during release:perform after updating to Maven 2.2
-

 Key: WAGON-276
 URL: http://jira.codehaus.org/browse/WAGON-276
 Project: Maven Wagon
  Issue Type: Bug
 Environment: Windows XP, Java 1.6, Maven 2.2
Reporter: Dennis Kieselhorst
Priority: Blocker


Artifact deployment fails with Maven 2.2:

[INFO] [DEBUG] Read timed out
[INFO] java.net.SocketTimeoutException: Read timed out
[INFO]  at java.net.SocketInputStream.socketRead0(Native Method)
[INFO]  at java.net.SocketInputStream.read(SocketInputStream.java:129)
[INFO]  at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
[INFO]  at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
[INFO]  at 
hidden.org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
[INFO]  at 
hidden.org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
[INFO]  at 
hidden.org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
[INFO]  at 
hidden.org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1413)
[INFO]  at 
hidden.org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
[INFO]  at 
hidden.org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
[INFO]  at 
hidden.org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
[INFO]  at 
hidden.org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
[INFO]  at 
hidden.org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
[INFO]  at 
hidden.org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
[INFO]  at 
hidden.org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
[INFO]  at 
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.execute(AbstractHttpClientWagon.java:446)
[INFO]  at 
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:330)
[INFO]  at 
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:280)
[INFO]  at 
org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:262)
[INFO]  at 
org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:172)
[INFO]  at 
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107)
[INFO]  at 
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:173)
[INFO]  at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
[INFO]  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
[INFO]  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
[INFO]  at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
[INFO]  at 
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
[INFO]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO]  at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[INFO]  at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[INFO]  at java.lang.reflect.Method.invoke(Method.java:597)
[INFO]  at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
[INFO]  at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
[INFO]  at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
[INFO]  at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] [INFO] 

[INFO] [ERROR] BUILD ERROR
[INFO] [INFO] 

[INFO] [INFO] Error deploying artifact: Read timed out
[INFO]
[INFO] [INFO] 

[INFO] [DEBUG] Trace
[INFO] org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying 
artifact: Read timed out
[INFO]  at 

[jira] Updated: (MSHARED-109) Add ranges in filters

2009-07-20 Thread Benoit Lafontaine (JIRA)

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

Benoit Lafontaine updated MSHARED-109:
--

Attachment: version-ranges.patch

Path with unit tests and proposed solution

 Add ranges in filters
 -

 Key: MSHARED-109
 URL: http://jira.codehaus.org/browse/MSHARED-109
 Project: Maven Shared Components
  Issue Type: Improvement
  Components: maven-common-artifact-filters
Reporter: Benoit Lafontaine
 Attachments: version-ranges.patch


 To be able to have such a filter :
 my.company:*:::[12.0,12.3)

-- 
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-2979) Cross module dependencies for multi-module site

2009-07-20 Thread John Casey (JIRA)

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

John Casey updated MNG-2979:


Fix Version/s: (was: 2.2.0)
   2.2.2

 Cross module dependencies for multi-module site
 ---

 Key: MNG-2979
 URL: http://jira.codehaus.org/browse/MNG-2979
 Project: Maven 2
  Issue Type: Improvement
  Components: Artifacts and Repositories
Affects Versions: 2.0.5
 Environment: Linux 2.6.18-gentoo-r6 #2 SMP PREEMPT Wed Feb 28 
 10:25:50 CET 2007 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux
Reporter: Wally Wallou
Assignee: John Casey
Priority: Minor
 Fix For: 2.2.2

 Attachments: build.log, gwttk-m2.zip, maven-core-2.0.11-SNAPSHOT.jar, 
 maven.diff, maven.diff, mng-2979-testcase.tar.gz, package.txt, site.txt, 
 to-package.log


 Considering a multi-module project A which declares two sub-projects 
 (modules) B and C. Having module C indicating in its POM a dependency against 
 module B. Compilation and packaging work great without having to install 
 module B in maven local repository, it locate module B for module C using 
 declared aggregation at top level project A.
 But for site goals it does not work, that is to say when maven try to 
 generate site for module C it tells that module B artifact cannot be found. 
 So we have to install module B to be able to generate module C site, whereas 
 it is not necessary for compile or package goals.
 I think it would be great if site goals behaves like compile and package with 
 aggregation. It would be more coherent, and avoid to have to run install just 
 for site goals.

-- 
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-4148) Apply profiles from settings.xml to POMs built from the repository

2009-07-20 Thread John Casey (JIRA)

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

John Casey updated MNG-4148:


Fix Version/s: (was: 2.2.x)
   2.2.2

 Apply profiles from settings.xml to POMs built from the repository
 --

 Key: MNG-4148
 URL: http://jira.codehaus.org/browse/MNG-4148
 Project: Maven 2
  Issue Type: Improvement
  Components: Artifacts and Repositories, POM, Profiles
Affects Versions: 2.1.0
Reporter: John Casey
 Fix For: 2.2.2

 Attachments: test-mng3553.zip


 When we declare a profile in the settings.xml, it will never be applied to 
 POMs loaded from the Maven repository. This means that overriding the central 
 repository definition - for instance - cannot be done without using mirror 
 definitions, since transitive dependencies (any dependency of a direct 
 dependency) will skip the modified definition and use the original from the 
 super-POM instead.
 I'm attaching a testing setup that was originally reported for MNG-3553, 
 which exhibits this problem when dealing with scope == import. The 
 instructions for using it are as follows:
 {noformat}
 I installed locally a nexus server (1.3.3 Open Source) and I'm using maven 
 2.1.0 (I reproduced the issue with 2.0.10).
 In the releases repository of nexus you upload all artifacts given in the 
 toUpload directory :
 * parent 1.0.0 pom
 * dependencies 1.0.0 pom
 * module 1.0.0 pom and jar
 You'll find in the root of the archive my settings. It defines to use nexus 
 for the central repository.
 You launch a build of the project and you'll have :
 [INFO] Scanning for projects...
 [INFO] 
 
 [INFO] Building Unnamed - 
 org.apache.maven.it.mng3553:project:jar:1.0.0-SNAPSHOT
 [INFO]task-segment: [install]
 [INFO] 
 
 [INFO] [resources:resources]
 [WARNING] Using platform encoding (Cp1252 actually) to copy filtered 
 resources, i.e. build is platform dependent!
 [INFO] skip non existing resourceDirectory 
 E:\jtb\workspaces\tests\test-mng3553\project\src\main\resources
 Downloading: 
 http://localhost:8081/nexus/content/groups/public//org/apache/maven/it/mng3553/module/1.0.0/module-1.0.0.pom
 867b downloaded  (module-1.0.0.pom)
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/it/mng3553/dependencies/1.0.0/dependencies-1.0.0.pom
 [WARNING] Unable to get resource 
 'org.apache.maven.it.mng3553:dependencies:pom:1.0.0' from repository central 
 (http://repo1.maven.org/maven2): Authorization fai
 led: Access denied to: 
 http://repo1.maven.org/maven2/org/apache/maven/it/mng3553/dependencies/1.0.0/dependencies-1.0.0.pom
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Failed to resolve artifact.
 GroupId: org.apache.maven.it.mng3553
 ArtifactId: dependencies
 Version: 1.0.0
 Reason: Unable to download the artifact from any repository
   org.apache.maven.it.mng3553:dependencies:pom:1.0.0
 from the specified remote repositories:
   central (http://repo1.maven.org/maven2)
 [INFO] 
 
 [INFO] For more information, run Maven with the -e switch
 [INFO] 
 
 [INFO] Total time: 1 second
 [INFO] Finished at: Thu Apr 30 15:19:47 CEST 2009
 [INFO] Final Memory: 6M/254M
 [INFO] 
 
 You can see that the project downloads successfully the module-1.0.0 from 
 nexus but it fails for depencencies which is an import. It tries to download 
 it from the real central repository and not from the one I defined in my 
 settings.
 The behavior is inconsistent...
 {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] Created: (SCM-483) Update SCM Perforce Provider to use P4Java

2009-07-20 Thread Tom Rodriguez (JIRA)
Update SCM Perforce Provider to use P4Java
--

 Key: SCM-483
 URL: http://jira.codehaus.org/browse/SCM-483
 Project: Maven SCM
  Issue Type: Improvement
  Components: maven-scm-provider-perforce
Affects Versions: 1.2
Reporter: Tom Rodriguez


Perforce has developed a new Java Native API for access to perforce called 
P4Java.  You can access it here: 
ftp://ftp.perforce.com/perforce/r09.1/bin.java/p4java.zip.  This completely 
reworked API does not require that the p4 client be installed on the system.  
The SCM Perforce Provider should be modified to use this new native java API to 
eliminate the many issues involved with depending on the p4 executable.


-- 
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-240) Add default Javadoc link depending the values of maven-compiler-plugin configuration

2009-07-20 Thread Vincent Siveton (JIRA)
Add default Javadoc link depending the values of maven-compiler-plugin 
configuration


 Key: MJAVADOC-240
 URL: http://jira.codehaus.org/browse/MJAVADOC-240
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Improvement
Affects Versions: 2.5
Reporter: Vincent Siveton




-- 
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