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