[jira] Created: (MJXR-26) JXR does not handle empty (completely commented) java-files...
JXR does not handle empty (completely commented) java-files...
--
Key: MJXR-26
URL: http://jira.codehaus.org/browse/MJXR-26
Project: Maven 2.x JXR Plugin
Issue Type: Bug
Affects Versions: 2.0
Environment: Maven 2.0.5 (Windows 2003 Srv/Windows XP)
Reporter: Jan Palmquist
Priority: Minor
I have detected that the jxr-plugin (or sub components) does not handle
java-files being completely commented away e.g.
//package my.demopackage;
//public class MyClass {
//}
This is not a big issue, however it is quite annoying to have to notify
developers that this not only is bad coding style but also breaks site
generation.
My stack trace:
INFO] Generate Test Source Xref report.
Unable to processPath
C:\CC\projects\MyProject\src\test\java\my\demopackage\MyClass.java =
c:\CC\projects\MyProject\target/site/xref-test\my\demopackage\MyClass.html
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at org.apache.maven.jxr.JavaCodeTransform.getHeader(JavaCodeTransform.java:651)
at org.apache.maven.jxr.JavaCodeTransform.transform(JavaCodeTransform.java:716)
at org.apache.maven.jxr.JavaCodeTransform.transform(JavaCodeTransform.java:787)
at org.apache.maven.jxr.JXR.transform(JXR.java:195)
at org.apache.maven.jxr.JXR.processPath(JXR.java:114)
at org.apache.maven.jxr.JXR.xref(JXR.java:335)
at
org.apache.maven.plugin.jxr.AbstractJxrReport.createXref(AbstractJxrReport.java:226)
at
org.apache.maven.plugin.jxr.AbstractJxrReport.executeReport(AbstractJxrReport.java:352)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:67)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:115)
at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:124)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
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: 9 minutes 24 seconds
[INFO] Finished at: Thu Mar 22 07:26:14 CET 2007
[INFO] Final Memory: 73M/200M
[INFO]
--
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-1434) please upload new version of vafer.org dependency
please upload new version of vafer.org dependency - Key: MAVENUPLOAD-1434 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1434 Project: maven-upload-requests Issue Type: Task Reporter: Torsten Curdt required for the new release of minijar which is supposed to be used for the maven 2.0..6 release -- 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-1435) Upload ZK 2.3.0 to the central repository
Upload ZK 2.3.0 to the central repository - Key: MAVENUPLOAD-1435 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1435 Project: maven-upload-requests Issue Type: Task Reporter: Tom M. Yeh http://www.zkoss.org/maven/bundles/2.3.0/zcommon-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/zweb-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/zk-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/zul-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/zhtml-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/zkplus-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/dojoz-0.4.1-1-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/gmapsz-2.0-3-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/timelinez-1.1-1-bundle.jar http://www.zkoss.org http://sourceforge.net/users/tomyeh/ ZK is an open-source Ajax Web framework that enables rich user interface for Web applications with no JavaScript and little programming. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-289) Allow to store clearcase-settings.xml in ${maven.home}/conf instead of ${user.home}/.scm
Allow to store clearcase-settings.xml in ${maven.home}/conf instead of
${user.home}/.scm
Key: SCM-289
URL: http://jira.codehaus.org/browse/SCM-289
Project: Maven SCM
Issue Type: Improvement
Components: maven-scm-provider-clearcase
Affects Versions: 1.0
Reporter: Arne Degenring
Attachments: maven-scm-provider-clearcase-ClearCaseUtil-patch.txt
The clearcase-settings.xml contain environment-specific, not user-specific
settings. It should there be possible to store it in ${maven.home}/conf instead
of ${user.home}/.scm. If it is present at both places, the file at
${user.home}/.scm wins.
See attached patch.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-290) Improved documentation for ClearCase SCM provider
Improved documentation for ClearCase SCM provider - Key: SCM-290 URL: http://jira.codehaus.org/browse/SCM-290 Project: Maven SCM Issue Type: Improvement Components: documentation, maven-scm-provider-clearcase, maven-scm-site Affects Versions: 1.0 Reporter: Arne Degenring Attachments: maven-scm-provider-clearcase-patch.txt, maven-scm-site-patch.txt The attached patches contain improved documentation for the ClearCase SCM provider. -- 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: (SCM-289) Allow to store clearcase-settings.xml in ${maven.home}/conf instead of ${user.home}/.scm
[
http://jira.codehaus.org/browse/SCM-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse closed SCM-289.
Assignee: Emmanuel Venisse
Resolution: Fixed
Fix Version/s: 1.0
Allow to store clearcase-settings.xml in ${maven.home}/conf instead of
${user.home}/.scm
Key: SCM-289
URL: http://jira.codehaus.org/browse/SCM-289
Project: Maven SCM
Issue Type: Improvement
Components: maven-scm-provider-clearcase
Affects Versions: 1.0
Reporter: Arne Degenring
Assigned To: Emmanuel Venisse
Fix For: 1.0
Attachments: maven-scm-provider-clearcase-ClearCaseUtil-patch.txt
The clearcase-settings.xml contain environment-specific, not user-specific
settings. It should there be possible to store it in ${maven.home}/conf
instead of ${user.home}/.scm. If it is present at both places, the file at
${user.home}/.scm wins.
See attached patch.
--
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: (SCM-290) Improved documentation for ClearCase SCM provider
[ http://jira.codehaus.org/browse/SCM-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-290. Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.0 Improved documentation for ClearCase SCM provider - Key: SCM-290 URL: http://jira.codehaus.org/browse/SCM-290 Project: Maven SCM Issue Type: Improvement Components: documentation, maven-scm-provider-clearcase, maven-scm-site Affects Versions: 1.0 Reporter: Arne Degenring Assigned To: Emmanuel Venisse Fix For: 1.0 Attachments: maven-scm-provider-clearcase-patch.txt, maven-scm-site-patch.txt The attached patches contain improved documentation for the ClearCase SCM provider. -- 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: (MRM-308) Maven1 requests are not served
Maven1 requests are not served -- Key: MRM-308 URL: http://jira.codehaus.org/browse/MRM-308 Project: Archiva Issue Type: Bug Affects Versions: 1.0 Environment: using latest version from SVN: revision 521221 archiva running on Tomcat-5.5.17 Reporter: Joerg Vater I got one managed repository with two proxied repositories, one for our locally built artifacts and the central repository. When I try to retreive an artifact with maven2 path layout (e.g. ant/ant/1.6.5/ant-1.6.5.jar) everything works fine. When I try to retreive the same artifact with maven1 path layout (ant/jars/ant-1.6.5.jar) the jar gets downloaded from the proxied repository but is not delivered to the client. Client response is a 404 (s. below). In the local directory it is stored with the maven2 path layout -- log output: 2007-03-22 12:20:51,278 4594195 [http-9080-Processor24] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact requested is: ant:ant:jar:1.6.5:runtime 2007-03-22 12:20:51,279 4594196 [http-9080-Processor24] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving ant/ant/1.6.5/ant-1.6.5.pom from ComBOTS Maven2 Repository 2007-03-22 12:20:51,279 4594196 [http-9080-Processor24] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact not found in repository: ComBOTS Maven2 Repository: File: /data/maven-repo/combots-maven2-repo/ant/ant/1.6.5/ant-1.6.5.pom does not exist 2007-03-22 12:20:51,281 4594198 [http-9080-Processor24] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving ant/ant/1.6.5/ant-1.6.5.pom from Maven2 Central Repository 2007-03-22 12:20:51,728 4594645 [http-9080-Processor24] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Successfully downloaded -- http response: Error 404 Not Found Resource in error: http://mavenproxy:9080/archiva/repository/ant/jars/ant-1.6.5.jar/ant/jars/ant-1.6.5.jar Exception details: it.could.webdav.DAVException: Not found at it.could.webdav.methods.HEAD.process(HEAD.java:52) at it.could.webdav.methods.GET.process(GET.java:58) at it.could.webdav.DAVProcessor.process(DAVProcessor.java:79) at org.codehaus.plexus.webdav.simple.SimpleDavServerComponent.process(SimpleDavServerComponent.java:142) at org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:147) at org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:111) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) --
[jira] Created: (SCM-291) Errors during date parsing with cvs version 1.12.12.
Errors during date parsing with cvs version 1.12.12. Key: SCM-291 URL: http://jira.codehaus.org/browse/SCM-291 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-cvs Affects Versions: 1.0-beta-4 Environment: Linux Suse 10 CVS 1.12.12 Reporter: johann angeli The changelog plugin used with cvs client 1.12.12, failed with the following error : [ERROR] cvs [log aborted]: Can't parse date/time: `2007-02-20T12:15:51+0100' The problem comes from the cvs client version 1.12.12 that doesn't seem any more to support the specified time format (-MM-dd'T'HH:mm:ssZ). Tests made with changelog and cvs client version 1.11.6 are ok. Older versions of changelog, prior to issue SCM-177, and cvs client version 1.12.12 work also correctly. The problem is solved by replacing the format -MM-dd'T'HH:mm:ssZ by this one -MM-dd HH:mm:ssZ in class AbstractCvsChangeLogCommand. -- 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: (MECLIPSE-248) Clean build of maven-eclipse-plugin-2.3 tag fails
Clean build of maven-eclipse-plugin-2.3 tag fails - Key: MECLIPSE-248 URL: http://jira.codehaus.org/browse/MECLIPSE-248 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.3 Environment: Linux (Ubuntu Edgy), Maven 2.0.5, JDK5update11, totally empty local repository, no remote repositories other than central Reporter: Max Bowsher Attachments: org.apache.maven.plugin.eclipse.EclipsePluginMasterProjectTest_testModule1Project.build.log A clean build of the maven-eclipse-plugin-2.3 tag fails, because of a test failure: Tests in error: testModule1Project(org.apache.maven.plugin.eclipse.EclipsePluginMasterProjectTest) (build log for this test is attached) Presumably this is not the fault of the eclipse plugin code, since it must have built at one time in order to be released, but I'm not sure where else to report it. The test failure poses a problem for people trying to make modified versions of the plugin based on the last released version. -- 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: (MRM-308) Maven1 requests are not served
[ http://jira.codehaus.org/browse/MRM-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90813 ] Joerg Vater commented on MRM-308: - When I change the layout of the managed repository to legacy it works for maven1 requests but not for maven2 requests. Maven1 requests are not served -- Key: MRM-308 URL: http://jira.codehaus.org/browse/MRM-308 Project: Archiva Issue Type: Bug Affects Versions: 1.0 Environment: using latest version from SVN: revision 521221 archiva running on Tomcat-5.5.17 Reporter: Joerg Vater I got one managed repository with two proxied repositories, one for our locally built artifacts and the central repository. When I try to retreive an artifact with maven2 path layout (e.g. ant/ant/1.6.5/ant-1.6.5.jar) everything works fine. When I try to retreive the same artifact with maven1 path layout (ant/jars/ant-1.6.5.jar) the jar gets downloaded from the proxied repository but is not delivered to the client. Client response is a 404 (s. below). In the local directory it is stored with the maven2 path layout -- log output: 2007-03-22 12:20:51,278 4594195 [http-9080-Processor24] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact requested is: ant:ant:jar:1.6.5:runtime 2007-03-22 12:20:51,279 4594196 [http-9080-Processor24] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving ant/ant/1.6.5/ant-1.6.5.pom from ComBOTS Maven2 Repository 2007-03-22 12:20:51,279 4594196 [http-9080-Processor24] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact not found in repository: ComBOTS Maven2 Repository: File: /data/maven-repo/combots-maven2-repo/ant/ant/1.6.5/ant-1.6.5.pom does not exist 2007-03-22 12:20:51,281 4594198 [http-9080-Processor24] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving ant/ant/1.6.5/ant-1.6.5.pom from Maven2 Central Repository 2007-03-22 12:20:51,728 4594645 [http-9080-Processor24] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Successfully downloaded -- http response: Error 404 Not Found Resource in error: http://mavenproxy:9080/archiva/repository/ant/jars/ant-1.6.5.jar/ant/jars/ant-1.6.5.jar Exception details: it.could.webdav.DAVException: Not found at it.could.webdav.methods.HEAD.process(HEAD.java:52) at it.could.webdav.methods.GET.process(GET.java:58) at it.could.webdav.DAVProcessor.process(DAVProcessor.java:79) at org.codehaus.plexus.webdav.simple.SimpleDavServerComponent.process(SimpleDavServerComponent.java:142) at org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:147) at org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:111) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
[jira] Created: (MRM-309) relocated artifacts are not delivered
relocated artifacts are not delivered - Key: MRM-309 URL: http://jira.codehaus.org/browse/MRM-309 Project: Archiva Issue Type: Bug Affects Versions: 1.0 Environment: latest version from SVN (rev. 521221) archiva running in tomcat-5.5.17 on a linux system Reporter: Joerg Vater One managed repository with two proxied repositories. When I request an artifact that is relocated in the proxied repository, the relocaated artifact is downloaded to the local repository but not delivered to the requestor. -- log messages: 2007-03-22 13:32:05,478 8868395 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact requested is: easymock:easymock:jar:2.0:runtime 2007-03-22 13:32:05,478 8868395 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving easymock/easymock/2.0/easymock-2.0.pom from ComBOTS Maven2 Repository 2007-03-22 13:32:05,478 8868395 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact not found in repository: ComBOTS Maven2 Repository: File: /data/maven-repo/combots-maven2-repo/easymock/easymock/2.0/easymock-2.0.pom does not exist 2007-03-22 13:32:05,478 8868395 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving easymock/easymock/2.0/easymock-2.0.pom from Maven2 Central Repository 2007-03-22 13:32:05,877 8868794 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Successfully downloaded 2007-03-22 13:32:05,889 8868806 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact easymock:easymock:2.0 has been relocated to org.easymock:easymock:2.0 2007-03-22 13:32:05,890 8868807 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving org/easymock/easymock/2.0/easymock-2.0.pom from ComBOTS Maven2 Repository 2007-03-22 13:32:05,890 8868807 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact not found in repository: ComBOTS Maven2 Repository: File: /data/maven-repo/combots-maven2-repo/org/easymock/easymock/2.0/easymock-2.0.pom does not exist 2007-03-22 13:32:05,890 8868807 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving org/easymock/easymock/2.0/easymock-2.0.pom from Maven2 Central Repository 2007-03-22 13:32:06,157 8869074 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Successfully downloaded 2007-03-22 13:32:06,158 8869075 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving org/easymock/easymock/2.0/easymock-2.0.jar from ComBOTS Maven2 Repository 2007-03-22 13:32:06,158 8869075 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact not found in repository: ComBOTS Maven2 Repository: File: /data/maven-repo/combots-maven2-repo/org/easymock/easymock/2.0/easymock-2.0.jar does not exist 2007-03-22 13:32:06,159 8869076 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving org/easymock/easymock/2.0/easymock-2.0.jar from Maven2 Central Repository 2007-03-22 13:32:07,017 8869934 [http-9080-Processor25] DEBUG org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Successfully downloaded -- html response: Error 404 Not Found Resource in error: http://mavenproxy:9080/archiva/repository/easymock/easymock/2.0/easymock-2.0.jar/easymock/easymock/2.0/easymock-2.0.jar Exception details: it.could.webdav.DAVException: Not found at it.could.webdav.methods.HEAD.process(HEAD.java:52) at it.could.webdav.methods.GET.process(GET.java:58) at it.could.webdav.DAVProcessor.process(DAVProcessor.java:79) at org.codehaus.plexus.webdav.simple.SimpleDavServerComponent.process(SimpleDavServerComponent.java:142) at org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:147) at org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:111) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at
[jira] Commented: (SCM-291) Errors during date parsing with cvs version 1.12.12.
[ http://jira.codehaus.org/browse/SCM-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90814 ] Emmanuel Venisse commented on SCM-291: -- cvs 1.12.* isn't yet a stable release but a feature release and it isn't supported yet by Maven-SCM. The date format is totally different in cvs 1.12 and we need to allow new formats. I can't change the actual format by -MM-dd HH:mm:ssZ for all cvs client because lot of them doesn't support this format. I think I'll allow to change the format in cvs-settings.xml Errors during date parsing with cvs version 1.12.12. Key: SCM-291 URL: http://jira.codehaus.org/browse/SCM-291 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-cvs Affects Versions: 1.0-beta-4 Environment: Linux Suse 10 CVS 1.12.12 Reporter: johann angeli Fix For: 1.0 The changelog plugin used with cvs client 1.12.12, failed with the following error : [ERROR] cvs [log aborted]: Can't parse date/time: `2007-02-20T12:15:51+0100' The problem comes from the cvs client version 1.12.12 that doesn't seem any more to support the specified time format (-MM-dd'T'HH:mm:ssZ). Tests made with changelog and cvs client version 1.11.6 are ok. Older versions of changelog, prior to issue SCM-177, and cvs client version 1.12.12 work also correctly. The problem is solved by replacing the format -MM-dd'T'HH:mm:ssZ by this one -MM-dd HH:mm:ssZ in class AbstractCvsChangeLogCommand. -- 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: (SCM-291) Errors during date parsing with cvs version 1.12.12.
[ http://jira.codehaus.org/browse/SCM-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-291: - Assignee: Emmanuel Venisse Fix Version/s: 1.0 Errors during date parsing with cvs version 1.12.12. Key: SCM-291 URL: http://jira.codehaus.org/browse/SCM-291 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-cvs Affects Versions: 1.0-beta-4 Environment: Linux Suse 10 CVS 1.12.12 Reporter: johann angeli Assigned To: Emmanuel Venisse Fix For: 1.0 The changelog plugin used with cvs client 1.12.12, failed with the following error : [ERROR] cvs [log aborted]: Can't parse date/time: `2007-02-20T12:15:51+0100' The problem comes from the cvs client version 1.12.12 that doesn't seem any more to support the specified time format (-MM-dd'T'HH:mm:ssZ). Tests made with changelog and cvs client version 1.11.6 are ok. Older versions of changelog, prior to issue SCM-177, and cvs client version 1.12.12 work also correctly. The problem is solved by replacing the format -MM-dd'T'HH:mm:ssZ by this one -MM-dd HH:mm:ssZ in class AbstractCvsChangeLogCommand. -- 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: (MRRESOURCES-18) Error when no 'inceptionYear' is specified in POM
Error when no 'inceptionYear' is specified in POM
-
Key: MRRESOURCES-18
URL: http://jira.codehaus.org/browse/MRRESOURCES-18
Project: Maven 2.x Remote Resources Plugin
Issue Type: Bug
Affects Versions: 1.0-alpha-3
Reporter: Konstantin Pavlov
Priority: Minor
[INFO] [remote-resources:process {execution: default}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] You must specify an inceptionYear.
'inceptionYear' is optionl element in the POM (see
http://maven.apache.org/maven-v4_0_0.xsd), but plugin requires it to be
specified.
--
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: (MRRESOURCES-18) Error when no 'inceptionYear' is specified in POM
[
http://jira.codehaus.org/browse/MRRESOURCES-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90815
]
Konstantin Pavlov commented on MRRESOURCES-18:
--
Error when no 'inceptionYear' is *NOT* specified in the POM
Error when no 'inceptionYear' is specified in POM
-
Key: MRRESOURCES-18
URL: http://jira.codehaus.org/browse/MRRESOURCES-18
Project: Maven 2.x Remote Resources Plugin
Issue Type: Bug
Affects Versions: 1.0-alpha-3
Reporter: Konstantin Pavlov
Priority: Minor
[INFO] [remote-resources:process {execution: default}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] You must specify an inceptionYear.
'inceptionYear' is optionl element in the POM (see
http://maven.apache.org/maven-v4_0_0.xsd), but plugin requires it to be
specified.
--
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: (SCM-185) Validity check rejects valid protocol
[ http://jira.codehaus.org/browse/SCM-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-185. Assignee: Emmanuel Venisse Resolution: Fixed Validity check rejects valid protocol - Key: SCM-185 URL: http://jira.codehaus.org/browse/SCM-185 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-svn Affects Versions: 1.0-beta-2 Reporter: Joerg Schaible Assigned To: Emmanuel Venisse Fix For: 1.0 According to the subversion manual a user can add arbitrary protocols by defining new tunnels in his local subversion configuration. Such definitions are necessary to tunnel ports, define the usage of a smart card, ... e.g. defining an entry in the tunnel section of the .subversion/config file to access over SSH protocol version 1 can be defined like: ssh1=ssh -1 A repo would be accessed with svn+ssh1://repo/url This is not possible, since the SvnScmProvider checks against a fixed set of protocols, which is not correct. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2890) Allow for deploying to multiple repositories
Allow for deploying to multiple repositories Key: MNG-2890 URL: http://jira.codehaus.org/browse/MNG-2890 Project: Maven 2 Issue Type: Improvement Components: Deployment Reporter: David Jackman There is currently no way to list multiple repositories for deployment. When I've brought this question up before, people say to create mirrors of the repository, but that's not really the right solution in many cases. In my own case, I need to deploy to a Maven 1.x repository as well as the 2.x repository for the time being (while projects are moving from Maven 1 to Maven 2). This situation can't be solved by a repository mirror. -- 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-2854) Recreating pom.properties always breaks the archivers uptodate check
[
http://jira.codehaus.org/browse/MNG-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90820
]
Jason van Zyl commented on MNG-2854:
Point one is fine.
Point two is not fine. One artifact and so many people expect the
pom.properties file and is what we document. That can't change and I will never
support the widespread production of multiple artifacts.
Point three is fine.
Fix up the second point and I will apply the patch. Also, how did you test this?
Recreating pom.properties always breaks the archivers uptodate check
Key: MNG-2854
URL: http://jira.codehaus.org/browse/MNG-2854
Project: Maven 2
Issue Type: Bug
Components: maven-archiver
Affects Versions: 2.0.5
Reporter: Jochen Wiedmann
Attachments: maven-archiver-properties.patch
The maven-archiver creates a file called pom.properties on every invocation.
(Unless the flag addMavenDescriptor is set to false, which few people do.)
This forced recreation makes the uptodate check fail. In other words, jar
files are always recreated, regardless whether anything was recompiled.
Obviously, this makes the uptodate check of war files etc. fail as well,
because the included jar files are always changed.. This is a major drawback,
because it makes Maven much slower than, for example, Ant-.
The attached patch proposes a solution for the same problem. What the patch
does:
- It is obviously bad, that the generated pom.properties file is in the
projects directory. The
patch moves the file to ${project.build.directory}/maven-archiver, which
seems to me to
be a more sensible solution.
- Second, whether we like it or not, there are projects, which create
multiple artifacts. In other
words, it isn't good to have a single file. The patch renames the
pom.properties file to
${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently
unique.
- Finally, the patch makes the maven-archiver check, whether the
pom.properties file has
actually changed. (In other words, whether groupId, artifactId, or version
have changed.)
It does so, by writing the file to an internal buffer and comparing the
file on the disk and
the internal buffer (after skipping the line with the timestamp).
In other words, in the usual case, where groupId, artifactId and version
haven't changed, the pom.properties file remains unchanged. In particular,
the jar file doesn't need to be recreated.
--
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: (SCM-188) Add the posibility of adding an entire directory to SCM
[ http://jira.codehaus.org/browse/SCM-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-188: - Fix Version/s: (was: 1.0) future Add the posibility of adding an entire directory to SCM --- Key: SCM-188 URL: http://jira.codehaus.org/browse/SCM-188 Project: Maven SCM Issue Type: New Feature Components: maven-scm-api Affects Versions: 1.0-beta-3 Reporter: Carlos Sanchez Priority: Critical Fix For: future For the scm wagon I'd need to add a whole directory to scm. Right now the only solution is create a ScmFileSet, but none of the current methods adds directories, i have to look for them and add in order so the svn add works correctly. It'd be a nice to have in the API an addDirectory or make the add command add directories recursively (I don't know what's the use case of the current behaviour) eg. translated to svn it would call a svn add recursively, also optimizing the current approach of calling lots of times to external svn -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2891) Fix deployment permissions so by default group write works
Fix deployment permissions so by default group write works -- Key: MNG-2891 URL: http://jira.codehaus.org/browse/MNG-2891 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.5 Reporter: Jason van Zyl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2891) Fix deployment permissions so by default group write works
[ http://jira.codehaus.org/browse/MNG-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2891: --- Description: We will change some code in Maven to set these defaults reasonably. Fix Version/s: 2.0.6 Fix deployment permissions so by default group write works -- Key: MNG-2891 URL: http://jira.codehaus.org/browse/MNG-2891 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.5 Reporter: Jason van Zyl Fix For: 2.0.6 We will change some code in Maven to set these defaults reasonably. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2760) Fix deployment so that assemblies are signed with the GPG plugin
[ http://jira.codehaus.org/browse/MNG-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2760. -- Resolution: Won't Fix We can't actually do this because the install/deploy rename any attached artifacts which is the right thing to do. We need to make the assembly in the correct place to have it named correctly. Or we deploy separately and we typically have not pushed assemblies to the repo. At least for apache. Fix deployment so that assemblies are signed with the GPG plugin Key: MNG-2760 URL: http://jira.codehaus.org/browse/MNG-2760 Project: Maven 2 Issue Type: Bug Components: Deployment Reporter: Jason van Zyl Assigned To: Jason van Zyl Fix For: 2.0.6 Currenty, the attached assemblies are not signed. -- 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: (SCM-213) Broken with Cygwin
[ http://jira.codehaus.org/browse/SCM-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-213. Assignee: Emmanuel Venisse Resolution: Fixed I can't reproduce with latest code so I think it's fixed. Tested on the Maven-SCM TCK with windows svn and cygwin svn Broken with Cygwin -- Key: SCM-213 URL: http://jira.codehaus.org/browse/SCM-213 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-svn Affects Versions: 1.0-beta-3 Environment: Cygwin under Windows, Maven release plugin version 2.0-beta-4 Reporter: Chas Douglass Assigned To: Emmanuel Venisse Fix For: 1.0 svn doesn't like absolute path for the files to commit when we run it under cygwin with a windows svn and a cygwin svn. svn --non-interactive commit --file c:\temp\maven-scm-945043858.commit e:/newapps/JEC/pom.xml Working directory: e:\newapps\JEC doesn't works with the same error you have svn --non-interactive commit --file c:\temp\maven-scm-945043858.commit pom.xml Working directory: e:\newapps\JEC works fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-146) Release tag with SVN under Cygwin fails when sending the svn command a bad absolute path
[ http://jira.codehaus.org/browse/MRELEASE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90823 ] Emmanuel Venisse commented on MRELEASE-146: --- Can you test with 2.0-beta-5-SNAPSHOT? Normally, we use relative path and I can't reproduce it but maybe the release plugin use somewhere an absolute path. Release tag with SVN under Cygwin fails when sending the svn command a bad absolute path Key: MRELEASE-146 URL: http://jira.codehaus.org/browse/MRELEASE-146 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.0-beta-4 Environment: Windows XP Reporter: Christian Gruber When release:prepare is invoked, on a cygwin system using svn provided with cygwin, the following error occurs. [INFO] Checking in modified POMs... [INFO] Executing: svn --non-interactive commit --file E:\DOCUME~1\CGRUBE~1.DJI\LOCALS~1\Temp\maven-scm-1141263545.commit E:/projects/israfil-fw/net.israfil.foundation-JDK1.4/pom.xml [INFO] Working directory: E:\projects\israfil-fw\net.israfil.foundation-JDK1.4 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to commit files Provider message: The svn command failed. Command output: svn: '/projects/israfil-fw/net.israfil.foundation-JDK1.4/E:/projects/israfil-fw/net.israfil.foundation-JDK1.4' is not a working copy ... SVN on cygwin interprets E:/projects/israfil-fw/net.israfil.foundation-JDK1.4/pom.xml to be /projects/israfil-fw/net.israfil.foundation-JDK1.4/E:/projects/israfil-fw/net.israfil.foundation-JDK1.4, essentially appending the absolute path on the current working driectory as if it were a relative path. This is very odd, since svn command E:/projects/israfil-fw/net.israfil.foundation-JDK1.4 works like a charm. I tried it with E: and e: to no avail. Proposed solution: Use relative paths Alternative - really really bad alternative: detect the presence of cygwin and re-structure the file path to use /cygdrive/e/blah/blah format. Ultimate remedy: Figure out why SVN is interpreting this way and fix in svn. -Christian. -- 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: (MGPG-6) Attached jars/assemblies that would have renamed files result in wacky .asc files deployed....
Attached jars/assemblies that would have renamed files result in wacky .asc files deployed -- Key: MGPG-6 URL: http://jira.codehaus.org/browse/MGPG-6 Project: Maven 2.x GPG Plugin Issue Type: Bug Affects Versions: 1.0-alpha-3 Reporter: Daniel Kulp If an assembly or jar plugin uses a finalName config element to change the name of the artifacts, when installed/deployed, they get renamed. However, the .asc files usually end up with a different name. In this case, the .asc files should not be attached and warning issued. Alternatively, they could be copied to the proper deploy name and attached in that form. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-146) Release tag with SVN under Cygwin fails when sending the svn command a bad absolute path
[ http://jira.codehaus.org/browse/MRELEASE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90825 ] Christian Gruber commented on MRELEASE-146: --- Sadly, I can't. I have returned my laptop and now have a MacBook Pro which I am more than happy with, and does not exhibit this behaviour. Release tag with SVN under Cygwin fails when sending the svn command a bad absolute path Key: MRELEASE-146 URL: http://jira.codehaus.org/browse/MRELEASE-146 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.0-beta-4 Environment: Windows XP Reporter: Christian Gruber When release:prepare is invoked, on a cygwin system using svn provided with cygwin, the following error occurs. [INFO] Checking in modified POMs... [INFO] Executing: svn --non-interactive commit --file E:\DOCUME~1\CGRUBE~1.DJI\LOCALS~1\Temp\maven-scm-1141263545.commit E:/projects/israfil-fw/net.israfil.foundation-JDK1.4/pom.xml [INFO] Working directory: E:\projects\israfil-fw\net.israfil.foundation-JDK1.4 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to commit files Provider message: The svn command failed. Command output: svn: '/projects/israfil-fw/net.israfil.foundation-JDK1.4/E:/projects/israfil-fw/net.israfil.foundation-JDK1.4' is not a working copy ... SVN on cygwin interprets E:/projects/israfil-fw/net.israfil.foundation-JDK1.4/pom.xml to be /projects/israfil-fw/net.israfil.foundation-JDK1.4/E:/projects/israfil-fw/net.israfil.foundation-JDK1.4, essentially appending the absolute path on the current working driectory as if it were a relative path. This is very odd, since svn command E:/projects/israfil-fw/net.israfil.foundation-JDK1.4 works like a charm. I tried it with E: and e: to no avail. Proposed solution: Use relative paths Alternative - really really bad alternative: detect the presence of cygwin and re-structure the file path to use /cygdrive/e/blah/blah format. Ultimate remedy: Figure out why SVN is interpreting this way and fix in svn. -Christian. -- 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: (SCM-232) Improve error message when CVS URL is not correct
[ http://jira.codehaus.org/browse/SCM-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-232. Assignee: Emmanuel Venisse Resolution: Fixed Improve error message when CVS URL is not correct - Key: SCM-232 URL: http://jira.codehaus.org/browse/SCM-232 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-cvs Affects Versions: 1.0-beta-3 Environment: Win XP Reporter: Christoph Amshoff Assigned To: Emmanuel Venisse Fix For: 1.0 When the CVS URL is not correct because the module name is misspelled, the error output always is Embedded error: Exception while executing SCM command. Username isn't defined. This is misleading, since the username is definitely correct. This took me more than 2 hours to figure out and should be fixed by issuing a more applicable error message. -- 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: (MDEP-78) analyze-dep-mgt has the labels reversed
analyze-dep-mgt has the labels reversed --- Key: MDEP-78 URL: http://jira.codehaus.org/browse/MDEP-78 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: analyze Affects Versions: 2.0-alpha-3 Reporter: Brian Fox Assigned To: Brian Fox The resolved line and the DepMgt outputs are reversed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2891) Fix deployment permissions so by default group write works
[ http://jira.codehaus.org/browse/MNG-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2891. -- Resolution: Fixed Test deployment to apache shows we're all set. Fix deployment permissions so by default group write works -- Key: MNG-2891 URL: http://jira.codehaus.org/browse/MNG-2891 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.5 Reporter: Jason van Zyl Fix For: 2.0.6 We will change some code in Maven to set these defaults reasonably. -- 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: (MDEP-78) analyze-dep-mgt has the labels reversed
[ http://jira.codehaus.org/browse/MDEP-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-78. - Resolution: Fixed Fix Version/s: 2.0-alpha-4 analyze-dep-mgt has the labels reversed --- Key: MDEP-78 URL: http://jira.codehaus.org/browse/MDEP-78 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: analyze Affects Versions: 2.0-alpha-3 Reporter: Brian Fox Assigned To: Brian Fox Fix For: 2.0-alpha-4 The resolved line and the DepMgt outputs are reversed. -- 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: (SCM-291) Errors during date parsing with cvs version 1.12.12.
[ http://jira.codehaus.org/browse/SCM-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-291. Resolution: Fixed Errors during date parsing with cvs version 1.12.12. Key: SCM-291 URL: http://jira.codehaus.org/browse/SCM-291 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-cvs Affects Versions: 1.0-beta-4 Environment: Linux Suse 10 CVS 1.12.12 Reporter: johann angeli Assigned To: Emmanuel Venisse Fix For: 1.0 The changelog plugin used with cvs client 1.12.12, failed with the following error : [ERROR] cvs [log aborted]: Can't parse date/time: `2007-02-20T12:15:51+0100' The problem comes from the cvs client version 1.12.12 that doesn't seem any more to support the specified time format (-MM-dd'T'HH:mm:ssZ). Tests made with changelog and cvs client version 1.11.6 are ok. Older versions of changelog, prior to issue SCM-177, and cvs client version 1.12.12 work also correctly. The problem is solved by replacing the format -MM-dd'T'HH:mm:ssZ by this one -MM-dd HH:mm:ssZ in class AbstractCvsChangeLogCommand. -- 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: (SCM-291) Errors during date parsing with cvs version 1.12.12.
[ http://jira.codehaus.org/browse/SCM-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90828 ] Emmanuel Venisse commented on SCM-291: -- -MM-dd HH:mm:ssZ format is used by default now as it work in cvs 1.11 too If a cvs can't use this format, he'll can define an other one in cvs-settings.xml Errors during date parsing with cvs version 1.12.12. Key: SCM-291 URL: http://jira.codehaus.org/browse/SCM-291 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-cvs Affects Versions: 1.0-beta-4 Environment: Linux Suse 10 CVS 1.12.12 Reporter: johann angeli Assigned To: Emmanuel Venisse Fix For: 1.0 The changelog plugin used with cvs client 1.12.12, failed with the following error : [ERROR] cvs [log aborted]: Can't parse date/time: `2007-02-20T12:15:51+0100' The problem comes from the cvs client version 1.12.12 that doesn't seem any more to support the specified time format (-MM-dd'T'HH:mm:ssZ). Tests made with changelog and cvs client version 1.11.6 are ok. Older versions of changelog, prior to issue SCM-177, and cvs client version 1.12.12 work also correctly. The problem is solved by replacing the format -MM-dd'T'HH:mm:ssZ by this one -MM-dd HH:mm:ssZ in class AbstractCvsChangeLogCommand. -- 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-1436) xSocket V1.0
xSocket V1.0 Key: MAVENUPLOAD-1436 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1436 Project: maven-upload-requests Issue Type: Task Reporter: grro xSocket is a easy to use nio-based library to build high performance, high scalable network applications. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2892) Use minijar to hide the use of plexus-utils internally so that plugins can use their own version
Use minijar to hide the use of plexus-utils internally so that plugins can use their own version Key: MNG-2892 URL: http://jira.codehaus.org/browse/MNG-2892 Project: Maven 2 Issue Type: Improvement Affects Versions: 2.0.5 Reporter: Jason van Zyl Fix For: 2.0.6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2892) Use minijar to hide the use of plexus-utils internally so that plugins can use their own version
[ http://jira.codehaus.org/browse/MNG-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2892: --- Fix Version/s: 2.0.6 Use minijar to hide the use of plexus-utils internally so that plugins can use their own version Key: MNG-2892 URL: http://jira.codehaus.org/browse/MNG-2892 Project: Maven 2 Issue Type: Improvement Affects Versions: 2.0.5 Reporter: Jason van Zyl Assigned To: Jason van Zyl Fix For: 2.0.6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1434) please upload new version of vafer.org dependency
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1434. --- Assignee: Carlos Sanchez Resolution: Fixed please upload new version of vafer.org dependency - Key: MAVENUPLOAD-1434 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1434 Project: maven-upload-requests Issue Type: Task Reporter: Torsten Curdt Assigned To: Carlos Sanchez required for the new release of minijar which is supposed to be used for the maven 2.0..6 release -- 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: (MAVENUPLOAD-1436) xSocket V1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1436. --- Assignee: Carlos Sanchez Resolution: Fixed xSocket V1.0 Key: MAVENUPLOAD-1436 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1436 Project: maven-upload-requests Issue Type: Task Reporter: grro Assigned To: Carlos Sanchez xSocket is a easy to use nio-based library to build high performance, high scalable network applications. -- 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: (MAVENUPLOAD-1432) upload winstone to maven central
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1432. --- Assignee: Carlos Sanchez Resolution: Fixed upload winstone to maven central Key: MAVENUPLOAD-1432 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1432 Project: maven-upload-requests Issue Type: Task Reporter: Jorg Heymans Assigned To: Carlos Sanchez There is also a lite version which is provided in a separate bundle: www.domek.be/winstone-lite-bundle.tar -- 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: (MAVENUPLOAD-1435) Upload ZK 2.3.0 to the central repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1435. --- Assignee: Carlos Sanchez Resolution: Fixed You are going to have to start setting up an automated sync http://maven.apache.org/guides/mini/guide-central-repository-upload.html Sync'ing your own repository with ibiblio Upload ZK 2.3.0 to the central repository - Key: MAVENUPLOAD-1435 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1435 Project: maven-upload-requests Issue Type: Task Reporter: Tom M. Yeh Assigned To: Carlos Sanchez http://www.zkoss.org/maven/bundles/2.3.0/zcommon-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/zweb-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/zk-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/zul-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/zhtml-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/zkplus-2.3.0-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/dojoz-0.4.1-1-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/gmapsz-2.0-3-bundle.jar http://www.zkoss.org/maven/bundles/2.3.0/timelinez-1.1-1-bundle.jar http://www.zkoss.org http://sourceforge.net/users/tomyeh/ ZK is an open-source Ajax Web framework that enables rich user interface for Web applications with no JavaScript and little programming. -- 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: (MJXR-26) JXR does not handle empty (completely commented) java-files...
[
http://jira.codehaus.org/browse/MJXR-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MJXR-26.
---
Assignee: Dennis Lundberg
Resolution: Fixed
Fix Version/s: 2.1
This has already been fixed by previous commits. I created a small project for
this and verified that I got an NPE when running 'mvn site'. Using the same
project with maven-jxr-plugin 2.1-SNAPSHOT I do not get the NPE anymore.
JXR does not handle empty (completely commented) java-files...
--
Key: MJXR-26
URL: http://jira.codehaus.org/browse/MJXR-26
Project: Maven 2.x JXR Plugin
Issue Type: Bug
Affects Versions: 2.0
Environment: Maven 2.0.5 (Windows 2003 Srv/Windows XP)
Reporter: Jan Palmquist
Assigned To: Dennis Lundberg
Priority: Minor
Fix For: 2.1
I have detected that the jxr-plugin (or sub components) does not handle
java-files being completely commented away e.g.
//package my.demopackage;
//public class MyClass {
//}
This is not a big issue, however it is quite annoying to have to notify
developers that this not only is bad coding style but also breaks site
generation.
My stack trace:
INFO] Generate Test Source Xref report.
Unable to processPath
C:\CC\projects\MyProject\src\test\java\my\demopackage\MyClass.java =
c:\CC\projects\MyProject\target/site/xref-test\my\demopackage\MyClass.html
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.jxr.JavaCodeTransform.getHeader(JavaCodeTransform.java:651)
at
org.apache.maven.jxr.JavaCodeTransform.transform(JavaCodeTransform.java:716)
at
org.apache.maven.jxr.JavaCodeTransform.transform(JavaCodeTransform.java:787)
at org.apache.maven.jxr.JXR.transform(JXR.java:195)
at org.apache.maven.jxr.JXR.processPath(JXR.java:114)
at org.apache.maven.jxr.JXR.xref(JXR.java:335)
at
org.apache.maven.plugin.jxr.AbstractJxrReport.createXref(AbstractJxrReport.java:226)
at
org.apache.maven.plugin.jxr.AbstractJxrReport.executeReport(AbstractJxrReport.java:352)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:67)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:115)
at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:124)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
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: 9 minutes 24 seconds
[INFO] Finished at: Thu Mar 22 07:26:14 CET 2007
[INFO] Final Memory: 73M/200M
[INFO]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
[jira] Updated: (MNG-2854) Recreating pom.properties always breaks the archivers uptodate check
[
http://jira.codehaus.org/browse/MNG-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann updated MNG-2854:
-
Attachment: maven-archiver-properties-2.patch
Ok, here's an updated version of the patch. Note, that it contains a test case
(MavenArchiverTest.testRecreation) that verifies whether the jar file is indeed
created when invoked for the first time, but isn't for the second time.
Recreating pom.properties always breaks the archivers uptodate check
Key: MNG-2854
URL: http://jira.codehaus.org/browse/MNG-2854
Project: Maven 2
Issue Type: Bug
Components: maven-archiver
Affects Versions: 2.0.5
Reporter: Jochen Wiedmann
Attachments: maven-archiver-properties-2.patch,
maven-archiver-properties.patch
The maven-archiver creates a file called pom.properties on every invocation.
(Unless the flag addMavenDescriptor is set to false, which few people do.)
This forced recreation makes the uptodate check fail. In other words, jar
files are always recreated, regardless whether anything was recompiled.
Obviously, this makes the uptodate check of war files etc. fail as well,
because the included jar files are always changed.. This is a major drawback,
because it makes Maven much slower than, for example, Ant-.
The attached patch proposes a solution for the same problem. What the patch
does:
- It is obviously bad, that the generated pom.properties file is in the
projects directory. The
patch moves the file to ${project.build.directory}/maven-archiver, which
seems to me to
be a more sensible solution.
- Second, whether we like it or not, there are projects, which create
multiple artifacts. In other
words, it isn't good to have a single file. The patch renames the
pom.properties file to
${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently
unique.
- Finally, the patch makes the maven-archiver check, whether the
pom.properties file has
actually changed. (In other words, whether groupId, artifactId, or version
have changed.)
It does so, by writing the file to an internal buffer and comparing the
file on the disk and
the internal buffer (after skipping the line with the timestamp).
In other words, in the usual case, where groupId, artifactId and version
haven't changed, the pom.properties file remains unchanged. In particular,
the jar file doesn't need to be recreated.
--
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: (SCM-263) Subversion http url should support password on the url
[ http://jira.codehaus.org/browse/SCM-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-263. Assignee: Emmanuel Venisse Resolution: Fixed Subversion http url should support password on the url -- Key: SCM-263 URL: http://jira.codehaus.org/browse/SCM-263 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-svn Affects Versions: 1.0-beta-4 Environment: xp, linux, Reporter: Dan Tran Assigned To: Emmanuel Venisse Fix For: 1.0 both cvs and staream urls allow password on url. currently scm:svn:http://user:[EMAIL PROTECTED]/path see user:password as username Having password on url simplifies lots of work my a test application i am writing that has no concern about password in the url comments? why do we not support this feature to beginning with? -- 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: (SCM-262) scm:tag for subversion tagging from local version of code, not directly from repository
[ http://jira.codehaus.org/browse/SCM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-262: - Component/s: maven-scm-provider-svn scm:tag for subversion tagging from local version of code, not directly from repository --- Key: SCM-262 URL: http://jira.codehaus.org/browse/SCM-262 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-svn Reporter: Stephan Heilner Fix For: future In theory, you shouldn't tag or branch from a local and potentially different version of the code. From what I can tell, the scm:tag imports your existing code into a new tag. With subversion, tagging is very lightweight if you do a 'svn copy trunk_url tag_url'. The way it currently works make sense for other repositories such as CVS but not for subversion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-1981) move maven snapshots to the apache snapshot repo
[ http://jira.codehaus.org/browse/MNG-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1981. -- Resolution: Fixed Yes, everything is published to Apache now. move maven snapshots to the apache snapshot repo Key: MNG-1981 URL: http://jira.codehaus.org/browse/MNG-1981 Project: Maven 2 Issue Type: Bug Components: Bootstrap Build Reporter: Brett Porter Fix For: 2.0.x -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2091) NPE when including middlegen-hibernate-plugin
[ http://jira.codehaus.org/browse/MNG-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2091. -- Resolution: Fixed Plugin related problem. If still a problem submit a working build that can be tested. NPE when including middlegen-hibernate-plugin - Key: MNG-2091 URL: http://jira.codehaus.org/browse/MNG-2091 Project: Maven 2 Issue Type: Bug Components: Plugin API Affects Versions: 2.2 Environment: SUSE Linux 9.3 on i386; JVM: 1.5.0_04-b05; Kernel: 2.6.11.4.20a-11-default Reporter: Bernd Adamowicz Fix For: 2.0.x As soon as the plugin middlegen-hibernat-plugin is integrated into the POM, a NPE is thrown when the plugin is added. This is the stacktrace: [EMAIL PROTECTED]:~/THEMEN/ECLIPSE_WORKBENCH/Buttenlauf mvn compile [INFO] Scanning for projects... [INFO] [INFO] Building Buttenlauf Auswertung - GVC Criesbach [INFO]task-segment: [compile] [INFO] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:295) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:200) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:165) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1218) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1182) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:950) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:450) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) 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: 2 seconds [INFO] Finished at: Mon Feb 20 21:04:30 CET 2006 [INFO] Final Memory: 1M/4M [INFO] This is how the Middlegen-part of the POM looks like: build plugins plugin groupIdmiddlegen/groupId artifactIdmiddlegen-hibernate-plugin/artifactId version2.1/version /plugin plugin I know this issue has been around with Maven 1.x. The cause there was a corrupted plugin pom from middlegen. But I wasn't able to reproduce this. I couldn't find anything wrong with the pom. This problem can be reproduced with Maven 2.0 and on Windows systems, too. So I think the problem really is the plugin. I will open an issue on the Middlegen page, too and will (hopefully) post a solution here. But maybe someone has a workaround to fix this in the meantime. Thanks in advance for any help. Bernd -- 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
[jira] Closed: (MNG-380) migrate integration tests belonging to non-core plugins
[ http://jira.codehaus.org/browse/MNG-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-380. - Resolution: Fixed Issue contained in notes about the ITs. migrate integration tests belonging to non-core plugins --- Key: MNG-380 URL: http://jira.codehaus.org/browse/MNG-380 Project: Maven 2 Issue Type: Bug Reporter: Brett Porter Fix For: 2.0.x some of the integration tests depend on plugins not part of the core (eg war, ear, verifier). Make these tests be integration tests on those plugins themselves when the lifecycle supports it. After this, the integration tests should all relate to the core plugins, so the second step in the bootstrap that rebuilds all plugins with m2 should be removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-145) release:prepare requires all modules to be SNAPSHOTS
[ http://jira.codehaus.org/browse/MRELEASE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90842 ] Parolini Antonio commented on MRELEASE-145: --- I agree with Jorg: the release-plugin should be have the ability to make partial release without touching the not-snapshot poms. My workaround for this issue so far as been to use profiles, in order to choose what module are released. release:prepare requires all modules to be SNAPSHOTS Key: MRELEASE-145 URL: http://jira.codehaus.org/browse/MRELEASE-145 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-4 Reporter: Jörg Hohwiller The biggest need for the maven-release-plugin is in complex projects with a lot of modules (that may again have modules). If I do not get it wrong, the current released version forces all modules to be snapshots and releases them individually. This is completely useless in my situation because in the end this forces me to release alle modules together for every change that is to be released and more or less causes that all modules have the same version number. When I call mvn replease:prepare on my toplevel project this is no snapshot, it fails with this error: The project groupId:artifactId isn't a snapshot (version). I would expect release:prepare to leave non SNAPSHOT modules untouched (and only verify that they do not have SNAPSHOT dependencies, what should never be the case if the version is no snapshot). All reactor projects that have a -SNAPHSOT version should be released and theier project-internal dependencies should also be set to the acording released version (and later be set to the new SNAPSHOT). Additionally I want to have the complete project to be tagged as a whole instead of each module. This could potentially be configureable (especially which directory is actually tagged, e.g. if the toplevel project is not in trunk/ but somewhere deeper say trunk/develop because other directories in trunk are huge but do not need to be checked out by every developer but need to be tagged). I personally think that the best flexibility and final freedom would be to split off the release:prepare goal into 3 goals: -create release version(s) -create tag(s) -update to snapshot version(s) These goals could be used individually and one could add some custom steps or replace one with something else. For creating the snapshot versions there is also the problem, that you do not know right away which project will be modified when in the future. The coolest thing would be if this would happen automatically when the first change is commited to the module. But this is of cause not praticable in reality (maybe if all commits would be done with maven). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2481) project builder should make the processed project cache configurable
[ http://jira.codehaus.org/browse/MNG-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2481. -- Resolution: Fixed We decided the caching should not be done in the project builder. It is being done at a session level in the reactor manager now. project builder should make the processed project cache configurable Key: MNG-2481 URL: http://jira.codehaus.org/browse/MNG-2481 Project: Maven 2 Issue Type: Bug Components: Performance, POM Affects Versions: 2.0.4 Reporter: Brett Porter Fix For: 2.0.x the cache in the project builder is a simple map. This is usually fine for Maven, but in long lived processes (Continuum, MRM, and I imagine the IDE plugins as it gets used more) it can chew up quite some memory. I'd suggest we make it configurable: - can turn it on or off using plexus configuration - can limit its size using plexus configuration - can change other options, such as adding expiry ages to items regardless of size Rather than implementing something in the project builder itself, I suggest having a cache plexus component that does everything we need it to (this could be reused in the webapps as well). I'm not sure of any existing caching solutions (I know OSCache has a general Java cache but don't know how suitable it is). One alterantive might be to round out commons-cache with some features and plexus descriptors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-1395) Change all m2.bat and m2 references in sources to mvn.bat and mvn
[ http://jira.codehaus.org/browse/MNG-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1395. -- Resolution: Fixed Patch applied. Change all m2.bat and m2 references in sources to mvn.bat and mvn - Key: MNG-1395 URL: http://jira.codehaus.org/browse/MNG-1395 Project: Maven 2 Issue Type: Bug Reporter: Piotr Bzdyl Priority: Minor Fix For: 2.0.x Attachments: m2-to-mvn.diff See attached patch (for all files I grepped for m2.bat and m2 - shell script calls). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2089) APT AspectJ plugins
[ http://jira.codehaus.org/browse/MNG-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2089. -- Resolution: Fixed These exist at mojo.codehaus.org. APT AspectJ plugins - Key: MNG-2089 URL: http://jira.codehaus.org/browse/MNG-2089 Project: Maven 2 Issue Type: Wish Components: Sandbox Affects Versions: 2.0.3 Reporter: Juraj Burian Priority: Minor Fix For: 2.0.x Attachments: APTexamplePrj.zip, plugins.zip We have prototypes of AspectJ APT plugins ready. Can you put it into the Sanbox? Thanx. best regards J.Burian -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-1120) don't require modelVersion / if there is a valid schema element
[ http://jira.codehaus.org/browse/MNG-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-1120: --- Description: This can't happen in 2.0.x. Fix Version/s: (was: 2.0.x) 2.1.x don't require modelVersion / if there is a valid schema element - Key: MNG-1120 URL: http://jira.codehaus.org/browse/MNG-1120 Project: Maven 2 Issue Type: Bug Reporter: Brett Porter Priority: Minor Fix For: 2.1.x This can't happen in 2.0.x. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-1498) [PATCH] Add all mailing lists to Maven's main site
[ http://jira.codehaus.org/browse/MNG-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1498. -- Resolution: Fixed This will be generated. [PATCH] Add all mailing lists to Maven's main site -- Key: MNG-1498 URL: http://jira.codehaus.org/browse/MNG-1498 Project: Maven 2 Issue Type: Improvement Reporter: Felipe Leme Priority: Minor Fix For: 2.0.x Attachments: MAVEN-1468.patch Original Estimate: 5 minutes Remaining Estimate: 5 minutes Maven's mailing list page (http://maven.apache.org/mail-lists.html) currently lists only the user and dev lists. I think it would be more useful for new users if this page listed all maven-related mailing lists (even though some lists belong to sub-projects, such as Wagon and SCM). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2239) Null pointer exception when typo is in plugin name
[ http://jira.codehaus.org/browse/MNG-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2239. -- Resolution: Fixed Fixed. Null pointer exception when typo is in plugin name -- Key: MNG-2239 URL: http://jira.codehaus.org/browse/MNG-2239 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.4 Reporter: Carlos Sanchez Priority: Minor Fix For: 2.0.x Running mvn eclipsE:eclipse $ mvn eclipsE:eclipse [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'eclipsE'. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:292) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:198) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:163) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1252) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1517) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:381) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:135) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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: 1 second [INFO] Finished at: Tue Apr 25 16:32:32 PDT 2006 [INFO] Final Memory: 1M/3M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-1491) Reactor should print out a message if it detects a collision of artifact ids
[ http://jira.codehaus.org/browse/MNG-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1491. -- Resolution: Fixed The new feature in the dependency plugin can do this nicely now. Reactor should print out a message if it detects a collision of artifact ids Key: MNG-1491 URL: http://jira.codehaus.org/browse/MNG-1491 Project: Maven 2 Issue Type: Wish Components: Plugins and Lifecycle Reporter: Anuerin Diaz Priority: Trivial Fix For: 2.0.x It might be a good idea to have the Reactor print out a warning message if it detects similar artifact IDs (copy and paste problem) when scanning for the build order at the start of the build. Currently, there are no messages shown in the screen even if -X is used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2048) Quote args in mvn script
[
http://jira.codehaus.org/browse/MNG-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-2048.
--
Resolution: Duplicate
Dupe and fixed.
Quote args in mvn script
Key: MNG-2048
URL: http://jira.codehaus.org/browse/MNG-2048
Project: Maven 2
Issue Type: Bug
Components: Command Line
Affects Versions: 2.0.2
Environment: Windows XP
Cygwin
Reporter: Dale Wyttenbach
Priority: Minor
Fix For: 2.0.x
The mvn script as distributed does not handle quoted args such as:
m2 -Dgreeting=huh bah hello:sayhi
You get the error:
Invalid task 'bah': you must specify a valid lifecycle phase, or a goal in
the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal
Here is a fix for the mvn script:
*** mvn 2006/02/07 15:58:33 1.1
--- mvn 2006/02/07 15:58:38
***
*** 134,138
-classpath ${M2_HOME}/core/boot/classworlds-*.jar \
-Dclassworlds.conf=${M2_HOME}/bin/m2.conf \
-Dmaven.home=${M2_HOME} \
! ${CLASSWORLDS_LAUNCHER} $@
--- 134,138
-classpath ${M2_HOME}/core/boot/classworlds-*.jar \
-Dclassworlds.conf=${M2_HOME}/bin/m2.conf \
-Dmaven.home=${M2_HOME} \
! ${CLASSWORLDS_LAUNCHER} $@
--
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-310) surefire-reports failes to locate java, returns There are test failures.
surefire-reports failes to locate java, returns There are test failures. -- Key: SUREFIRE-310 URL: http://jira.codehaus.org/browse/SUREFIRE-310 Project: Maven Surefire Issue Type: Bug Components: report plugin Affects Versions: 2.3.1 Environment: Windows, Sun JDK 1.5 u10, environment variables include: JAVA_HOME = C:\Program Files\Java\jdk1_5 Reporter: Steve Lewis Priority: Critical Attachments: execution_error.txt When the JAVA_HOME environment variable includes spaces, surefire-reports execution failes to locate java Partial error below, full error in context is available in attachment. Forking command line: C:\Program Files\Java\jdk1.5.0_10\jre\bin\java -classpath [...] 'C:\Program' is not recognized as an internal or external command, operable program or batch file. [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] This is similar to behavior the gwt-maven plugin experienced a little while back, http://groups.google.com/group/gwt-maven/browse_thread/thread/b8ccf7896b0f65f0/df999ee333246567%23df999ee333246567 WORKAROUNDS: Either changing JAVA_HOME to not use spaces such as c:\progra~1\java\jdk1_5 Explicitly use a previous version of the maven-surefire-plugin such as plugin artifactIdmaven-surefire-plugin/artifactId version2.3/version /plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-1817) Debug System.out statement snuck through
[ http://jira.codehaus.org/browse/MNG-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1817. -- Resolution: Fixed No System.out|err calls in the ant tasks. Debug System.out statement snuck through Key: MNG-1817 URL: http://jira.codehaus.org/browse/MNG-1817 Project: Maven 2 Issue Type: Bug Components: Ant tasks Affects Versions: 2.0.1 Reporter: Eric Andresen Priority: Trivial Fix For: 2.0.x In the maven-artifact-ant tasks, a debug statement snuck through to the final release: Repository.getId() == central This happens in the artifact:dependencies task. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-1875) Cannot deploy artifact with classifier
[ http://jira.codehaus.org/browse/MNG-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1875. -- Resolution: Fixed Dupe and fixed. Cannot deploy artifact with classifier -- Key: MNG-1875 URL: http://jira.codehaus.org/browse/MNG-1875 Project: Maven 2 Issue Type: Bug Reporter: Miguel Griffa Assigned To: Brett Porter Fix For: 2.0.x Intro: I have an artifact I want to deploy with different confs, I use profiles and I want confs to be deployed, so I want somethings like core-1.0.dev.jar core-1.0.-test.jar core-1.0.-prod.jar profiles is the way to go. The problem is how to set the name of the artifact with profiles. simple overwriting finalName does not work, I was told to put the classifier in the version, but this is incorrect, since all jars above should be in 1.0 dir. putting the classifier in verison makes them appear in different version dirs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-1637) Maven bootstrap requires old libraries, like 2.0-beta-3
[ http://jira.codehaus.org/browse/MNG-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1637. -- Resolution: Fixed This is released plugins using older versions of the plugin-api for example that pull in older libraries. Only building entirely from source would prevent this for all plugins needed in the bootstrap. Maven bootstrap requires old libraries, like 2.0-beta-3 --- Key: MNG-1637 URL: http://jira.codehaus.org/browse/MNG-1637 Project: Maven 2 Issue Type: Bug Components: Bootstrap Build Reporter: Brett Porter Fix For: 2.0.x haven't checked where these are pulled from - could be plugins, or a dependency. Need to hunt them down and update them, and should problbay filter them out in the bootstrap. For any library built via the bootstrap, only the newest version should be used. -- 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-1437) Trove 1.1 beta 5
Trove 1.1 beta 5 Key: MAVENUPLOAD-1437 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1437 Project: maven-upload-requests Issue Type: Task Reporter: Eric Redmond Require this version of Trove for Terracotta - figured this would be a good excuse to upload it! -- 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-1889) Plugins without descriptors
[ http://jira.codehaus.org/browse/MNG-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90858 ] Jason van Zyl commented on MNG-1889: Jochen, I now look for your name for patches :-) This one doesn't apply. Could you take another pass and I promise I'll apply it. Plugins without descriptors --- Key: MNG-1889 URL: http://jira.codehaus.org/browse/MNG-1889 Project: Maven 2 Issue Type: Bug Components: Plugin Creation Tools Affects Versions: 2.0.1 Reporter: Jochen Wiedmann Priority: Minor Fix For: 2.0.x Attachments: numMojoDescriptors.patch The attached patch throws an exception, if no Mojos are found in a plugin. Background: If such a plugin is installed, then an NPE is caused in the DefaultLifeCycleExecutor, which properly assumes, that a plugin contains Mojo descriptors. Obviously, the actual error is in the plugin itself, where it should be exposed. It took me some hours to find this actual reason. (I still do not know, why the Mojos aren't found in my plugin, but that's another story.) The patch should be able to save the same number of hours for other plugin developers. Note: The InvalidPluginDescriptorException, which is triggered by the patch, is possibly not proper. I choosed it, because it allowed to leave the method signature unchanged and keep the patch simple. It is up to the reviewer to choose another exception. -- 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: (MSOURCES-13) No-Forking mojos for use within a POM instead of CLI
No-Forking mojos for use within a POM instead of CLI Key: MSOURCES-13 URL: http://jira.codehaus.org/browse/MSOURCES-13 Project: Maven 2.x Sources Plugin Issue Type: Improvement Environment: ALL Reporter: Ben Tatham Attachments: nofork.patch The exiting jar at test-jar mojos will always cause a lifecycle fork and generate-sources. This can cause all kinds of undesired side effects when using the source plugin with a pom, instead of CLI. I propose a simple fix (patch attached) to extend these two mojos in no-forking mode. I can't think of a better name for them. This behaviour is similar to the difference between assembly:assembly and assembly:attached. -- 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: (MSOURCES-13) No-Forking mojos for use within a POM instead of CLI
[ http://jira.codehaus.org/browse/MSOURCES-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Tatham updated MSOURCES-13: --- Attachment: nofork.patch My previous patch was a bit premature. This one actually does what it says. I didn't realize that maven plugin javadoc annotations were inherited! No-Forking mojos for use within a POM instead of CLI Key: MSOURCES-13 URL: http://jira.codehaus.org/browse/MSOURCES-13 Project: Maven 2.x Sources Plugin Issue Type: Improvement Environment: ALL Reporter: Ben Tatham Attachments: nofork.patch, nofork.patch The exiting jar at test-jar mojos will always cause a lifecycle fork and generate-sources. This can cause all kinds of undesired side effects when using the source plugin with a pom, instead of CLI. I propose a simple fix (patch attached) to extend these two mojos in no-forking mode. I can't think of a better name for them. This behaviour is similar to the difference between assembly:assembly and assembly:attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2669) bootstrap of components/trunk fails with ant-1.7.0RC1
[ http://jira.codehaus.org/browse/MNG-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2669. -- Resolution: Fixed We only use it too bootstrap and don't care if it works with every version of Ant. bootstrap of components/trunk fails with ant-1.7.0RC1 - Key: MNG-2669 URL: http://jira.codehaus.org/browse/MNG-2669 Project: Maven 2 Issue Type: Improvement Components: Bootstrap Build Affects Versions: 2.1 Reporter: Alfred Nathaniel Priority: Blocker Bootstrap build of components/trunk with ant-1.7.0RC1 fails. [javac] /home/alfred/apache/maven/components/trunk/maven-artifact-ant/src/main/java/org/apache/maven/artifact/ant/LocalRepository.java:32: getLocation() in org.apache.maven.artifact.ant.LocalRepository cannot override getLocation() in org.apache.tools.ant.ProjectComponent; attempting to use incompatible return type[javac] found : java.io.File [javac] required: org.apache.tools.ant.Location [javac] public File getLocation() [javac] ^ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-1889) Plugins without descriptors
[ http://jira.codehaus.org/browse/MNG-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann updated MNG-1889: - Attachment: maven-no-plugin-descriptors.patch Here's an updated version. Please note, that I had to catch the new exception in the test suite at some point. It mighe be better to remove the final check for size() == 0 in that test. Plugins without descriptors --- Key: MNG-1889 URL: http://jira.codehaus.org/browse/MNG-1889 Project: Maven 2 Issue Type: Bug Components: Plugin Creation Tools Affects Versions: 2.0.1 Reporter: Jochen Wiedmann Priority: Minor Fix For: 2.0.x Attachments: maven-no-plugin-descriptors.patch, numMojoDescriptors.patch The attached patch throws an exception, if no Mojos are found in a plugin. Background: If such a plugin is installed, then an NPE is caused in the DefaultLifeCycleExecutor, which properly assumes, that a plugin contains Mojo descriptors. Obviously, the actual error is in the plugin itself, where it should be exposed. It took me some hours to find this actual reason. (I still do not know, why the Mojos aren't found in my plugin, but that's another story.) The patch should be able to save the same number of hours for other plugin developers. Note: The InvalidPluginDescriptorException, which is triggered by the patch, is possibly not proper. I choosed it, because it allowed to leave the method signature unchanged and keep the patch simple. It is up to the reviewer to choose another exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-50) Add the loader-repository node for jboss configuration
[ http://jira.codehaus.org/browse/MEAR-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90868 ] Greg Jones commented on MEAR-50: It would be nice to get this patch applied and into a SNAPSHOT so that we can use this property rather than having to copy our own jboss-app.xml file as part of the build. Please! Add the loader-repository node for jboss configuration -- Key: MEAR-50 URL: http://jira.codehaus.org/browse/MEAR-50 Project: Maven 2.x Ear Plugin Issue Type: New Feature Affects Versions: 2.3 Reporter: Maurice Zeijen Assigned To: Stephane Nicoll Fix For: 2.4 Attachments: MEAR-50.patch In the jboss-app.xml file it is possible to add a loader-repository node. To complement the jboss configuration in the ear plugin, it should be possible to add this node. -- 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
