[jira] Created: (MASSEMBLY-519) Documentation problem: description of how to share assemble descriptors is wrong

2010-10-28 Thread Thomas Arand (JIRA)
Documentation problem: description of how to share assemble descriptors is wrong


 Key: MASSEMBLY-519
 URL: http://jira.codehaus.org/browse/MASSEMBLY-519
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Thomas Arand


The page 
http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html
 describes the way to access the shared descriptor like follows:

configuration
  !-- This is where we use our shared assembly descriptor --
  descriptors
descriptormyassembly.xml/descriptor
  /descriptors
/configuration

Due to the layout of the shared assembly descriptor project (myassembly.xml is 
stored in src/main/resources/assemblies/) this is wrong. It must be 
configuration
  !-- This is where we use our shared assembly descriptor --
  descriptors
descriptorassemblies/myassembly.xml/descriptor
  /descriptors
/configuration

-- 
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: (MECLIPSE-449) Facet Generation generates duplicate entries - breaks RAD/RSA support

2010-10-28 Thread Nicolas Ternisien (JIRA)

[ 
http://jira.codehaus.org/browse/MECLIPSE-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=241277#action_241277
 ] 

Nicolas Ternisien commented on MECLIPSE-449:


Bug reproduced here.

 Facet Generation generates duplicate entries - breaks RAD/RSA support
 -

 Key: MECLIPSE-449
 URL: http://jira.codehaus.org/browse/MECLIPSE-449
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
  Components: WTP support
Affects Versions: 2.5.1
 Environment: WinXP, IBM RSA V7.0.0.6 (Eclipse 3.2.2)
Reporter: Chris Graham
 Fix For: 2.9

 Attachments: MECLIPSE-449.patch, sample-error.zip, sample-noerror.zip


 Using V2.5.1 of the maven-eclipse-plugin, I have some issues in getting the 
 generated artifacts being correct.
 Take this section of the POM:
 additionalProjectFacets
 jst.java5.0/jst.java
 jst.ejb2.1/jst.ejb
 com.ibm.websphere.extended.ejb6.1/com.ibm.websphere.extended.ejb
 /additionalProjectFacets
 Generates this:
 faceted-project
   fixed facet=jst.java/
   fixed facet=jst.utility/
   installed facet=jst.utility version=1.0/
   installed facet=jst.java version=5.0/
   installed facet=com.ibm.websphere.extended.ejb version=6.1/
   installed facet=jst.ejb version=2.1/
   installed facet=jst.java version=5.0/
 /faceted-project
 You'll see that the jst.java facet is in there twice.
 Removing the facet from the list:
 additionalProjectFacets
 jst.ejb2.1/jst.ejb
 com.ibm.websphere.extended.ejb6.1/com.ibm.websphere.extended.ejb
 /additionalProjectFacets
 Generates this:
 faceted-project
   fixed facet=jst.java/
   fixed facet=jst.utility/
   installed facet=jst.utility version=1.0/
   installed facet=jst.java version=5.0/
   installed facet=com.ibm.websphere.extended.ejb version=6.1/
   installed facet=jst.ejb version=2.1/
 /faceted-project
 Which is a little more correct.
 I consider this a bug, as the facets (by their very definition) are unique 
 and should not be repeated.
 Additionally, when compared to a RSA (V7) generated one, it is missing the 
 standard XML header:
 ?xml version=1.0 encoding=UTF-8?
 Also, where does the jst.utility facet come from?
 It's inclusion is getting in the way of RSA recognising it as a true J2EE 
 component project (the EJB Deployment descriptor tree element does not 
 display in the Project Explorer view in the J2EE Perspective).
 This is the complete RSA generated one, for reference:
 ?xml version=1.0 encoding=UTF-8?
 faceted-project
   runtime name=WebSphere Application Server v6.1/
   fixed facet=jst.ejb/
   fixed facet=jst.java/
   installed facet=jst.ejb version=2.1/
   installed facet=jst.java version=5.0/
   installed facet=com.ibm.websphere.extended.ejb version=6.1/
 /faceted-project
 (Which raises another question, how do we specify the runtime items and if 
 something is fixed or not?)
 However, to get it to be correctly recognised, all we need is this:
 faceted-project
   fixed facet=jst.java/
   installed facet=jst.java version=5.0/
   installed facet=jst.ejb version=2.1/
   installed facet=com.ibm.websphere.extended.ejb version=6.1/
 /faceted-project

-- 
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-316) Incompatible with Maven 3

2010-10-28 Thread Xin Zoo (JIRA)
Incompatible with Maven 3
-

 Key: WAGON-316
 URL: http://jira.codehaus.org/browse/WAGON-316
 Project: Maven Wagon
  Issue Type: Bug
  Components: wagon-ssh-external
Affects Versions: 1.0-beta-6
 Environment: Windows 7 64 Bit, Java 1.6.0.22 64 Bit, Maven 3.0
Reporter: Xin Zoo


Wagon-ssh-external does not evaluate my settings.xml or at least not properly. 
With Maven 2.2.1 everything works fine, but with Maven 3.0 i get an error:
Command  scp is spelled wrong or could not be found.
(I had to translate this message).

My settings.xml looks like this (abbreviated):

settings
  servers
server
  idinhouse-deploy/id
  usernamedavid/username
  privateKeyc:\Users\xinzoo\.ssh\id_rsa.ppk/privateKey
  configuration
sshExecutablec:/Program Files (x86)/PuTTY/plink.exe/sshExecutable
scpExecutablec:/Program Files (x86)/PuTTY/pscp.exe/scpExecutable
  /configuration
/server
  /servers
/settings


-- 
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: (MPIR-205) Add the license information for each dependency

2010-10-28 Thread Vincent Siveton (JIRA)

[ 
http://jira.codehaus.org/browse/MPIR-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=241287#action_241287
 ] 

Vincent Siveton commented on MPIR-205:
--

Also added similar stuffs for the dependency-management report in r1028260, 
snapshot deployed

 Add the license information for each dependency
 ---

 Key: MPIR-205
 URL: http://jira.codehaus.org/browse/MPIR-205
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: New Feature
Affects Versions: 2.1
Reporter: Matthew Smith
Assignee: Vincent Siveton
 Fix For: 2.3

 Attachments: patch


 The current Dependency report includes tables for the dependencies that 
 include GroupId,ArtifactId, Version, Classifier,Type.  This patch will 
 include a License column to the tables.  The License will also be a link 
 making it easier to relate licenses to atrifacts.  The License section of the 
 document is affected.

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




Maven Tomcat and Axis 1.5.1 problem

2010-10-28 Thread srd.pl

Hello,

I am trying to deploy a webservice on tomcat that implements some axis
wsdl2java work. However when I try to launch the code it gives an error in
the line when I create an instance of auto-generated ServiceStub. The funny
thing is that I am using Maven for building the project. And when maven
compiles it it runs a TEST. During the test a tomcat server is launched and
the project is deployed. And everything works doing fine there - no errors,
the application connects correctly to another server, sending an attachment
and getting the proper response - no problem. However when I take the var
file and deploy it on a 'normal' tomcat I have the error:

org.apache.axis2.deployment.DeploymentException:
org.apache.axis2.transport.local.LocalTransportSender
 at
org.apache.axis2.deployment.AxisConfigBuilder.processTransportSenders(AxisConfigBuilder.java:694)
 at
org.apache.axis2.deployment.AxisConfigBuilder.populateConfig(AxisConfigBuilder.java:121)
 at
org.apache.axis2.deployment.DeploymentEngine.populateAxisConfiguration(DeploymentEngine.java:703)
 at
org.apache.axis2.deployment.FileSystemConfigurator.getAxisConfiguration(FileSystemConfigurator.java:116)
 at
org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:64)
 at
org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContextFromFileSystem(ConfigurationContextFactory.java:206)
 at
org.apache.axis2.client.ServiceClient.configureServiceClient(ServiceClient.java:150)
 at org.apache.axis2.client.ServiceClient.init(ServiceClient.java:143)
 at
com.mywebpack.rest.gencode.MywebappServiceStub.init(MywebappServiceStub.java:211)
 at
com.mywebpack.rest.gencode.MywebappServiceStub.init(MywebappServiceStub.java:197)
 at com.mywebpack.rest.resources.MywebappImpl.init(MywebappImpl.java:86)
 at
com.mywebpack.rest.resources.SearchResource.receiveWavestream(SearchResource.java:163)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at
com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:165)
 at
com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:67)
 at
com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:276)
 at
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:133)
 at
com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:83)
 at
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:133)
 at
com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:71)
 at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1171)
 at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1103)
 at
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1053)
 at
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1043)
 at
com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:406)
 at
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:477)
 at
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:662)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
 at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
 at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
 at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
 at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
 at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
 at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:873)
 at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
 at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
 at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
 at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
 at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException:

[jira] Closed: (MPIR-204) License report should not try to include pdf content as plain text

2010-10-28 Thread Vincent Siveton (JIRA)

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

Vincent Siveton closed MPIR-204.


   Resolution: Fixed
Fix Version/s: 2.3
 Assignee: Vincent Siveton

Patch applied in r1028267 with this change: linkOnly param is always true in 
offline mode

 License report should not try to include pdf content as plain text
 --

 Key: MPIR-204
 URL: http://jira.codehaus.org/browse/MPIR-204
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
  Components: license
Affects Versions: 2.2
Reporter: Grégory Joseph
Assignee: Vincent Siveton
 Fix For: 2.3

 Attachments: MPIR-204.patch


 The LicenseReport class has a relevant TODO: {{we should check for a 
 text/html mime type instead, and possibly use a html parser to do this a bit 
 more cleanly/reliably.}}. That, and/or there could be a configuration item so 
 that one could configure the report to simply render links to the license 
 documents rather than attempt to include them verbatim in the generated html.

-- 
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: (MPIR-204) License report should not try to include pdf content as plain text

2010-10-28 Thread JIRA

[ 
http://jira.codehaus.org/browse/MPIR-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=241290#action_241290
 ] 

Grégory Joseph commented on MPIR-204:
-

great, thanks!
Any plans for the next release ?

 License report should not try to include pdf content as plain text
 --

 Key: MPIR-204
 URL: http://jira.codehaus.org/browse/MPIR-204
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
  Components: license
Affects Versions: 2.2
Reporter: Grégory Joseph
Assignee: Vincent Siveton
 Fix For: 2.3

 Attachments: MPIR-204.patch


 The LicenseReport class has a relevant TODO: {{we should check for a 
 text/html mime type instead, and possibly use a html parser to do this a bit 
 more cleanly/reliably.}}. That, and/or there could be a configuration item so 
 that one could configure the report to simply render links to the license 
 documents rather than attempt to include them verbatim in the generated html.

-- 
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: (MSITE-519) overwrite inherited menu item or add addition item to inherited menu

2010-10-28 Thread Thomas Wabner (JIRA)
overwrite inherited menu item or add addition item to inherited menu


 Key: MSITE-519
 URL: http://jira.codehaus.org/browse/MSITE-519
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: inheritance
Affects Versions: 3.0-beta-3
 Environment: maven 3.0
Reporter: Thomas Wabner


I have a parent project with a site descriptor where I have defined a menu like 
this:

...
menu name=Overview inherit=top
   item name=Introduction href=/index.html /
/menu
...

Now I have a child project which should overwrite OR add addition item(s) to 
the inherited site descriptor like this:

...
menu name=Overview
  item name=Introduction href=/index.html /
  item name=Deployment instruction href=/deploy.html /
/menu
...

The current behavior is that the Overview menu is rendered twice in the 
resulting site.

But I expect that the additional menu item will be mixed into the Overview 
menu.

-- 
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: (MPIR-204) License report should not try to include pdf content as plain text

2010-10-28 Thread Vincent Siveton (JIRA)

[ 
http://jira.codehaus.org/browse/MPIR-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=241291#action_241291
 ] 

Vincent Siveton commented on MPIR-204:
--

soon probably in November or for Xmas

 License report should not try to include pdf content as plain text
 --

 Key: MPIR-204
 URL: http://jira.codehaus.org/browse/MPIR-204
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
  Components: license
Affects Versions: 2.2
Reporter: Grégory Joseph
Assignee: Vincent Siveton
 Fix For: 2.3

 Attachments: MPIR-204.patch


 The LicenseReport class has a relevant TODO: {{we should check for a 
 text/html mime type instead, and possibly use a html parser to do this a bit 
 more cleanly/reliably.}}. That, and/or there could be a configuration item so 
 that one could configure the report to simply render links to the license 
 documents rather than attempt to include them verbatim in the generated html.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (MAVENUPLOAD-2806) Upload jsch-0.1.43 to Central

2010-10-28 Thread Martin Todorov (JIRA)
Upload jsch-0.1.43 to Central
-

 Key: MAVENUPLOAD-2806
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2806
 Project: Maven Upload Requests
  Issue Type: Task
Reporter: Martin Todorov
 Attachments: jsch-0.1.43.jar, jsch-0.1.43.pom



Hi,

A newer version of jsch already exists. It would be very much appreciated, if 
you could upload it to Maven Central.
This library is used by many projects and Maven plugins. Our current workaround 
is to upload the jar manually to our own Nexus, but I am sure that a lot of 
other people would benefit from the newer version in Central as well.

I am attaching both the artifact and a pom file for it.

Thanks in advance,
Regards,

Martin Todorov




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MSITE-519) overwrite inherited menu item or add addition item to inherited menu

2010-10-28 Thread Sebastian Paul (JIRA)

[ 
http://jira.codehaus.org/browse/MSITE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=241292#action_241292
 ] 

Sebastian Paul commented on MSITE-519:
--

Hi, this behavior has been introduced with maven-site-plugin version 2.1 for 
fixing MSITE-293. For a work-around we have been stuck with version 2.0.1. 
Unfortunately, this now holds us back from migrating to Maven 3, as the old 
plugin version is not compatible.

 overwrite inherited menu item or add addition item to inherited menu
 

 Key: MSITE-519
 URL: http://jira.codehaus.org/browse/MSITE-519
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: inheritance
Affects Versions: 3.0-beta-3
 Environment: maven 3.0
Reporter: Thomas Wabner

 I have a parent project with a site descriptor where I have defined a menu 
 like this:
 ...
 menu name=Overview inherit=top
item name=Introduction href=/index.html /
 /menu
 ...
 Now I have a child project which should overwrite OR add addition item(s) 
 to the inherited site descriptor like this:
 ...
 menu name=Overview
   item name=Introduction href=/index.html /
   item name=Deployment instruction href=/deploy.html /
 /menu
 ...
 The current behavior is that the Overview menu is rendered twice in the 
 resulting site.
 But I expect that the additional menu item will be mixed into the Overview 
 menu.

-- 
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: (MPIR-204) License report should not try to include pdf content as plain text

2010-10-28 Thread JIRA

[ 
http://jira.codehaus.org/browse/MPIR-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=241293#action_241293
 ] 

Grégory Joseph commented on MPIR-204:
-

ok thanks!

 License report should not try to include pdf content as plain text
 --

 Key: MPIR-204
 URL: http://jira.codehaus.org/browse/MPIR-204
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
  Components: license
Affects Versions: 2.2
Reporter: Grégory Joseph
Assignee: Vincent Siveton
 Fix For: 2.3

 Attachments: MPIR-204.patch


 The LicenseReport class has a relevant TODO: {{we should check for a 
 text/html mime type instead, and possibly use a html parser to do this a bit 
 more cleanly/reliably.}}. That, and/or there could be a configuration item so 
 that one could configure the report to simply render links to the license 
 documents rather than attempt to include them verbatim in the generated html.

-- 
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: (MPIR-206) Improve configuration of mailing list header text.

2010-10-28 Thread Olivier Lamy (JIRA)
Improve configuration of mailing list header text.
--

 Key: MPIR-206
 URL: http://jira.codehaus.org/browse/MPIR-206
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
  Components: mailing-list
Reporter: Olivier Lamy
Assignee: Olivier Lamy
 Fix For: 2.2


The generated mailing list report has a header which provides basic info on the 
page.

However, in some cases this information is not enough.
For example, some lists may not allow posting; it would be useful to be able to 
explain why.
In the case of Apache Commons, the lists are shared, so users need to add a 
prefix to the subject line.
There are no doubt other use cases.

It would be useful to be able to override the introduction.

-- 
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: (MPIR-206) Improve configuration of mailing list header text.

2010-10-28 Thread Olivier Lamy (JIRA)

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

Olivier Lamy updated MPIR-206:
--

Description: 
The generated mailing list report has a header which provides basic info on the 
page.

However, in some cases this information is not enough.
For example, some lists may not allow posting; it would be useful to be able to 
explain why.
In the case of Apache Commons, the lists are shared, so users need to add a 
prefix to the subject line.
There are no doubt other use cases.

It would be useful to be able to override the introduction.


  was:
The generated mailing list report has a header which provides basic info on the 
page.

However, in some cases this information is not enough.
For example, some lists may not allow posting; it would be useful to be able to 
explain why.
In the case of Apache Commons, the lists are shared, so users need to add a 
prefix to the subject line.
There are no doubt other use cases.

It would be useful to be able to override the introduction.



The current implementation is too much simple.
We must probably improve this with loading some bundles

 Improve configuration of mailing list header text.
 --

 Key: MPIR-206
 URL: http://jira.codehaus.org/browse/MPIR-206
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
  Components: mailing-list
Reporter: Olivier Lamy
Assignee: Olivier Lamy
 Fix For: 2.2


 The generated mailing list report has a header which provides basic info on 
 the page.
 However, in some cases this information is not enough.
 For example, some lists may not allow posting; it would be useful to be able 
 to explain why.
 In the case of Apache Commons, the lists are shared, so users need to add a 
 prefix to the subject line.
 There are no doubt other use cases.
 It would be useful to be able to override the introduction.

-- 
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: (MPIR-206) Improve configuration of mailing list header text.

2010-10-28 Thread Olivier Lamy (JIRA)

[ 
http://jira.codehaus.org/browse/MPIR-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=241295#action_241295
 ] 

Olivier Lamy edited comment on MPIR-206 at 10/28/10 7:46 AM:
-

The current implementation MPIR-189 is too much simple.
We must probably improve this with loading some bundles

  was (Author: olamy):

The current implementation is too much simple.
We must probably improve this with loading some bundles
  
 Improve configuration of mailing list header text.
 --

 Key: MPIR-206
 URL: http://jira.codehaus.org/browse/MPIR-206
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
  Components: mailing-list
Reporter: Olivier Lamy
Assignee: Olivier Lamy
 Fix For: 2.2


 The generated mailing list report has a header which provides basic info on 
 the page.
 However, in some cases this information is not enough.
 For example, some lists may not allow posting; it would be useful to be able 
 to explain why.
 In the case of Apache Commons, the lists are shared, so users need to add a 
 prefix to the subject line.
 There are no doubt other use cases.
 It would be useful to be able to override the introduction.

-- 
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: (MPIR-206) Improve configuration of mailing list header text.

2010-10-28 Thread Olivier Lamy (JIRA)

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

Olivier Lamy updated MPIR-206:
--

Assignee: (was: Olivier Lamy)

 Improve configuration of mailing list header text.
 --

 Key: MPIR-206
 URL: http://jira.codehaus.org/browse/MPIR-206
 Project: Maven 2.x Project Info Reports Plugin
  Issue Type: Improvement
  Components: mailing-list
Reporter: Olivier Lamy
 Fix For: 2.2


 The generated mailing list report has a header which provides basic info on 
 the page.
 However, in some cases this information is not enough.
 For example, some lists may not allow posting; it would be useful to be able 
 to explain why.
 In the case of Apache Commons, the lists are shared, so users need to add a 
 prefix to the subject line.
 There are no doubt other use cases.
 It would be useful to be able to override the introduction.

-- 
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: (MSITE-519) overwrite inherited menu item or add addition item to inherited menu

2010-10-28 Thread Sebastian Paul (JIRA)

[ 
http://jira.codehaus.org/browse/MSITE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=241292#action_241292
 ] 

Sebastian Paul edited comment on MSITE-519 at 10/28/10 8:02 AM:


Hi, the current behavior has been introduced with maven-site-plugin version 2.1 
for fixing MSITE-293, where the inheritance concept is not usable for us. One 
can choose whether a menu is always inherited (with no way of overriding in 
children) or not inherited at all. This choice is made in the parent project. 
Child projects don't have a control at all.

In versions until 2.0.1, menus (without the inherit attribute) have been 
inherited from the parent unless a site.xml is present. When a project needed 
to add a link to a menu, a site.xml had to be added, and all menus had to be 
redefined. We never made use of the inherit attribute, for the reasons 
explained in the description.
For a working around this issue, we have been stuck with version 2.0.1. 
Unfortunately, this now holds us back from migrating to Maven 3, as the old 
plugin version is not compatible.

There should really be a way of overriding inherited menus, so that they can be 
extended (or even replaced or removed). For this, child projects have to 
control the inheritence.

  was (Author: sebpaul):
Hi, this behavior has been introduced with maven-site-plugin version 2.1 
for fixing MSITE-293. For a work-around we have been stuck with version 2.0.1. 
Unfortunately, this now holds us back from migrating to Maven 3, as the old 
plugin version is not compatible.
  
 overwrite inherited menu item or add addition item to inherited menu
 

 Key: MSITE-519
 URL: http://jira.codehaus.org/browse/MSITE-519
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: inheritance
Affects Versions: 3.0-beta-3
 Environment: maven 3.0
Reporter: Thomas Wabner

 I have a parent project with a site descriptor where I have defined a menu 
 like this:
 ...
 menu name=Overview inherit=top
item name=Introduction href=/index.html /
 /menu
 ...
 Now I have a child project which should overwrite OR add addition item(s) 
 to the inherited site descriptor like this:
 ...
 menu name=Overview
   item name=Introduction href=/index.html /
   item name=Deployment instruction href=/deploy.html /
 /menu
 ...
 The current behavior is that the Overview menu is rendered twice in the 
 resulting site.
 But I expect that the additional menu item will be mixed into the Overview 
 menu.

-- 
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: (MCHECKSTYLE-148) Would be nice to see the name of CHECK together with its output

2010-10-28 Thread Vincenzo Mancini (JIRA)
Would be nice to see the name of CHECK together with its output
---

 Key: MCHECKSTYLE-148
 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-148
 Project: Maven 2.x Checkstyle Plugin
  Issue Type: Improvement
 Environment: maven-3
Reporter: Vincenzo Mancini


This is what I see in my report (for example):

{noformat}
[...]
[ERROR] Abc.java[77:5] Class should define a constructor.
[ERROR] Abc.java[88:5] Class should define a constructor.
[ERROR] Abc.java[99:8] Unused @param tag for 's'.
[...]
{noformat}

It's difficult to understand which particular checkstyle check produced these 
lines. Would be nice to have a configuration option in the plugin, which will 
let me turn such extra logging ON and OFF, and I would see something like this:

{noformat}
[...]
[ERROR] Abc.java[77:5] Class should define a constructor. 
(com.puppycrawl.tools.checkstyle.checks...)
[ERROR] Abc.java[88:5] Class should define a constructor. 
(com.puppycrawl.tools.checkstyle.checks...)
[ERROR] Abc.java[99:8] Unused @param tag for 's'. 
(com.puppycrawl.tools.checkstyle.checks...)
[...]
{noformat}

This logging will help me to find (!) and re-configure my checks very fast.

-- 
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: (MASSEMBLY-520) Classpath is setup incorrectly if assembly-plugin is used several times on the same reactor

2010-10-28 Thread Thomas Arand (JIRA)
Classpath is setup incorrectly if assembly-plugin is used several times on the 
same reactor
---

 Key: MASSEMBLY-520
 URL: http://jira.codehaus.org/browse/MASSEMBLY-520
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-5
Reporter: Thomas Arand
Priority: Critical


I have some projects (which use the maven-assembly-plugin) sharing the same 
assembly-descriptor. Thus I setup my projects as described in 
http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html.
 In principle that works fine.

Unfortunately when invoking maven on a higher directory level (that means 
putting more projects in the same reactor) I got Classpath related 
assembly-descriptor-not-found problems in my new projects. This problem occurs 
whenever at least one of the other projects also use the maven-assembly-plugin. 
These other projects typically do not have the dependency specification for the 
shard-assembly-descriptor project. Obviously in that case the 
shared-assembly-descriptor jar is not put on the CLASSPATH when the plugin is 
invoked for my new projects.

Note that there is a workaround: When adding the dependency to the 
shared-assembly-descriptor project to all other projects using the 
maven-assembly-plugin, everything compiles perfectly. However, this workaround 
is a bad one.

-- 
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: (MASSEMBLY-519) Documentation problem: description of how to share assemble descriptors is wrong

2010-10-28 Thread Thomas Arand (JIRA)

[ 
http://jira.codehaus.org/browse/MASSEMBLY-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=241303#action_241303
 ] 

Thomas Arand commented on MASSEMBLY-519:


The situation is worse. The description is correct, but a CLASSPATH issue 
exists. I created a new Jira MASSEMBLY-520 for that. MASSEMBLY-519 (this one) 
can be closed.

 Documentation problem: description of how to share assemble descriptors is 
 wrong
 

 Key: MASSEMBLY-519
 URL: http://jira.codehaus.org/browse/MASSEMBLY-519
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Thomas Arand

 The page 
 http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html
  describes the way to access the shared descriptor like follows:
 configuration
   !-- This is where we use our shared assembly descriptor --
   descriptors
 descriptormyassembly.xml/descriptor
   /descriptors
 /configuration
 Due to the layout of the shared assembly descriptor project (myassembly.xml 
 is stored in src/main/resources/assemblies/) this is wrong. It must be 
 configuration
   !-- This is where we use our shared assembly descriptor --
   descriptors
 descriptorassemblies/myassembly.xml/descriptor
   /descriptors
 /configuration

-- 
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-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally

2010-10-28 Thread Martin Todorov (JIRA)

[ 
http://jira.codehaus.org/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=241305#action_241305
 ] 

Martin Todorov commented on MNG-4142:
-



Bonjour Arnaud!

As per your request, I have tested this with Maven 3.0 today. I am afraid the 
problem still persists. Today this actually happened with a completely 
different project/setup/machine under both Maven 2.2.1 and 3.0.

This is not just annoying, it's actually a show-stopper when it happens to a 
developer who's not expecting it, as they spend quite some time trying to 
figure it out.

Please review for the release of Maven 3.1, (if a 2.x version will not be 
further released).

Regards,

Martin




 Maven doesn't try to download a dependency when it already exists a version 
 with classifier locally
 ---

 Key: MNG-4142
 URL: http://jira.codehaus.org/browse/MNG-4142
 Project: Maven 2  3
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 2.0.9, 2.0.10, 2.1.0
 Environment: Java 5, Windows XP
Reporter: Arnaud Heritier
Priority: Critical
 Fix For: Issues to be reviewed for 3.x

 Attachments: MNG-4142.patch, test-metadata-local-clover.zip


 When maven installs in the local repository an artifact with a classifier, 
 and not the principal artifact, it won't try in a reactor to download the 
 principal artifact from the remote repository.
 I created a testcase to reproduce it. It's quite simple. You unzip it and in 
 the root directory you launch {code}mvn site{code}
 This build uses clover, thus it installs locally cloverified versions of 
 artifacts.
 The build will fail because it doesn't find the SNAPSHOT of the module1 :
 {code}
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Failed to resolve artifact.
 Missing:
 --
 1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
   Try downloading the file manually from the project website.
   Then, install it using the command:
   mvn install:install-file 
 -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1 
 -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
 th/to/file
   Alternatively, if you host your own repository you can deploy the file 
 there:
   mvn deploy:deploy-file 
 -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1 
 -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
 /to/file -Durl=[url] -DrepositoryId=[id]
   Path to dependency:
 1) 
 org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
 2) 
 org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
 --
 1 required artifact is missing.
 for artifact:
   org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
 from the specified remote repositories:
   central (http://maven-proxy.groupe.generali.fr/all),
   remote-repo 
 (file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
 {code}
 It's anormal because I set a local remote repository in the build where it 
 should try to download it.
 You can validate that it is working by launching :
 {code}mvn install -f module2/pom.xml{code}
 This bug is really annoying for us. It exists for a long long time now. I 
 thought it was due to a problem with metadata sent by archiva, but after 
 migrating to nexus the problem always occurs. 
 I don't know if the problem is in metadata or in the reactor itself. I think 
 it is the second one. There are many issues opened about the reactor and 
 classifiers.
 Is there some who can try if it can reproduce the error with my testcase ?
 It should be easy to create a real IT for maven with it if it is necessary.

-- 
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-300) URL changed after Oracle's acquisition of Sun

2010-10-28 Thread Juergen Zimmermann (JIRA)
URL changed after Oracle's acquisition of Sun
-

 Key: MJAVADOC-300
 URL: http://jira.codehaus.org/browse/MJAVADOC-300
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Juergen Zimmermann


The javadoc plugin uses http://java.sun.com/javase/6/docs/api/package-list. But 
this URL has to be changed to 
http://download.oracle.com/javase/6/docs/api/package-list

-- 
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: (ARCHETYPE-340) New Project from Archetype causes STS to crash

2010-10-28 Thread Gordon Dickens (JIRA)
New Project from Archetype causes STS to crash 
---

 Key: ARCHETYPE-340
 URL: http://jira.codehaus.org/browse/ARCHETYPE-340
 Project: Maven Archetype
  Issue Type: Bug
  Components: Archetypes
Affects Versions: 2.0
 Environment: Mac OSX
Reporter: Gordon Dickens


See: https://jira.springsource.org/browse/IDE-1146

-- 
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: (WAGON-316) Incompatible with Maven 3

2010-10-28 Thread Brett Porter (JIRA)

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

Brett Porter closed WAGON-316.
--

Resolution: Duplicate
  Assignee: Brett Porter

 Incompatible with Maven 3
 -

 Key: WAGON-316
 URL: http://jira.codehaus.org/browse/WAGON-316
 Project: Maven Wagon
  Issue Type: Bug
  Components: wagon-ssh-external
Affects Versions: 1.0-beta-6
 Environment: Windows 7 64 Bit, Java 1.6.0.22 64 Bit, Maven 3.0
Reporter: Xin Zoo
Assignee: Brett Porter

 Wagon-ssh-external does not evaluate my settings.xml or at least not 
 properly. With Maven 2.2.1 everything works fine, but with Maven 3.0 i get an 
 error:
 Command  scp is spelled wrong or could not be found.
 (I had to translate this message).
 My settings.xml looks like this (abbreviated):
 settings
   servers
 server
   idinhouse-deploy/id
   usernamedavid/username
   privateKeyc:\Users\xinzoo\.ssh\id_rsa.ppk/privateKey
   configuration
 sshExecutablec:/Program Files (x86)/PuTTY/plink.exe/sshExecutable
 scpExecutablec:/Program Files (x86)/PuTTY/pscp.exe/scpExecutable
   /configuration
 /server
   /servers
 /settings

-- 
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: (MJAR-139) New option to avoid empty jar creation

2010-10-28 Thread Vlad Skarzhevskyy (JIRA)

[ 
http://jira.codehaus.org/browse/MJAR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=241332#action_241332
 ] 

Vlad Skarzhevskyy commented on MJAR-139:


There are 'skip' Parameter for jar:test-jar goal. Would be nice to have the 
same for jar:jar goal. And not create main jar at all.
Obviously pom packagingtest-jar/packaging would make more sense.

My usage example is a creation of common tests modules. 
The tests are executed in different poms configured with different database 
bindings.

 New option to avoid empty jar creation
 --

 Key: MJAR-139
 URL: http://jira.codehaus.org/browse/MJAR-139
 Project: Maven 2.x Jar Plugin
  Issue Type: Improvement
Affects Versions: 2.3.1
Reporter: Roman Ivanov

 Usage of test-jar is beneficial for all project, as all of them have tests.
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-jar-plugin/artifactId
   version2.3.1/version
   executions
   execution
   goals
   goaltest-jar/goal
   /goals
   /execution
   /executions
 /plugin
 Pom artifacts and some jar artifacts does not have test and will never have 
 them.
 In logs we have: [WARNING] JAR will be empty - no content was marked for 
 inclusion!
 and empty and useless artifacts are created, deployed , ...
 It will be convenient to have an plugin option to define whether skip empty 
 jar creation and warning or generate jar with warning in log. Does it make 
 sense ?
 By default option will be FALSE, to comply with previous behavior.

-- 
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: (MSTAGE-9) Stage plugin fails with ClassCastException

2010-10-28 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MSTAGE-9.


   Resolution: Fixed
Fix Version/s: 1.0
 Assignee: Dennis Lundberg

Fixed in 
[r1028469|http://svn.apache.org/viewvc?view=revisionrevision=1028469], by 
updating the prerequisite Maven version to 2.0.10.

 Stage plugin fails with ClassCastException
 --

 Key: MSTAGE-9
 URL: http://jira.codehaus.org/browse/MSTAGE-9
 Project: Maven 2.x Stage Plugin
  Issue Type: Bug
Affects Versions: 1.0-alpha-1
Reporter: Benson Margulies
Assignee: Dennis Lundberg
 Fix For: 1.0


 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] org.apache.maven.wagon.providers.ssh.jsch.ScpWagon
 [INFO] 
 
 [INFO] Trace
 java.lang.ClassCastException: 
 org.apache.maven.wagon.providers.ssh.jsch.ScpWagon
   at 
 org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepositoryCopier.java:252)
   at 
 org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepositoryMojo.java:93)
   at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:227)
   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:287)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   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)
 [INFO] 
 
 [INFO] Total time: 49 seconds
 [INFO] Finished at: Wed Dec 10 22:13:24 EST 2008
 [INFO] Final Memory: 3M/6M
 [INFO] 
 
 /Users/benson/xmlschema 
 mvn stage:copy \
-Dsource=http://people.apache.org/~bimargulies/maven_staging; \

 -Dtarget=scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository
  \
-Dversion=1.4.3 \
-DtargetRepositoryId=apache.releases
   servers
 server
   idapache-repo/id
   usernamebimargulies/username
 /server
 server
   idapache.releases/id
   usernamebimargulies/username
 /server
 server
   idapache-snapshots/id
   usernamebimargulies/username
 /server
   /servers

-- 
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: (MSTAGE-7) Unable to use archiva as http source with maven-stage-plugin

2010-10-28 Thread Dennis Lundberg (JIRA)

[ 
http://jira.codehaus.org/browse/MSTAGE-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=241342#action_241342
 ] 

Dennis Lundberg commented on MSTAGE-7:
--

Dan, I've read the comments in your patch. If I understand them correctly, now 
that the bugs in Archiva have been solved, we only need to update the Wagon 
dependencies in the Stage Plugin to version 1.0-beta-3 to solve this issue.

 Unable to use archiva as http source with maven-stage-plugin
 

 Key: MSTAGE-7
 URL: http://jira.codehaus.org/browse/MSTAGE-7
 Project: Maven 2.x Stage Plugin
  Issue Type: Bug
Affects Versions: 1.0-alpha-1
Reporter: Dan Tran
 Attachments: MSTAGE-7.patch


 http-wagon-beta-2 currently not able to parse the archiva page ( 
 http://jira.codehaus.org/browse/MRM-891 ).
 however with the fix from http://jira.codehaus.org/browse/MRM-893 and upgrade 
 to wagon-beta-3 will solve the problem
 without change in stage plugin source code.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (SUREFIRE-655) massive grief by DefaultPlexusContainer lookup which incorrectly parsed the roleHint

2010-10-28 Thread Martin Gainty (JIRA)
massive grief by DefaultPlexusContainer lookup which incorrectly parsed the 
roleHint


 Key: SUREFIRE-655
 URL: http://jira.codehaus.org/browse/SUREFIRE-655
 Project: Maven Surefire
  Issue Type: Bug
Affects Versions: 2.5
 Environment: mvn -version
Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.6.0_16
Java home: C:\Java\jdk\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Martin Gainty


originally i was using 2.5 version of maven-surefire-plugin as seen here

groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.5/version

this caused massive grief by DefaultPlexusContainer lookup which incorrectly 
parsed the roleHint

so i backed all my dependencies of maven-surefire-plugin down to v 2.4.2 to rid 
myself of the guice injector anomaly here is the debug error listing:
note that the org.codehaus.plexus.DefaultPlexusContainer roleHint is 
incorrectly assigned  org.apache.maven.plugins:maven-surefire-plugin:2.5:test 

it should be
org.apache.maven.plugins:maven-surefire-plugin:2.5

for the lookup to work


[ERROR] 1 error
[ERROR] role: org.apache.maven.plugin.Mojo
[ERROR] roleHint: org.apache.maven.plugins:maven-surefire-plugin:2.5:test: 
Guice provision errors:
[ERROR] 
[ERROR] 1) No implementation for 
org.apache.maven.artifact.resolver.ArtifactResolver was bound.
[ERROR] while locating org.apache.maven.plugin.surefire.SurefirePlugin
[ERROR] 
[ERROR] 1 error
[ERROR] - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.5:test (default-test) on 
project maven-checkstyle-plugin: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.5:test failed: Unable to load 
the mojo 'test' (or one of its required components) from the plugin 
'org.apache.maven.plugins:maven-surefire-plugin:2.5'
 at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:211)
 at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
 at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
 at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
 at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
 at 
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
 at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:314)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151)
 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445)
 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:132)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
 at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.5:test 
failed: Unable to load the mojo 'test' (or one of its required components) from 
the plugin 'org.apache.maven.plugins:maven-surefire-plugin:2.5'
 at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121)
 at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
 ... 19 more
Caused by: org.apache.maven.plugin.PluginContainerException: Unable to load the 
mojo 'test' (or one of its required components) from the plugin 
'org.apache.maven.plugins:maven-surefire-plugin:2.5'
 at 
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:426)
 at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:96)
 ... 20 more
Caused by: 
org.codehaus.plexus.component.repository.exception.ComponentLookupException: 
com.google.inject.ProvisionException: Guice provision errors:

1) Error injecting: org.apache.maven.plugin.surefire.SurefirePlugin
  at 

[jira] Updated: (SUREFIRE-655) massive grief by DefaultPlexusContainer lookup which incorrectly parsed the roleHint

2010-10-28 Thread Benjamin Bentmann (JIRA)

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

Benjamin Bentmann updated SUREFIRE-655:
---

Attachment: SUREFIRE-655.zip

The Surefire ITs run fine using M3 and this small sample project inspired by 
your information also doesn't exhibit the issue.

 massive grief by DefaultPlexusContainer lookup which incorrectly parsed the 
 roleHint
 

 Key: SUREFIRE-655
 URL: http://jira.codehaus.org/browse/SUREFIRE-655
 Project: Maven Surefire
  Issue Type: Bug
Affects Versions: 2.5
 Environment: mvn -version
 Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
 Java version: 1.6.0_16
 Java home: C:\Java\jdk\jre
 Default locale: en_US, platform encoding: Cp1252
 OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Martin Gainty
 Attachments: SUREFIRE-655.zip


 originally i was using 2.5 version of maven-surefire-plugin as seen here
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-surefire-plugin/artifactId
 version2.5/version
 this caused massive grief by DefaultPlexusContainer lookup which incorrectly 
 parsed the roleHint
 so i backed all my dependencies of maven-surefire-plugin down to v 2.4.2 to 
 rid myself of the guice injector anomaly here is the debug error listing:
 note that the org.codehaus.plexus.DefaultPlexusContainer roleHint is 
 incorrectly assigned  org.apache.maven.plugins:maven-surefire-plugin:2.5:test 
 it should be  
   org.apache.maven.plugins:maven-surefire-plugin:2.5
 for the lookup to work
 [ERROR] 1 error
 [ERROR] role: org.apache.maven.plugin.Mojo
 [ERROR] roleHint: org.apache.maven.plugins:maven-surefire-plugin:2.5:test: 
 Guice provision errors:
 [ERROR] 
 [ERROR] 1) No implementation for 
 org.apache.maven.artifact.resolver.ArtifactResolver was bound.
 [ERROR] while locating org.apache.maven.plugin.surefire.SurefirePlugin
 [ERROR] 
 [ERROR] 1 error
 [ERROR] - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-surefire-plugin:2.5:test (default-test) 
 on project maven-checkstyle-plugin: Execution default-test of goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.5:test failed: Unable to 
 load the mojo 'test' (or one of its required components) from the plugin 
 'org.apache.maven.plugins:maven-surefire-plugin:2.5'
  at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:211)
  at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
  at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
  at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
  at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
  at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
  at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:314)
  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151)
  at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445)
  at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168)
  at org.apache.maven.cli.MavenCli.main(MavenCli.java:132)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  at java.lang.reflect.Method.invoke(Method.java:597)
  at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
  at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
  at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
  at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
 Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
 default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.5:test 
 failed: Unable to load the mojo 'test' (or one of its required components) 
 from the plugin 'org.apache.maven.plugins:maven-surefire-plugin:2.5'
  at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121)
  at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
  ... 19 more
 Caused by: org.apache.maven.plugin.PluginContainerException: Unable to load 
 the mojo 'test' (or one of its required components) from the plugin 
 'org.apache.maven.plugins:maven-surefire-plugin:2.5'
  at 
 

[jira] Closed: (SUREFIRE-655) massive grief by DefaultPlexusContainer lookup which incorrectly parsed the roleHint

2010-10-28 Thread Benjamin Bentmann (JIRA)

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

Benjamin Bentmann closed SUREFIRE-655.
--

Resolution: Cannot Reproduce
  Assignee: Benjamin Bentmann

Not reproducible from the information given, feel free to reopen with updated 
steps to reproduce the issue.

 massive grief by DefaultPlexusContainer lookup which incorrectly parsed the 
 roleHint
 

 Key: SUREFIRE-655
 URL: http://jira.codehaus.org/browse/SUREFIRE-655
 Project: Maven Surefire
  Issue Type: Bug
Affects Versions: 2.5
 Environment: mvn -version
 Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
 Java version: 1.6.0_16
 Java home: C:\Java\jdk\jre
 Default locale: en_US, platform encoding: Cp1252
 OS name: windows xp version: 5.1 arch: x86 Family: windows
Reporter: Martin Gainty
Assignee: Benjamin Bentmann
 Attachments: SUREFIRE-655.zip


 originally i was using 2.5 version of maven-surefire-plugin as seen here
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-surefire-plugin/artifactId
 version2.5/version
 this caused massive grief by DefaultPlexusContainer lookup which incorrectly 
 parsed the roleHint
 so i backed all my dependencies of maven-surefire-plugin down to v 2.4.2 to 
 rid myself of the guice injector anomaly here is the debug error listing:
 note that the org.codehaus.plexus.DefaultPlexusContainer roleHint is 
 incorrectly assigned  org.apache.maven.plugins:maven-surefire-plugin:2.5:test 
 it should be  
   org.apache.maven.plugins:maven-surefire-plugin:2.5
 for the lookup to work
 [ERROR] 1 error
 [ERROR] role: org.apache.maven.plugin.Mojo
 [ERROR] roleHint: org.apache.maven.plugins:maven-surefire-plugin:2.5:test: 
 Guice provision errors:
 [ERROR] 
 [ERROR] 1) No implementation for 
 org.apache.maven.artifact.resolver.ArtifactResolver was bound.
 [ERROR] while locating org.apache.maven.plugin.surefire.SurefirePlugin
 [ERROR] 
 [ERROR] 1 error
 [ERROR] - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-surefire-plugin:2.5:test (default-test) 
 on project maven-checkstyle-plugin: Execution default-test of goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.5:test failed: Unable to 
 load the mojo 'test' (or one of its required components) from the plugin 
 'org.apache.maven.plugins:maven-surefire-plugin:2.5'
  at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:211)
  at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
  at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
  at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
  at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
  at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
  at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:314)
  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151)
  at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445)
  at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168)
  at org.apache.maven.cli.MavenCli.main(MavenCli.java:132)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  at java.lang.reflect.Method.invoke(Method.java:597)
  at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
  at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
  at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
  at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
 Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
 default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.5:test 
 failed: Unable to load the mojo 'test' (or one of its required components) 
 from the plugin 'org.apache.maven.plugins:maven-surefire-plugin:2.5'
  at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121)
  at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
  ... 19 more
 Caused by: org.apache.maven.plugin.PluginContainerException: Unable to load 
 the mojo 'test' (or one of its required components) from the plugin 
 

[jira] Commented: (MSTAGE-7) Unable to use archiva as http source with maven-stage-plugin

2010-10-28 Thread Dan Tran (JIRA)

[ 
http://jira.codehaus.org/browse/MSTAGE-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=241384#action_241384
 ] 

Dan Tran commented on MSTAGE-7:
---

Yes. 

 Unable to use archiva as http source with maven-stage-plugin
 

 Key: MSTAGE-7
 URL: http://jira.codehaus.org/browse/MSTAGE-7
 Project: Maven 2.x Stage Plugin
  Issue Type: Bug
Affects Versions: 1.0-alpha-1
Reporter: Dan Tran
 Attachments: MSTAGE-7.patch


 http-wagon-beta-2 currently not able to parse the archiva page ( 
 http://jira.codehaus.org/browse/MRM-891 ).
 however with the fix from http://jira.codehaus.org/browse/MRM-893 and upgrade 
 to wagon-beta-3 will solve the problem
 without change in stage plugin source code.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (MSITE-520) Russian localization

2010-10-28 Thread Yevgeny Nyden (JIRA)
Russian localization


 Key: MSITE-520
 URL: http://jira.codehaus.org/browse/MSITE-520
 Project: Maven 2.x Site Plugin
  Issue Type: Improvement
  Components: internationalization
Affects Versions: 3.0-beta-2
Reporter: Yevgeny Nyden
 Attachments: project-info-report_ru.properties, 
site-plugin_ru.properties, site-tool_ru.properties

Attached are the Russian  localization resource files for the site, report, and 
tools plugins. 

To create localized versions of resource files, I've used default resource 
files from the following plugins:
maven-site-plugin   -   3.0-beta-2
maven-project-info-reports-plugin   -   2.2
maven-doxia-tools   -   1.2.1

Let me know if you need to update them for the next plugin releases - I'd be 
happy to help.

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