[jira] Closed: (CONTINUUM-602) Integrate new Continuum CSS
[ http://jira.codehaus.org/browse/CONTINUUM-602?page=all ] Emmanuel Venisse closed CONTINUUM-602: -- Resolution: Fixed Done. Integrate new Continuum CSS --- Key: CONTINUUM-602 URL: http://jira.codehaus.org/browse/CONTINUUM-602 Project: Continuum Type: Task Components: Web interface Reporter: Emmanuel Venisse Assignee: Emmanuel Venisse Fix For: 1.0.3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[continuum build branches/continuum-1.0.x - SUCCESS - update] Thu Feb 23 22:30:01 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/branches/continuum-1.0.x/continuum-20060223.223001.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060223.223001.txt
[jira] Created: (CONTINUUM-603) Fix date parsing in changeset in buil result screen
Fix date parsing in changeset in buil result screen --- Key: CONTINUUM-603 URL: http://jira.codehaus.org/browse/CONTINUUM-603 Project: Continuum Type: Bug Components: Web interface Reporter: Emmanuel Venisse Assigned to: Emmanuel Venisse Fix For: 1.0.3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-604) Failure to remove working directory when deleteing project on Windows
Failure to remove working directory when deleteing project on Windows - Key: CONTINUUM-604 URL: http://jira.codehaus.org/browse/CONTINUUM-604 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Environment: Windows Server 2003 Reporter: Scott Ryan When I try to delete a project I get the following stack trace ognl.MethodFailedException: Method removeProject failed for object [EMAIL PROTECTED] [org.apache.maven.continuum.ContinuumException: Error while deleting project working directory.] at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:796) at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) at ognl.ASTMethod.getValueBody(ASTMethod.java:75) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) at ognl.SimpleNode.getValue(SimpleNode.java:210) at ognl.Ognl.getValue(Ognl.java:333) at ognl.Ognl.getValue(Ognl.java:378) at ognl.Ognl.getValue(Ognl.java:357) at org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57) at org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47) at org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) at org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) at org.mortbay.http.HttpServer.service(HttpServer.java:879) at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520) /-- Encapsulated exception \ org.apache.maven.continuum.ContinuumException: Error while deleting project working directory. at org.apache.maven.continuum.DefaultContinuum.logAndCreateException(DefaultContinuum.java:1834) at org.apache.maven.continuum.DefaultContinuum.removeProject(DefaultContinuum.java:265) 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:324) at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:491) at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:785) at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) at ognl.ASTMethod.getValueBody(ASTMethod.java:75) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) at ognl.SimpleNode.getValue(SimpleNode.java:210) at ognl.Ognl.getValue(Ognl.java:333) at ognl.Ognl.getValue(Ognl.java:378) at ognl.Ognl.getValue(Ognl.java:357) at org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57) at org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47) at org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) at org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at
[jira] Closed: (CONTINUUM-603) Fix date parsing in changeset in buil result screen
[ http://jira.codehaus.org/browse/CONTINUUM-603?page=all ] Emmanuel Venisse closed CONTINUUM-603: -- Resolution: Fixed Fixed. Fix date parsing in changeset in buil result screen --- Key: CONTINUUM-603 URL: http://jira.codehaus.org/browse/CONTINUUM-603 Project: Continuum Type: Bug Components: Web interface Reporter: Emmanuel Venisse Assignee: Emmanuel Venisse Fix For: 1.0.3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-604) Failure to remove working directory when deleteing project on Windows
[ http://jira.codehaus.org/browse/CONTINUUM-604?page=all ] Scott Ryan closed CONTINUUM-604: Resolution: Fixed It looks like since continuum was running as a service it had locked the directory at the top. A restart and retest with several other projects fixed the issue. Failure to remove working directory when deleteing project on Windows - Key: CONTINUUM-604 URL: http://jira.codehaus.org/browse/CONTINUUM-604 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Environment: Windows Server 2003 Reporter: Scott Ryan When I try to delete a project I get the following stack trace ognl.MethodFailedException: Method removeProject failed for object [EMAIL PROTECTED] [org.apache.maven.continuum.ContinuumException: Error while deleting project working directory.] at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:796) at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) at ognl.ASTMethod.getValueBody(ASTMethod.java:75) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) at ognl.SimpleNode.getValue(SimpleNode.java:210) at ognl.Ognl.getValue(Ognl.java:333) at ognl.Ognl.getValue(Ognl.java:378) at ognl.Ognl.getValue(Ognl.java:357) at org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57) at org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47) at org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) at org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) at org.mortbay.http.HttpServer.service(HttpServer.java:879) at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520) /-- Encapsulated exception \ org.apache.maven.continuum.ContinuumException: Error while deleting project working directory. at org.apache.maven.continuum.DefaultContinuum.logAndCreateException(DefaultContinuum.java:1834) at org.apache.maven.continuum.DefaultContinuum.removeProject(DefaultContinuum.java:265) 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:324) at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:491) at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:785) at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) at ognl.ASTMethod.getValueBody(ASTMethod.java:75) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) at ognl.SimpleNode.getValue(SimpleNode.java:210) at ognl.Ognl.getValue(Ognl.java:333) at ognl.Ognl.getValue(Ognl.java:378) at ognl.Ognl.getValue(Ognl.java:357) at org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57) at org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47) at org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) at org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) at
[continuum build branches/continuum-1.0.x - FAILED - checkout] Fri Feb 24 02:00:01 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060224.020001.txt
[jira] Updated: (CONTINUUM-418) RSS feed for build status
[ http://jira.codehaus.org/browse/CONTINUUM-418?page=all ] John Didion updated CONTINUUM-418: -- Attachment: rss.patch RSS feed for build status - Key: CONTINUUM-418 URL: http://jira.codehaus.org/browse/CONTINUUM-418 Project: Continuum Type: Wish Versions: 1.0 Reporter: David Blevins Priority: Minor Attachments: rss.patch Lyndon Samson suggested on the Geronimo dev list that an rss feed for reporting build status would be a really great way to report build status. A neat application of that feature would be the ability to include continuum data on a confluence page. -- 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: (CONTINUUM-322) Add the possibiliy to be notify after all build
[ http://jira.codehaus.org/browse/CONTINUUM-322?page=all ] John Didion updated CONTINUUM-322: -- Attachment: AbstractContinuumNotifier.diff Add the possibiliy to be notify after all build --- Key: CONTINUUM-322 URL: http://jira.codehaus.org/browse/CONTINUUM-322 Project: Continuum Type: New Feature Versions: 1.0-beta-1 Reporter: Olivier Lamy Priority: Minor Attachments: AbstractContinuumNotifier.diff Is it possible to had the possibility about being notified after all build ? -- 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
[continuum build trunk - SUCCESS - update] Fri Feb 24 03:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/trunk/continuum-20060224.030001.war Log: http://maven.zones.apache.org/~continuum/logs/trunk/continuum-build-log-20060224.030001.txt
[jira] Reopened: (CONTINUUM-604) Failure to remove working directory when deleteing project on Windows
[ http://jira.codehaus.org/browse/CONTINUUM-604?page=all ] Emmanuel Venisse reopened CONTINUUM-604: Failure to remove working directory when deleteing project on Windows - Key: CONTINUUM-604 URL: http://jira.codehaus.org/browse/CONTINUUM-604 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Environment: Windows Server 2003 Reporter: Scott Ryan When I try to delete a project I get the following stack trace ognl.MethodFailedException: Method removeProject failed for object [EMAIL PROTECTED] [org.apache.maven.continuum.ContinuumException: Error while deleting project working directory.] at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:796) at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) at ognl.ASTMethod.getValueBody(ASTMethod.java:75) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) at ognl.SimpleNode.getValue(SimpleNode.java:210) at ognl.Ognl.getValue(Ognl.java:333) at ognl.Ognl.getValue(Ognl.java:378) at ognl.Ognl.getValue(Ognl.java:357) at org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57) at org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47) at org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) at org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) at org.mortbay.http.HttpServer.service(HttpServer.java:879) at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520) /-- Encapsulated exception \ org.apache.maven.continuum.ContinuumException: Error while deleting project working directory. at org.apache.maven.continuum.DefaultContinuum.logAndCreateException(DefaultContinuum.java:1834) at org.apache.maven.continuum.DefaultContinuum.removeProject(DefaultContinuum.java:265) 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:324) at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:491) at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:785) at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) at ognl.ASTMethod.getValueBody(ASTMethod.java:75) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) at ognl.SimpleNode.getValue(SimpleNode.java:210) at ognl.Ognl.getValue(Ognl.java:333) at ognl.Ognl.getValue(Ognl.java:378) at ognl.Ognl.getValue(Ognl.java:357) at org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57) at org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47) at org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) at org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at
[jira] Updated: (CONTINUUM-322) Add the possibiliy to be notify after all build
[ http://jira.codehaus.org/browse/CONTINUUM-322?page=all ] Emmanuel Venisse updated CONTINUUM-322: --- Assign To: Emmanuel Venisse Fix Version: 1.0.3 Add the possibiliy to be notify after all build --- Key: CONTINUUM-322 URL: http://jira.codehaus.org/browse/CONTINUUM-322 Project: Continuum Type: New Feature Versions: 1.0-beta-1 Reporter: Olivier Lamy Assignee: Emmanuel Venisse Priority: Minor Fix For: 1.0.3 Attachments: AbstractContinuumNotifier.diff Is it possible to had the possibility about being notified after all build ? -- 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: (CONTINUUM-604) Failure to remove working directory when deleteing project on Windows
[ http://jira.codehaus.org/browse/CONTINUUM-604?page=all ] Emmanuel Venisse closed CONTINUUM-604: -- Resolution: Cannot Reproduce Failure to remove working directory when deleteing project on Windows - Key: CONTINUUM-604 URL: http://jira.codehaus.org/browse/CONTINUUM-604 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Environment: Windows Server 2003 Reporter: Scott Ryan When I try to delete a project I get the following stack trace ognl.MethodFailedException: Method removeProject failed for object [EMAIL PROTECTED] [org.apache.maven.continuum.ContinuumException: Error while deleting project working directory.] at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:796) at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) at ognl.ASTMethod.getValueBody(ASTMethod.java:75) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) at ognl.SimpleNode.getValue(SimpleNode.java:210) at ognl.Ognl.getValue(Ognl.java:333) at ognl.Ognl.getValue(Ognl.java:378) at ognl.Ognl.getValue(Ognl.java:357) at org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57) at org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47) at org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) at org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) at org.mortbay.http.HttpServer.service(HttpServer.java:879) at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520) /-- Encapsulated exception \ org.apache.maven.continuum.ContinuumException: Error while deleting project working directory. at org.apache.maven.continuum.DefaultContinuum.logAndCreateException(DefaultContinuum.java:1834) at org.apache.maven.continuum.DefaultContinuum.removeProject(DefaultContinuum.java:265) 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:324) at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:491) at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:785) at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) at ognl.ASTMethod.getValueBody(ASTMethod.java:75) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) at ognl.SimpleNode.getValue(SimpleNode.java:210) at ognl.Ognl.getValue(Ognl.java:333) at ognl.Ognl.getValue(Ognl.java:378) at ognl.Ognl.getValue(Ognl.java:357) at org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57) at org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47) at org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) at org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at
[jira] Created: (SCM-167) Check out complains about missing directory.
Check out complains about missing directory. - Key: SCM-167 URL: http://jira.codehaus.org/browse/SCM-167 Project: Maven SCM Type: Bug Components: maven-scm-provider-clearcase Versions: 1.0-beta-2 Environment: Using Continuum 1.0.2 on HP-UX 11 with Java 1.4.2.04 and ClearCase 2003.06.00. Reporter: Fredrik Rubensson When doing a build in Continuum using ClearCase as SCM it fails with the message: Working directory /proj/so/ext/continuum/apps/continuum/working-directory/1/.. does not exist! which is true. Further investigations into the source code (ClearCaseCheckout.java) reveals that the directory in question is removed a couple of lines above the call to clearcase that results in this error. There is even a comment in the code that says that ClearCase need a non-existant directory for this command to work. Maybe this is different for different OSs and/or ClearCase versions? -- 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-165) PerforceChangeLogCommand needs to use the same clientspec as the update command
[ http://jira.codehaus.org/browse/SCM-165?page=comments#action_59326 ] Mike Perham commented on SCM-165: - John, please attach a standard SVN diff. Your diff does not contain the filename headers. svn diff patch.diff PerforceChangeLogCommand needs to use the same clientspec as the update command --- Key: SCM-165 URL: http://jira.codehaus.org/browse/SCM-165 Project: Maven SCM Type: Bug Components: maven-scm-provider-perforce Versions: 1.0-beta-3 Reporter: John Didion Assignee: Mike Perham Priority: Critical Attachments: PerforceChangeLogCommand.diff The PerforceChangeLogCommand as written does not work if the update was done with the client spec generated by the checkout/update command. The attached diff will fix the problem. -- 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] Assigned: (SCM-165) PerforceChangeLogCommand needs to use the same clientspec as the update command
[ http://jira.codehaus.org/browse/SCM-165?page=all ] Mike Perham reassigned SCM-165: --- Assign To: Mike Perham PerforceChangeLogCommand needs to use the same clientspec as the update command --- Key: SCM-165 URL: http://jira.codehaus.org/browse/SCM-165 Project: Maven SCM Type: Bug Components: maven-scm-provider-perforce Versions: 1.0-beta-3 Reporter: John Didion Assignee: Mike Perham Priority: Critical Attachments: PerforceChangeLogCommand.diff The PerforceChangeLogCommand as written does not work if the update was done with the client spec generated by the checkout/update command. The attached diff will fix the problem. -- 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] Resolved: (SCM-163) PerforceUpdateCommand does not correctly return change list
[ http://jira.codehaus.org/browse/SCM-163?page=all ]
Mike Perham resolved SCM-163:
-
Resolution: Fixed
PerforceUpdateCommand does not correctly return change list
---
Key: SCM-163
URL: http://jira.codehaus.org/browse/SCM-163
Project: Maven SCM
Type: Bug
Components: maven-scm-provider-perforce
Versions: 1.0-beta-3
Reporter: John Didion
Assignee: Mike Perham
Priority: Critical
We are trying to use continuum to build our project, which resides in a p4
repository. Continuum relies on the changelist from scm update to determine
whether or not to kick off a build. PerforceUpdateCommand uses
UpdateScmResult.setChanges() to set the change list, when it should actually
be setting the updatedFiles property. The AbstractUpdateCommand only looks
at updatedFiles when creating the change list (see ~ line 54).
If you look at the update commands for any other provider you will see that
they do this. I'm not sure why the p4 one is different.
The code should be:
{noformat}
if (!cosr.isSuccess()) {
new UpdateScmResult(
cosr.getCommandLine(),
cosr.getProviderMessage(),
cosr.getCommandOutput(),
false);
}
return new UpdateScmResult(
cosr.getCommandLine(), cosr.getCheckedOutFiles() );
{noformat}
If, for some reason, the UpdateScmResult for p4 must have the message and
output set, then you'll need to add a setter for updatedFiles and call that
instead of setChanges().
--
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-163) PerforceUpdateCommand does not correctly return change list
[ http://jira.codehaus.org/browse/SCM-163?page=comments#action_59327 ]
Mike Perham commented on SCM-163:
-
Thanks for tracking this down, John. The code was written before the changelog
command was well defined.
PerforceUpdateCommand does not correctly return change list
---
Key: SCM-163
URL: http://jira.codehaus.org/browse/SCM-163
Project: Maven SCM
Type: Bug
Components: maven-scm-provider-perforce
Versions: 1.0-beta-3
Reporter: John Didion
Assignee: Mike Perham
Priority: Critical
We are trying to use continuum to build our project, which resides in a p4
repository. Continuum relies on the changelist from scm update to determine
whether or not to kick off a build. PerforceUpdateCommand uses
UpdateScmResult.setChanges() to set the change list, when it should actually
be setting the updatedFiles property. The AbstractUpdateCommand only looks
at updatedFiles when creating the change list (see ~ line 54).
If you look at the update commands for any other provider you will see that
they do this. I'm not sure why the p4 one is different.
The code should be:
{noformat}
if (!cosr.isSuccess()) {
new UpdateScmResult(
cosr.getCommandLine(),
cosr.getProviderMessage(),
cosr.getCommandOutput(),
false);
}
return new UpdateScmResult(
cosr.getCommandLine(), cosr.getCheckedOutFiles() );
{noformat}
If, for some reason, the UpdateScmResult for p4 must have the message and
output set, then you'll need to add a setter for updatedFiles and call that
instead of setChanges().
--
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-139) Create a utility class for scm url checking/parsing
[ http://jira.codehaus.org/browse/SCM-139?page=comments#action_59343 ] Dennis Lundberg commented on SCM-139: - Do you mean duplicated code in the new files that I created or in the files that are already a part of maven-scm? Create a utility class for scm url checking/parsing --- Key: SCM-139 URL: http://jira.codehaus.org/browse/SCM-139 Project: Maven SCM Type: New Feature Components: maven-scm-api Reporter: Dennis Lundberg Attachments: SCM-139-2.zip, SCM-139.zip, ScmUrlUtils.java There is a lot of code in different places, both in maven-scm and elsewhere, that checks and parses scm url:s. I propose that a utility class ScmUrlUtils be crated in maven-scm-api where such code (static methods) can be placed. The code there should not be scm provider specific. This should be accompanied by a test suite. This concept might also be applied to individual scm providers, e.g. there could be a CvsScmUrlUtils in maven-scm-provider-cvs. -- 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-165) PerforceChangeLogCommand needs to use the same clientspec as the update command
[ http://jira.codehaus.org/browse/SCM-165?page=comments#action_59346 ] John Didion commented on SCM-165: - I can't get svn diff to workit can't find the source file when I point it at the tagged version, and when I try to specify the revision (?rev=...) it complains about the URL formatting. PerforceChangeLogCommand needs to use the same clientspec as the update command --- Key: SCM-165 URL: http://jira.codehaus.org/browse/SCM-165 Project: Maven SCM Type: Bug Components: maven-scm-provider-perforce Versions: 1.0-beta-3 Reporter: John Didion Assignee: Mike Perham Priority: Critical Attachments: PerforceChangeLogCommand.diff The PerforceChangeLogCommand as written does not work if the update was done with the client spec generated by the checkout/update command. The attached diff will fix the problem. -- 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-165) PerforceChangeLogCommand needs to use the same clientspec as the update command
[ http://jira.codehaus.org/browse/SCM-165?page=all ] John Didion updated SCM-165: Attachment: svn.diff PerforceChangeLogCommand needs to use the same clientspec as the update command --- Key: SCM-165 URL: http://jira.codehaus.org/browse/SCM-165 Project: Maven SCM Type: Bug Components: maven-scm-provider-perforce Versions: 1.0-beta-3 Reporter: John Didion Assignee: Mike Perham Priority: Critical Attachments: PerforceChangeLogCommand.diff, svn.diff The PerforceChangeLogCommand as written does not work if the update was done with the client spec generated by the checkout/update command. The attached diff will fix the problem. -- 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-553) Secure Storage of Server Passwords
[ http://jira.codehaus.org/browse/MNG-553?page=all ] Brett Porter updated MNG-553: - Priority: Critical (was: Minor) Complexity: Expert upgrading priority for 2.1 release. Secure Storage of Server Passwords -- Key: MNG-553 URL: http://jira.codehaus.org/browse/MNG-553 Project: Maven 2 Type: Improvement Versions: 2.0-alpha-3 Environment: Although it may not be relevant since this is a general improvement issue, Windows XP, JDK 1.4.1. Reporter: J. Michael McGarr Priority: Critical Fix For: 2.1 This was a question pose to the Maven User's Group and it was suggested I add it here. It would be benefitial to provide a more secure means of storing password's to the servers listed in the .m2/settings.xml. They are currently being stored as plain text and could definately be considered a security breach. Numerous organizations would undoubtedly considered this an unacceptable security risk, and this could prevent widespread adoption of Maven2. I would suggest leaving an option to encrypt the password into the settings file (more secure, but not foolproof) or even requiring the password to be manually provided per build (would prevent automation of builds). I am sure that there is a secure solution to this problem and it should be part of the 2.0 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2105) Enable remote debugging command line option (+ docs)
Enable remote debugging command line option (+ docs) Key: MNG-2105 URL: http://jira.codehaus.org/browse/MNG-2105 Project: Maven 2 Type: New Feature Components: Command Line Versions: 2.0.2 Reporter: Geoffrey De Smet Priority: Minor [dev list mailing reference: Debugging maven with breakpoints feed-back: --jdwp + docs] Problem: Currently its hard to enable remote debugging for a remote debugger of your IDE. Basically you need to set MAVEN_OPTS something like: export MAVEN_OPTS=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000 mvn ... and unset it again. Solution: 1) Make it easier, choices: A) Provide a command line option to do this (--debug is already taken for debug logging), choices: a) mvn --jdpa b) mvn --jdwp B) Provide a different script: mvnDebug to avoid parsing command line arguments in bat and shell C) Find a generic way to give options on the command, like -mx etc to the java process, possibly by namespacing them? 2) Document it in mvn --help 3) Document it on http://maven.apache.org/guides/development/guide-m2-development.html like so (APT): Debugging with breakpoints You can attach a remote debugger of your IDE to the maven process. This will allow you to set breakpoints (line, exception, ...). Start maven in debugger mode on port 8000: +-- mvn ??? install +-- If you want to change any of the debugger settings, use MAVEN_OPTS instead. Then connect to the correct port with a remote debugger in your IDE. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Debugging maven with breakpoints feed-back: --jdwp + docs
Brett Porter wrote: I've thought about this in the past, but have always opted to go for setting MAVEN_OPTS (which I have in a separate little script). I'd be fine with adding this argument, but parsing the command line arguments (especially in the .bat file) can be a bit of a pain. Would someone like to put it in JIRA? Done :) http://jira.codehaus.org/browse/MNG-2105 - Brett Brian E. Fox wrote: +1! -Original Message- From: Vincent Siveton [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 22, 2006 7:49 AM To: Maven Developers List Subject: Re: Debugging maven with breakpoints feed-back: --jdwp + docs Geoffrey, I like it! I prefer more --jdpa rather than --jpwd (Think about geronimo or tomcat) What do others think? Vincent 2006/2/22, Geoffrey De Smet [EMAIL PROTECTED]: I just used my first debug breakpoint in maven 2 to fix the jasperreports plugin: export MAVEN_OPTS=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000 mvn phase-on-my-project Still, this is a bit unhandy and it took me quite a while to find out. So here's my 2 cents feed-back: 1) Some sort of mvn --jdwp (mvn --debug is already taken for debug logging). If it's already there, please document in mvn --help. 2) Document how to do this with a short APT, for example in http://maven.apache.org/guides/development/guide-m2-development.html like so (APT): Debugging with breakpoints You can attach a remote debugger of your IDE to the maven process. This will allow you to set breakpoints (line, exception, ...). Start maven in debugger mode on port 8000: +-- mvn --jdwp +-- If you want to change any of the debugger settings, use MAVEN_OPTS instead. Then connect to it with a remote debugger in your IDE. -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with the site plugin
Hello Where is the site:stage goal you are talking about? What is it for? I've been looking for it in components/trunk/maven-core/src/main/resources/... but not found. Greg - Original Message - From: Vincent Siveton [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Wednesday, February 22, 2006 1:16 PM Subject: Re: Problems with the site plugin I think that the next release should be in March (according plugin statuses). Cheers, Vincent 2006/2/21, Prasad Kashyap [EMAIL PROTECTED]: Sorry Brett. Will keep that in mind in the future. Issue 2 is not actually a issue. It was a user-error. Vincent, as for the site:stage goal, do you know approx when it may be available in a release ? Cheers Prasad On 2/21/06, Vincent Siveton [EMAIL PROTECTED] wrote: The site:stage goal only exists in the trunk http://jira.codehaus.org/browse/MSITE-92 Cheers Vincent 2006/2/21, Prasad Kashyap [EMAIL PROTECTED]: Can someone please let me know if the following issues are as designed or bugs that need a JIRA ? 1. The site:stage goal of the maven-site-plugin has disappeared in the 2.0-beta-4 version. 2. The post-site phase doesn't work. I have a simple antrun that echoes a msg.. It executes in the site phase but doesn't in the post-site phase. http://cvs.peopleware.be/training/maven/maven2/buildLifecyclePhases.html#site Cheers Prasad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.15.12/266 - Release Date: 2006-02-21 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-301) relocate xerces:xerces or xerces:xercesImpl
[ http://jira.codehaus.org/browse/MEV-301?page=comments#action_59295 ] Edwin Punzalan commented on MEV-301: Relocation created. Thanks. NOTE: May take up to 4 hours for the fix to reach central repo. relocate xerces:xerces or xerces:xercesImpl --- Key: MEV-301 URL: http://jira.codehaus.org/browse/MEV-301 Project: Maven Evangelism Type: Bug Reporter: fabrizio giustina Assignee: Edwin Punzalan At the moment xerces jars are distributed both with the xerces and xercesImpl artifact id. Jars are identical, at the moment some versions are in xerces, other in xercesImpl and some in both. For example the following are the same artifact: http://www.ibiblio.org/maven2/xerces/xerces/2.0.2/ http://www.ibiblio.org/maven2/xerces/xercesImpl/2.0.2/ xerces:xercesImpl should be relocated to xerces:xerces and all the jars should be moved there. At the moment the duplicate artifact name often causes two copies of xerces to be included due to transitive dependencies resolution. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPJAR-53) [JarSignMojo] Verification of a signed jar fails
[JarSignMojo] Verification of a signed jar fails Key: MPJAR-53 URL: http://jira.codehaus.org/browse/MPJAR-53 Project: maven-jar-plugin Type: Bug Environment: Linux Slackware 10.1, JDK 1.4.2_02 Reporter: Pawel Pastula Priority: Blocker When verification is executed there is no way the verification can succeed since if uses unsigned jar file instead of signedjar file: verify.setJarPath( getJarFile() ); in JarSignMojo.java:182. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-2103) Inheritance of plugin overrides that of execution
[ http://jira.codehaus.org/browse/MNG-2103?page=all ] Yann Le Du updated MNG-2103: Attachment: test-inheritance-true.zip Inheritance of plugin overrides that of execution - Key: MNG-2103 URL: http://jira.codehaus.org/browse/MNG-2103 Project: Maven 2 Type: Bug Reporter: Prasad Kashyap Attachments: test-inheritance-true.zip, test-inheritance.zip The inherited settings of plugin overrides that of it's execution By convention, all top level configuration settings are usually overridden by the settings in the lower levels. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (MJAR-32) [JarSignMojo] Verification of a signed jar fails
[ http://jira.codehaus.org/browse/MJAR-32?page=all ] Arnaud Heritier moved MPJAR-53 to MJAR-32: -- Workflow: Maven (was: jira) Key: MJAR-32 (was: MPJAR-53) Project: Maven 2.x Jar Plugin (was: maven-jar-plugin) [JarSignMojo] Verification of a signed jar fails Key: MJAR-32 URL: http://jira.codehaus.org/browse/MJAR-32 Project: Maven 2.x Jar Plugin Type: Bug Environment: Linux Slackware 10.1, JDK 1.4.2_02 Reporter: Pawel Pastula Priority: Blocker When verification is executed there is no way the verification can succeed since if uses unsigned jar file instead of signedjar file: verify.setJarPath( getJarFile() ); in JarSignMojo.java:182. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MDEPLOY-7) deploy plugin leaves unnecessary information in the deployed pom.xml
[ http://jira.codehaus.org/browse/MDEPLOY-7?page=all ] Allan Ramirez closed MDEPLOY-7: --- Resolution: Fixed I closed this issue because it seems to me that it is already deploying an uninherited, uninjected, uninterpolated POM to the remote repository deploy plugin leaves unnecessary information in the deployed pom.xml Key: MDEPLOY-7 URL: http://jira.codehaus.org/browse/MDEPLOY-7 Project: Maven 2.x Deploy Plugin Type: Bug Reporter: Jorg Heymans Assignee: Allan Ramirez ideally, during deployment, the deployed pom should be stripped of elements like build and distributionManagement IRC log : jorg Can someone enlighten me here : when i deploy an artifact (m2), why does the deployed plugin contain the build and distributionmanagement elements ? jorg s/plugin/artifact/ jorg surely these elements are only relevant to the deployer ? jesse in the pom that is in the jar? jorg no the one that is deployed alongside the jar jorg shall I jira this ? jesse hm, I think that is a bug similar to the one with stuff in the META-INF/maven file too jorg yeah that's what i figured too jesse might as well bug it jdcasey jorg: we're not cleaning up that pom at all, just sending it on...but it's a good point jorg jdcasey: you mean about the maven version ? jdcasey I mean about the build/distributionManagement stuff...or anything that makes it into the POM that's deployed jorg oh ok , yup i think the pom should be stripped of anything not dependency related jorg i'm using deploy plugin v2.0 jdcasey I think I agree that it should be stripped of the functional parts of the POM, but not the informational stuff...it will allow us to make a richer map of project info if we leave that stuff in jorg jdcasey: yes thinking of it that's what i meant .. anything build or deploy related can go jdcasey don't ask *how this got here, it just did. ;-) jorg hehe exactly -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MECLIPSE-37) eclipse:eclipse should execute in a later phase than generate-sources
[ http://jira.codehaus.org/browse/MECLIPSE-37?page=comments#action_59300 ] Mark Hobson commented on MECLIPSE-37: - This change impairs the use of eclipse:eclipse somewhat for the reasons detailed by Kenney above - would it not be better for the average user to revert back to generate-resources whilst the design issues are resolved? eclipse:eclipse should execute in a later phase than generate-sources --- Key: MECLIPSE-37 URL: http://jira.codehaus.org/browse/MECLIPSE-37 Project: Maven 2.x Eclipse Plugin Type: Bug Versions: 2.0 Reporter: Mark Donszelmann Assignee: fabrizio giustina the eclipse:eclipse goal should run in a later phase than it currently does (generate-sources) as user defined plugins may add to the compileSourceRoots and testCompileSourceRoots. If it runs later, added paths will be written correctly to the .classpath. Suggested phase is test -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MRM-41) discover standalone POMs
[ http://jira.codehaus.org/browse/MRM-41?page=all ] John Tolentino updated MRM-41: -- Attachment: MRM-41-maven-repository-discovery.diff discover standalone POMs Key: MRM-41 URL: http://jira.codehaus.org/browse/MRM-41 Project: Maven Repository Manager Type: Task Components: discovery Reporter: Brett Porter Assignee: John Tolentino Fix For: 1.0-alpha-1 Attachments: MRM-41-maven-repository-discovery.diff, MRM-41-maven-repository-discovery.diff, MRM-41-maven-repository-discovery.diff, repository-manager.diff Time Spent: 18 hours Remaining: 0 minutes where the pom is the artifact -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Debugging maven with breakpoints feed-back: --jdwp + docs
Hi I just copied mvn.bat to mvnd.bat (d = debug), added set MAVEN_OPTS=... line and that's all. You can do the same in maven-core sources. Greg - Original Message - From: Brett Porter [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Wednesday, February 22, 2006 10:41 PM Subject: Re: Debugging maven with breakpoints feed-back: --jdwp + docs I've thought about this in the past, but have always opted to go for setting MAVEN_OPTS (which I have in a separate little script). I'd be fine with adding this argument, but parsing the command line arguments (especially in the .bat file) can be a bit of a pain. Would someone like to put it in JIRA? - Brett Brian E. Fox wrote: +1! -Original Message- From: Vincent Siveton [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 22, 2006 7:49 AM To: Maven Developers List Subject: Re: Debugging maven with breakpoints feed-back: --jdwp + docs Geoffrey, I like it! I prefer more --jdpa rather than --jpwd (Think about geronimo or tomcat) What do others think? Vincent 2006/2/22, Geoffrey De Smet [EMAIL PROTECTED]: I just used my first debug breakpoint in maven 2 to fix the jasperreports plugin: export MAVEN_OPTS=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000 mvn phase-on-my-project Still, this is a bit unhandy and it took me quite a while to find out. So here's my 2 cents feed-back: 1) Some sort of mvn --jdwp (mvn --debug is already taken for debug logging). If it's already there, please document in mvn --help. 2) Document how to do this with a short APT, for example in http://maven.apache.org/guides/development/guide-m2-development.html like so (APT): Debugging with breakpoints You can attach a remote debugger of your IDE to the maven process. This will allow you to set breakpoints (line, exception, ...). Start maven in debugger mode on port 8000: +-- mvn --jdwp +-- If you want to change any of the debugger settings, use MAVEN_OPTS instead. Then connect to it with a remote debugger in your IDE. -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.15.12/266 - Release Date: 2006-02-21 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MJAR-32) [JarSignMojo] Verification of a signed jar fails
[ http://jira.codehaus.org/browse/MJAR-32?page=comments#action_59309 ] Jerome Lacoste commented on MJAR-32: Working on it... [JarSignMojo] Verification of a signed jar fails Key: MJAR-32 URL: http://jira.codehaus.org/browse/MJAR-32 Project: Maven 2.x Jar Plugin Type: Bug Environment: Linux Slackware 10.1, JDK 1.4.2_02 Reporter: Pawel Pastula Priority: Blocker When verification is executed there is no way the verification can succeed since if uses unsigned jar file instead of signedjar file: verify.setJarPath( getJarFile() ); in JarSignMojo.java:182. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with the site plugin
Grzegorz, It is a new feature in the site plugin. http://jira.codehaus.org/browse/MSITE-54 Cheers, Vincent 2006/2/23, Grzegorz Slowikowski [EMAIL PROTECTED]: Hello Where is the site:stage goal you are talking about? What is it for? I've been looking for it in components/trunk/maven-core/src/main/resources/... but not found. Greg - Original Message - From: Vincent Siveton [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Wednesday, February 22, 2006 1:16 PM Subject: Re: Problems with the site plugin I think that the next release should be in March (according plugin statuses). Cheers, Vincent 2006/2/21, Prasad Kashyap [EMAIL PROTECTED]: Sorry Brett. Will keep that in mind in the future. Issue 2 is not actually a issue. It was a user-error. Vincent, as for the site:stage goal, do you know approx when it may be available in a release ? Cheers Prasad On 2/21/06, Vincent Siveton [EMAIL PROTECTED] wrote: The site:stage goal only exists in the trunk http://jira.codehaus.org/browse/MSITE-92 Cheers Vincent 2006/2/21, Prasad Kashyap [EMAIL PROTECTED]: Can someone please let me know if the following issues are as designed or bugs that need a JIRA ? 1. The site:stage goal of the maven-site-plugin has disappeared in the 2.0-beta-4 version. 2. The post-site phase doesn't work. I have a simple antrun that echoes a msg.. It executes in the site phase but doesn't in the post-site phase. http://cvs.peopleware.be/training/maven/maven2/buildLifecyclePhases.html#site Cheers Prasad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.15.12/266 - Release Date: 2006-02-21 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-343) Missing po for tomcat:jaster-runtime:5.5.15
Missing po for tomcat:jaster-runtime:5.5.15 --- Key: MEV-343 URL: http://jira.codehaus.org/browse/MEV-343 Project: Maven Evangelism Type: Bug Reporter: Grzegorz Slowikowski Missing POM. Just copy from 5.5.12 and change version number. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-344) Missing pom for tomcat:jasper-compiler:5.5.15
Missing pom for tomcat:jasper-compiler:5.5.15 - Key: MEV-344 URL: http://jira.codehaus.org/browse/MEV-344 Project: Maven Evangelism Type: Bug Components: Missing POM Reporter: Grzegorz Slowikowski Missing POM. Just copy from 5.5.12 and change version number. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MJAR-32) [JarSignMojo] Verification of a signed jar fails
[ http://jira.codehaus.org/browse/MJAR-32?page=all ] Jerome Lacoste updated MJAR-32: --- Attachment: MJAR-32.diff [JarSignMojo] Verification of a signed jar fails Key: MJAR-32 URL: http://jira.codehaus.org/browse/MJAR-32 Project: Maven 2.x Jar Plugin Type: Bug Environment: Linux Slackware 10.1, JDK 1.4.2_02 Reporter: Pawel Pastula Priority: Blocker Attachments: MJAR-32.diff When verification is executed there is no way the verification can succeed since if uses unsigned jar file instead of signedjar file: verify.setJarPath( getJarFile() ); in JarSignMojo.java:182. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-719) New Plugin - buildinfo (buildnumber and buildclass)
[ http://jira.codehaus.org/browse/MNG-719?page=comments#action_59313 ] Geoffrey De Smet commented on MNG-719: -- It would be nice if it also includes the scm revision number (if the scm supports a revision number, like SVN, not CVS): http://commons.ucalgary.ca/projects/maven-buildnumber-plugin/ does this (see user list topic getting subversion revision number) New Plugin - buildinfo (buildnumber and buildclass) --- Key: MNG-719 URL: http://jira.codehaus.org/browse/MNG-719 Project: Maven 2 Type: New Feature Versions: 2.0-beta-1 Environment: n/a Reporter: Joakim Erdfelt Priority: Minor Attachments: maven-buildinfo-plugin.tar.gz After discussion in #maven, it seemed that this plugin could be of use by the general population. It manages the buildnumber for a specific project, and even can produce an (optional) buildclass. example setup. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-buildinfo-plugin/artifactId version1.0-alpha-1-SNAPSHOT/version configuration infofile.buildinfo/infofile classnameorg.codehaus.modello.plugins.dom4j.BuildInfo/classname /configuration executions execution goals goalbuildnumber/goal goalbuildclass/goal /goals /execution /executions /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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-742) Please upload maven-qalab-plugin
[ http://jira.codehaus.org/browse/MAVENUPLOAD-742?page=all ] Dave Sag updated MAVENUPLOAD-742: - Attachment: maven-qalab-plugin-2.0-bundle.jar Please upload maven-qalab-plugin Key: MAVENUPLOAD-742 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-742 Project: maven-upload-requests Type: Task Reporter: Dave Sag Attachments: maven-qalab-plugin-2.0-bundle.jar, maven-qalab-plugin-2.0-bundle.jar, qalab-patch.diff this plugin provides the basic merge and movers mojos and main and movers reports taking input from checkstyle, PMD and findbugs and reporting statistical quality data over the life of the project. it's a reworking of the maven 1 plugin for maven 2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-742) Please upload maven-qalab-plugin
[ http://jira.codehaus.org/browse/MAVENUPLOAD-742?page=comments#action_59316 ] Dave Sag commented on MAVENUPLOAD-742: -- i have not checked this latest change into CVS as i have not got access to sourceforge's cvs from in here. i don't treally want to check it in with hard coded references to this temporary repository you asked for. Please upload maven-qalab-plugin Key: MAVENUPLOAD-742 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-742 Project: maven-upload-requests Type: Task Reporter: Dave Sag Attachments: maven-qalab-plugin-2.0-bundle.jar, maven-qalab-plugin-2.0-bundle.jar, qalab-patch.diff this plugin provides the basic merge and movers mojos and main and movers reports taking input from checkstyle, PMD and findbugs and reporting statistical quality data over the life of the project. it's a reworking of the maven 1 plugin for maven 2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPCHANGELOG-83) NPE error if developer's id is missing
NPE error if developer's id is missing -- Key: MPCHANGELOG-83 URL: http://jira.codehaus.org/browse/MPCHANGELOG-83 Project: maven-changelog-plugin Type: Bug Versions: 1.9 Environment: tested on Linux, fecora core 3, Maven 1.1.beta2 Reporter: mike niemaz Priority: Minor If you forget to specify a developer id in project.xml, the changelog plugin will generates a dirty NullPointerException such as: Unable to obtain goal [site] -- /home/xxx/.maven/cache/maven-changelog-plugin-1.9/plugin.jelly:148:15: changelog:changelog null -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-345) POM for dom4j-1.4-dev-8 is invalid
POM for dom4j-1.4-dev-8 is invalid -- Key: MEV-345 URL: http://jira.codehaus.org/browse/MEV-345 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Michael Mattox I get this error: [WARNING] POM for 'dom4j:dom4j:pom:1.4-dev-8' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: TEXT must be imme diately followed by END_TAG and not START_TAG (position: START_TAG seen ...arti factIdjunitartifactId... @47:36) but what I don't understand is that when I look at line 47 of this file: groupIdjunit/groupId IT'S CORRECT!!! Something really weird is going on here. I don't have any mirrors defined so I have no idea what it is. The solution for me was to copy these files exactly as-is from ibiblio to our local repository and it works. Very strange. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-346) xpp3 filename invalid
xpp3 filename invalid - Key: MEV-346 URL: http://jira.codehaus.org/browse/MEV-346 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Michael Mattox The filename contains -RC8_min which doesn't match the version # in the directory -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MECLIPSE-37) eclipse:eclipse should execute in a later phase than generate-sources
[ http://jira.codehaus.org/browse/MECLIPSE-37?page=comments#action_59318 ] Alexandre Poitras commented on MECLIPSE-37: --- I don't like the eclipse:eclipse goal to be automatically linked to a phase, because I can't generate my projets when the source code doesn't compile. How about not giving one by default but give the option to specify it in the plugin configuration section. eclipse:eclipse should execute in a later phase than generate-sources --- Key: MECLIPSE-37 URL: http://jira.codehaus.org/browse/MECLIPSE-37 Project: Maven 2.x Eclipse Plugin Type: Bug Versions: 2.0 Reporter: Mark Donszelmann Assignee: fabrizio giustina the eclipse:eclipse goal should run in a later phase than it currently does (generate-sources) as user defined plugins may add to the compileSourceRoots and testCompileSourceRoots. If it runs later, added paths will be written correctly to the .classpath. Suggested phase is test -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-346) xpp3 filename invalid
[ http://jira.codehaus.org/browse/MEV-346?page=comments#action_59319 ] Joerg Schaible commented on MEV-346: You cannot find such a version anyways on xpp3's home. Use 1.1.3.4.O and either xpp3 or xpp3_min as artifactId. Both are available at ibiblio. xpp3 filename invalid - Key: MEV-346 URL: http://jira.codehaus.org/browse/MEV-346 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Michael Mattox The filename contains -RC8_min which doesn't match the version # in the directory -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MJAR-32) [JarSignMojo] Verification of a signed jar fails
[ http://jira.codehaus.org/browse/MJAR-32?page=comments#action_59321 ] Pawel Pastula commented on MJAR-32: --- After applying your patch, some tests fail. To be precise it's: testVerifyInPlaceSignedJar when you invoke: mojo.setSignedJar( null ); you will get NPE in JarSignMojo.java:221: addArgIfNotEmpty( arguments, -signedjar, this.signedjar.getPath() ); Here is the solution to this problem: addArgIfNotEmpty( arguments, -signedjar, this.signedjar != null ? this.signedjar.getPath() : null ); I didn't attach a patch since I don't know to which revision this patch should be applied. [JarSignMojo] Verification of a signed jar fails Key: MJAR-32 URL: http://jira.codehaus.org/browse/MJAR-32 Project: Maven 2.x Jar Plugin Type: Bug Environment: Linux Slackware 10.1, JDK 1.4.2_02 Reporter: Pawel Pastula Priority: Blocker Attachments: MJAR-32.diff When verification is executed there is no way the verification can succeed since if uses unsigned jar file instead of signedjar file: verify.setJarPath( getJarFile() ); in JarSignMojo.java:182. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-346) xpp3 filename invalid
[ http://jira.codehaus.org/browse/MEV-346?page=comments#action_59322 ] Michael Mattox commented on MEV-346: yep I got it working with 1.1.3.4.O (that's a letter O not a number, weird naming system). I hope they implement some kind of method to prevent people from deploying invalid POM's. And I hope they fix the problem where that breaks the entire maven build. xpp3 filename invalid - Key: MEV-346 URL: http://jira.codehaus.org/browse/MEV-346 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Michael Mattox The filename contains -RC8_min which doesn't match the version # in the directory -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SCM-166) Failed discovery of clearcase-settings.xml
Failed discovery of clearcase-settings.xml -- Key: SCM-166 URL: http://jira.codehaus.org/browse/SCM-166 Project: Maven SCM Type: Bug Components: maven-scm-provider-clearcase Versions: 1.0-beta-2 Environment: With Continuum 1.0.2 on HP-UX 11 and Java 1.4.2.04 Reporter: Fredrik Rubensson Priority: Minor The system property user.dir points to the current working directory on HP-UX Java clone. This makes the discovery of clearcase-settings.xml in ~/.scm to fail. Work around it so pass the property on to the virtual machine on the command line. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-32) [JarSignMojo] Verification of a signed jar fails
[ http://jira.codehaus.org/browse/MJAR-32?page=comments#action_59324 ] Pawel Pastula commented on MJAR-32: --- There is also one thing I forgot in my last comment. To enable in-place jar signing, the field signedjar must not be @requiered. Right now tests are working fine but there is no way to do it in practise. I had removed @requiered attribute and have been struggling with pom.xml to make it work. The default-value makes it difficult to set null value. I don't know maven2 well but if there is no way to set this plugin's attribute to null then I think signedjar should be String not java.io.File. I tried: signedjar/ and thoutht it could set signedjar to null - but the default value is set I also tried: signedjar implementation=java.io.Filenull/signedjar but creates File(null) :-) How can one set this field to null to enable in-place jar signing ? [JarSignMojo] Verification of a signed jar fails Key: MJAR-32 URL: http://jira.codehaus.org/browse/MJAR-32 Project: Maven 2.x Jar Plugin Type: Bug Environment: Linux Slackware 10.1, JDK 1.4.2_02 Reporter: Pawel Pastula Priority: Blocker Attachments: MJAR-32.diff When verification is executed there is no way the verification can succeed since if uses unsigned jar file instead of signedjar file: verify.setJarPath( getJarFile() ); in JarSignMojo.java:182. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPCHANGELOG-83) NPE error if developer's id is missing
[ http://jira.codehaus.org/browse/MPCHANGELOG-83?page=all ] mike niemaz updated MPCHANGELOG-83: --- Attachment: stack.txt NPE error if developer's id is missing -- Key: MPCHANGELOG-83 URL: http://jira.codehaus.org/browse/MPCHANGELOG-83 Project: maven-changelog-plugin Type: Bug Versions: 1.9 Environment: tested on Linux, fecora core 3, Maven 1.1.beta2 Reporter: mike niemaz Priority: Minor Attachments: stack.txt If you forget to specify a developer id in project.xml, the changelog plugin will generates a dirty NullPointerException such as: Unable to obtain goal [site] -- /home/xxx/.maven/cache/maven-changelog-plugin-1.9/plugin.jelly:148:15: changelog:changelog null -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven article
I'd be interested to read it too. -j [EMAIL PROTECTED] wrote: Hi, I worte an article about Maven for Dr. Dobbs. I would like to get some feedback. The article is a text file with several code listings and tables. Please let me know if I should just attach an archive of everything or separate files or just mail it directly to interested parties. Thanks, Gigi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2054) Multiple Inheritence causes plugin executions to run multiple times (Test Case Attached)
[ http://jira.codehaus.org/browse/MNG-2054?page=comments#action_59328 ]
Brian Fox commented on MNG-2054:
I verified in my sample and in my real project that this appears to be fixed in
2.0.3. The fixed version should be updated so that the JIRA report reflects the
correct information. I'd like to see this get created as an integration test to
prevent future regresion, but I'm not 100% sure how to test for this condition.
Multiple Inheritence causes plugin executions to run multiple times (Test
Case Attached)
Key: MNG-2054
URL: http://jira.codehaus.org/browse/MNG-2054
Project: Maven 2
Type: Bug
Components: Inheritence and Interpolation
Versions: 2.0.2
Environment: WinXp
Reporter: Brian Fox
Priority: Critical
Fix For: 2.0.4
Attachments: sample.zip
See the attached sample. If a plugin execution is set in a parent of a
parent, when the child is built from either aggregator, the plugin execution
runs multiple times. In my sample, I set the sources to be generated, but
when run, see that the sources are generated and installed 2x.
[INFO] Building jar:
E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-tests.jar
[INFO] [install:install]
[INFO] Installing
E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT.jar to
f:\mavenRepo\sampl
e-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT.jar
[INFO] Installing
E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-sources.jar
to f:\mavenRe
po\sample-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT-sources.jar
[INFO] Installing
E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-sources.jar
to f:\mavenRe
po\sample-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT-sources.jar
[INFO] Installing
E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-tests.jar
to f:\mavenRepo
\sample-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT-tests.jar
[INFO]
If run directly from the child build, the sources are only built 1x:
[INFO] [jar:jar]
[INFO] Building jar:
E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT.jar
[INFO] [source:jar {execution: attach-source}]
[INFO] Building jar:
E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-sources.jar
[INFO] [jar:test-jar {execution: default}]
[INFO] Building jar:
E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-tests.jar
[INFO] [install:install]
[INFO] Installing
E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT.jar to
f:\mavenRepo\sampl
e-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT.jar
[INFO] Installing
E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-sources.jar
to f:\mavenRe
po\sample-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT-sources.jar
[INFO] Installing
E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-tests.jar
to f:\mavenRepo
\sample-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT-tests.jar
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1958) we need a var that always points to the root direcotry in multi module builds
[ http://jira.codehaus.org/browse/MNG-1958?page=comments#action_59330 ]
Prasad Kashyap commented on MNG-1958:
-
Oh, I'm waiting for something like this too. This seems like an absolute
necessity.
we need a var that always points to the root direcotry in multi module builds
-
Key: MNG-1958
URL: http://jira.codehaus.org/browse/MNG-1958
Project: Maven 2
Type: Improvement
Reporter: Mark Proctor
Fix For: 2.1
${basedir} always points to the local module. There are cases, when having a
local relative repository, when it would be usefull to have a var that always
pointed to the root project, ${rootdir}.
In such a case you may want to think of having the names ${rootdir}
${moduledir}
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-346) xpp3 filename invalid
[ http://jira.codehaus.org/browse/MEV-346?page=all ] Carlos Sanchez closed MEV-346: -- Assign To: Carlos Sanchez Resolution: Won't Fix It can be used with classifier. Anyway as said before better use the one ending in O xpp3 filename invalid - Key: MEV-346 URL: http://jira.codehaus.org/browse/MEV-346 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Michael Mattox Assignee: Carlos Sanchez The filename contains -RC8_min which doesn't match the version # in the directory -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-346) xpp3 filename invalid
[ http://jira.codehaus.org/browse/MEV-346?page=comments#action_59335 ] Michael Mattox commented on MEV-346: That's not the point of this issue, the point is there is a version deployed to ibiblio which is invalid. I thought fixing it would only take a few seconds (less time than to debate this) and would save someone from getting stuck and having problems. xpp3 filename invalid - Key: MEV-346 URL: http://jira.codehaus.org/browse/MEV-346 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Michael Mattox Assignee: Carlos Sanchez The filename contains -RC8_min which doesn't match the version # in the directory -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPCHANGELOG-83) NPE error if developer's id is missing
[ http://jira.codehaus.org/browse/MPCHANGELOG-83?page=all ] Lukas Theussl updated MPCHANGELOG-83: - Fix Version: 1.9.1 NPE error if developer's id is missing -- Key: MPCHANGELOG-83 URL: http://jira.codehaus.org/browse/MPCHANGELOG-83 Project: maven-changelog-plugin Type: Bug Versions: 1.9 Environment: tested on Linux, fecora core 3, Maven 1.1.beta2 Reporter: mike niemaz Priority: Minor Fix For: 1.9.1 Attachments: stack.txt If you forget to specify a developer id in project.xml, the changelog plugin will generates a dirty NullPointerException such as: Unable to obtain goal [site] -- /home/xxx/.maven/cache/maven-changelog-plugin-1.9/plugin.jelly:148:15: changelog:changelog null -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-345) POM for dom4j-1.4-dev-8 is invalid
[ http://jira.codehaus.org/browse/MEV-345?page=all ] Carlos Sanchez closed MEV-345: -- Assign To: Carlos Sanchez Resolution: Cannot Reproduce I think you had an old version, deleting it in your local repo should fix it POM for dom4j-1.4-dev-8 is invalid -- Key: MEV-345 URL: http://jira.codehaus.org/browse/MEV-345 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Michael Mattox Assignee: Carlos Sanchez I get this error: [WARNING] POM for 'dom4j:dom4j:pom:1.4-dev-8' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: TEXT must be imme diately followed by END_TAG and not START_TAG (position: START_TAG seen ...arti factIdjunitartifactId... @47:36) but what I don't understand is that when I look at line 47 of this file: groupIdjunit/groupId IT'S CORRECT!!! Something really weird is going on here. I don't have any mirrors defined so I have no idea what it is. The solution for me was to copy these files exactly as-is from ibiblio to our local repository and it works. Very strange. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-344) Missing pom for tomcat:jasper-compiler:5.5.15
[ http://jira.codehaus.org/browse/MEV-344?page=all ] Carlos Sanchez closed MEV-344: -- Assign To: Carlos Sanchez Resolution: Won't Fix We don't generate empty poms. If you know what the dependencies are you can submit the pom. Missing pom for tomcat:jasper-compiler:5.5.15 - Key: MEV-344 URL: http://jira.codehaus.org/browse/MEV-344 Project: Maven Evangelism Type: Bug Components: Missing POM Reporter: Grzegorz Slowikowski Assignee: Carlos Sanchez Missing POM. Just copy from 5.5.12 and change version number. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-343) Missing po for tomcat:jaster-runtime:5.5.15
[ http://jira.codehaus.org/browse/MEV-343?page=all ] Carlos Sanchez closed MEV-343: -- Assign To: Carlos Sanchez Resolution: Won't Fix We don't generate empty poms. If you know what the dependencies are you can submit the pom. Missing po for tomcat:jaster-runtime:5.5.15 --- Key: MEV-343 URL: http://jira.codehaus.org/browse/MEV-343 Project: Maven Evangelism Type: Bug Reporter: Grzegorz Slowikowski Assignee: Carlos Sanchez Missing POM. Just copy from 5.5.12 and change version number. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-346) xpp3 filename invalid
[ http://jira.codehaus.org/browse/MEV-346?page=comments#action_59339 ] Carlos Sanchez commented on MEV-346: As I said before it's not necessarily wrong, you can use it by specifying classifier RC8_min xpp3 filename invalid - Key: MEV-346 URL: http://jira.codehaus.org/browse/MEV-346 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Michael Mattox Assignee: Carlos Sanchez The filename contains -RC8_min which doesn't match the version # in the directory -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPASPECTJ-15) Add property that define output folder for aspectj:compile goal.
[ http://jira.codehaus.org/browse/MPASPECTJ-15?page=all ] Lukas Theussl updated MPASPECTJ-15: --- Fix Version: (was: 3.3) 4.0 Add property that define output folder for aspectj:compile goal. Key: MPASPECTJ-15 URL: http://jira.codehaus.org/browse/MPASPECTJ-15 Project: maven-aspectj-plugin Type: Improvement Versions: 3.2 Reporter: Alexey Dashkevich Fix For: 4.0 Attachments: aspectj-patch-dash-20041203.zip, aspectj-test-case-dash-20041203.zip, aspectj.mpaspectj15.patch, mpaspectj-15.txt, patch.txt It will be good to have property for destination folder for compiled sources. It will be very helpful when you have aspects only for unit tests and don't wont to have weaved classes in classes folder. I propose to use property with name maven.aspectj.dest that by default will set to maven.build.dest. I have attached patch where added proposed property and test case that use this property. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPASPECTJ-14) Unable to weave only sources defined in argument files. Error during compilation if argument file contains file from sourceDirectory.
[ http://jira.codehaus.org/browse/MPASPECTJ-14?page=all ]
Lukas Theussl updated MPASPECTJ-14:
---
Fix Version: (was: 3.3)
4.0
Unable to weave only sources defined in argument files. Error during
compilation if argument file contains file from sourceDirectory.
-
Key: MPASPECTJ-14
URL: http://jira.codehaus.org/browse/MPASPECTJ-14
Project: maven-aspectj-plugin
Type: Bug
Versions: 3.2
Reporter: Alexey Dashkevich
Fix For: 4.0
Attachments: aspectj-patch-dash-20041130.zip,
aspectj-test-case-dash-20041130.zip, aspectj.mpaspectj14.patch, patch.txt
Some days ago I have started to use aspectj plugin for compilation
aspects. I use aspects only for tests. I have following structure in
project:
-src
|
aspectj - aspect sources
|
java - application sources
|
test - test sources
I have an lst file where defined what files should be compiled with
aspects e.g.:
com/toplinkmapping/UserRoleAspect.java
../java/com/toplinkmapping/UserRole.java
I want compile only files that defined in lst file and place classes
into test-classes folder. In project.properties I have defined
following properties:
maven.aspectj.source=1.4
maven.aspectj.argfiles=src/aspectj/aspects.lst
But when I have executed aspectj:compile I have error because this
task try to compile files from aspects.lst file and then from src/java
folder. And error occur because in aspects.lst defined files from java source
folder.
I have resolved this problem in my maven.xml by following way:
postGoal name=test:compile
ant:path id=build.dest location=${maven.build.dest}/
maven:addPath id=maven.dependency.classpath refid=build.dest/
ant:path id=maven.compile.src.set/
attainGoal name=aspectj:compile/
/postGoal
So as you can see I have overwrite maven.compile.src.set path that
not so good.
I think it will be good if will be introduced new property
like maven.aspectj.src.argfilesOnly that if true then only sources that
defined in argument files will be weaved. And following changes in plugin
script are needed e.g.:
from
ant:sourceroots
ant:path refid=${sourcePathRefid}/
j:if test=${aspectSourcesPresent and weaveAspectSources}
ant:pathelement location=${pom.build.aspectSourceDirectory}/
/j:if
/ant:sourceroots
to
ant:sourceroots
j:if test=${context.getVariable('maven.aspectj.src.argfilesOnly')
!= 'true'}
ant:path refid=${sourcePathRefid}/
/j:if
j:if test=${aspectSourcesPresent and weaveAspectSources}
ant:pathelement location=${pom.build.aspectSourceDirectory}/
/j:if
/ant:sourceroots
I have attached patch and test case for it. Please, take a look at them.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPASPECTJ-16) aspectj:compile also compiles java files in CVS/Base
[ http://jira.codehaus.org/browse/MPASPECTJ-16?page=all ]
Lukas Theussl updated MPASPECTJ-16:
---
Fix Version: (was: 3.3)
4.0
aspectj:compile also compiles java files in CVS/Base
Key: MPASPECTJ-16
URL: http://jira.codehaus.org/browse/MPASPECTJ-16
Project: maven-aspectj-plugin
Type: Bug
Versions: 3.2
Reporter: Brian Jacobsen
Priority: Minor
Fix For: 4.0
When using the aspect:compile goal we receive a lot of errors, because the
jelly plugin also tries to compile java sources in CVC/Base directory.
---
xxx\CVS\Base\Yyy.java:82 error The constructor ZzzException(String,
NamingException) is undefined
throw new ZzzException(test, e);
xxx\CVS\Base\zzzException.java:6 error The type zzzException is already
defined
public class ZzzException extends Exception {
---
Suggested fix:
Use ant:srcdir instead of ant:sourceroots or make it possible to specify the
preferred behaviour with a property.
!--
ant:sourceroots
ant:path refid=${sourcePathRefid}/
j:if test=${aspectSourcesPresent and weaveAspectSources}
ant:pathelement location=${pom.build.aspectSourceDirectory}/
/j:if
/ant:sourceroots
--
ant:srcdir
ant:path refid=${sourcePathRefid}/
j:if test=${aspectSourcesPresent and weaveAspectSources}
ant:pathelement location=${pom.build.aspectSourceDirectory}/
/j:if
/ant:srcdir
Or perhaps it is possible to bypass the problem in another way?
regards
Brian
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPASPECTJ-23) Report for the plugin
[ http://jira.codehaus.org/browse/MPASPECTJ-23?page=all ] Lukas Theussl updated MPASPECTJ-23: --- Fix Version: (was: 3.3) 4.0 Report for the plugin - Key: MPASPECTJ-23 URL: http://jira.codehaus.org/browse/MPASPECTJ-23 Project: maven-aspectj-plugin Type: Wish Reporter: Shinobu Kawai Yoshida Priority: Trivial Fix For: 4.0 Attachments: MPASPECTJ-23.patch, MPASPECTJ-23.xdocs.patch It would be great if there was a report feature to the 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPASPECTJ-24) failonerror support
[ http://jira.codehaus.org/browse/MPASPECTJ-24?page=all ] Lukas Theussl updated MPASPECTJ-24: --- Fix Version: (was: 3.3) 4.0 failonerror support --- Key: MPASPECTJ-24 URL: http://jira.codehaus.org/browse/MPASPECTJ-24 Project: maven-aspectj-plugin Type: Wish Versions: 3.2 Reporter: Shinobu Kawai Yoshida Assignee: Carlos Sanchez Priority: Minor Fix For: 4.0 Attachments: MPASPECTJ-24-xdocs.patch, MPASPECTJ-24.patch It would be great if the plugin supported the failonerror attribute. cf. http://www.eclipse.org/aspectj/doc/released/devguide/antTasks-iajc.html#d0e1506 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MPASPECTJ-24) failonerror support
[ http://jira.codehaus.org/browse/MPASPECTJ-24?page=all ] Lukas Theussl reopened MPASPECTJ-24: failonerror support --- Key: MPASPECTJ-24 URL: http://jira.codehaus.org/browse/MPASPECTJ-24 Project: maven-aspectj-plugin Type: Wish Versions: 3.2 Reporter: Shinobu Kawai Yoshida Assignee: Carlos Sanchez Priority: Minor Fix For: 4.0 Attachments: MPASPECTJ-24-xdocs.patch, MPASPECTJ-24.patch It would be great if the plugin supported the failonerror attribute. cf. http://www.eclipse.org/aspectj/doc/released/devguide/antTasks-iajc.html#d0e1506 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MPASPECTJ-19) Add messageHolderClass property
[ http://jira.codehaus.org/browse/MPASPECTJ-19?page=all ] Lukas Theussl reopened MPASPECTJ-19: Add messageHolderClass property --- Key: MPASPECTJ-19 URL: http://jira.codehaus.org/browse/MPASPECTJ-19 Project: maven-aspectj-plugin Type: Improvement Versions: 3.2 Reporter: Matt Smith Fix For: 4.0 Attachments: MPASPECTJ-19-2.txt, MPASPECTJ-19.txt from the iajc ant task documentation: Specify a class to use as the message holder for the compile process. The entry must be a fully-qualified name of a class resolveable from the task classpath complying with the org.aspectj.bridge.IMessageHolder interface and having a public no-argument constructor. Adding the ability to use a messageHolderClass requires two changes: 1) add maven.aspectj.messageHolderClass property and associated attribute messageHolderClass 2) add maven.dependency.classpath to the ant task def Please see the attached file -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MPASPECTJ-17) Update to aspectj 1.2.1
[ http://jira.codehaus.org/browse/MPASPECTJ-17?page=all ] Lukas Theussl reopened MPASPECTJ-17: Update to aspectj 1.2.1 --- Key: MPASPECTJ-17 URL: http://jira.codehaus.org/browse/MPASPECTJ-17 Project: maven-aspectj-plugin Type: Bug Versions: 3.2 Reporter: stephane bouchet Assignee: Carlos Sanchez Priority: Minor Fix For: 4.0 When using aspectj plugin with the last aspectjrt jar, there is a warning saying the expected version is 1.2. I am using the jar overriding mechanism, and my aspectjrt.jar version is 1.2.1. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPASPECTJ-17) Update to aspectj 1.2.1
[ http://jira.codehaus.org/browse/MPASPECTJ-17?page=all ] Lukas Theussl updated MPASPECTJ-17: --- Fix Version: (was: 3.3) 4.0 Update to aspectj 1.2.1 --- Key: MPASPECTJ-17 URL: http://jira.codehaus.org/browse/MPASPECTJ-17 Project: maven-aspectj-plugin Type: Bug Versions: 3.2 Reporter: stephane bouchet Assignee: Carlos Sanchez Priority: Minor Fix For: 4.0 When using aspectj plugin with the last aspectjrt jar, there is a warning saying the expected version is 1.2. I am using the jar overriding mechanism, and my aspectjrt.jar version is 1.2.1. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPASPECTJ-19) Add messageHolderClass property
[ http://jira.codehaus.org/browse/MPASPECTJ-19?page=all ] Lukas Theussl updated MPASPECTJ-19: --- Fix Version: (was: 3.3) 4.0 Add messageHolderClass property --- Key: MPASPECTJ-19 URL: http://jira.codehaus.org/browse/MPASPECTJ-19 Project: maven-aspectj-plugin Type: Improvement Versions: 3.2 Reporter: Matt Smith Fix For: 4.0 Attachments: MPASPECTJ-19-2.txt, MPASPECTJ-19.txt from the iajc ant task documentation: Specify a class to use as the message holder for the compile process. The entry must be a fully-qualified name of a class resolveable from the task classpath complying with the org.aspectj.bridge.IMessageHolder interface and having a public no-argument constructor. Adding the ability to use a messageHolderClass requires two changes: 1) add maven.aspectj.messageHolderClass property and associated attribute messageHolderClass 2) add maven.dependency.classpath to the ant task def Please see the attached file -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MASSEMBLY-69) dependencies configuration element in assembly:unpack plugin read-only
[ http://jira.codehaus.org/browse/MASSEMBLY-69?page=all ] Prasad Kashyap closed MASSEMBLY-69: --- Resolution: Duplicate The functionality is available in dependency-maven-plugin. This issue may be closed. dependencies configuration element in assembly:unpack plugin read-only - Key: MASSEMBLY-69 URL: http://jira.codehaus.org/browse/MASSEMBLY-69 Project: Maven 2.x Assembly Plugin Type: Bug Reporter: Prasad Kashyap Attachments: MASSEMBLY-69.patch The dependencies configuration element in the maven-assembly-plugin is set to read-only but the documentation on it say it's optional. The assembly:unpack goal currently unpacks all dependencies specified in the project. If this optional element was not read-only, it would be useful to specify just those dependencies that needed to be unpacked. http://maven.apache.org/plugins/maven-assembly-plugin/unpack-mojo.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MPASPECTJ-20) aspectj:compile bug when using jdk 1.5
[ http://jira.codehaus.org/browse/MPASPECTJ-20?page=all ] Lukas Theussl reopened MPASPECTJ-20: aspectj:compile bug when using jdk 1.5 -- Key: MPASPECTJ-20 URL: http://jira.codehaus.org/browse/MPASPECTJ-20 Project: maven-aspectj-plugin Type: Improvement Versions: 3.2 Reporter: stephane bouchet Assignee: Carlos Sanchez Fix For: 4.0 When using a jdk1.5 version and trying to weave classes, when using StringBuffer in source code, aspectj cannot compile the source code. The only solution is to download the last version of aspectj ( 1.5.0 ) from eclipse web site and change the jars in the .maven/repository/aspectj/jars folder. Now i have a warning saying that my version of aspectj is not 1.2 but 1.5 but i can compile without errors. So is it possible to update the aspectj jars to the 1.5.0 version ?? Stéphane -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPASPECTJ-20) aspectj:compile bug when using jdk 1.5
[ http://jira.codehaus.org/browse/MPASPECTJ-20?page=all ] Lukas Theussl closed MPASPECTJ-20: -- Resolution: Fixed aspectj:compile bug when using jdk 1.5 -- Key: MPASPECTJ-20 URL: http://jira.codehaus.org/browse/MPASPECTJ-20 Project: maven-aspectj-plugin Type: Improvement Versions: 3.2 Reporter: stephane bouchet Assignee: Carlos Sanchez Fix For: 4.0 When using a jdk1.5 version and trying to weave classes, when using StringBuffer in source code, aspectj cannot compile the source code. The only solution is to download the last version of aspectj ( 1.5.0 ) from eclipse web site and change the jars in the .maven/repository/aspectj/jars folder. Now i have a warning saying that my version of aspectj is not 1.2 but 1.5 but i can compile without errors. So is it possible to update the aspectj jars to the 1.5.0 version ?? Stéphane -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plugin testing
updating this thread again
Jason and I talked over the above idea and he took a few minutes and put
together the basic jist of the concept and shoved it into the mojo-sandbox
so I could work with it.
mojo-sandbox/maven-plugin-testing/maven-plugin-testing-harness
that has version 1.0-SNAPSHOT of the AbstractMojoTestCase which is what the
test cases can subclass from to get the ability to dynamically load the mojo
based on an arbitary pom.
I modified the maven-clean-plugin again to make use of this and it turned
out quite well I'd say.
/**
* tests the ability of the plugin to clean out a set of directories
*
* @throws Exception
*/
public void testClean() throws Exception {
CleanMojo mojo = (CleanMojo) lookupMojo (clean, testPom );
assertNotNull( mojo );
mojo.execute();
assertFalse ( FileUtils.fileExists(
target/test/testDirectoryStructure/buildDirectory ) );
assertFalse ( FileUtils.fileExists(
target/test/testDirectoryStructure/buildOutputDirectory ) );
assertFalse ( FileUtils.fileExists(
target/test/testDirectoryStructure/buildTestDirectory ) );
}
This method in the CleanMojoTest class coupled with this pom.xml @
src/test/resources/unit/clean/pom.xml execute the unit test very easily.
project
build
plugins
plugin
artifactIdmaven-clean-plugin/artifactId
configuration
directorytarget/test/testDirectoryStructure/buildDirectory/directory
outputDirectorytarget/test/testDirectoryStructure/buildOutputDirectory/outputDirectory
testOutputDirectorytarget/test/testDirectoryStructure/buildTestDirectory/testOutputDirectory
/configuration
/plugin
/plugins
/build
/project
I am going to take this approach and work on testing another plugin in maven
now, get a couple of plugins under my belt with this and the abstract base
class ought to be pretty tight.
jesse
--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom
Re: [vote] Release Maven 2.0.3
Don't want to be annoying, but I'd be really happy if anyone could upgrade WAGONSSH-36 to blocker. This is the last big remaining issue for us (and our customers). Nightly site deployments with Continuum are made impossible by this one! +1 I tested it with our full product build and it appears to work well. I would like to see WAGONSSH-36 fixed if possible - the fix is so trivial I don't know why it hasn't been integrated already. I'm also looking forward to the upcoming site and cobertura releases! -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 21, 2006 10:07 PM To: Maven Developers List Subject: [vote] Release Maven 2.0.3 Hi, I think it's time to release Maven 2.0.3. This release will incorporate 21 resolved JIRA issues, including some critical fixes for Continuum and users of the embedder. The full listing of fixes can be found here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleNa me=Htmlversion=12107 The remaining open issues are reminders for the site publishing process which should accompany this binary release. If you're interested, you can take the current release candidate for a test drive. The RC tarball is at: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-2006 0222.031501.tar.gz I'll leave the vote open for the customary 72 hours before summarizing. Please cast your vote as: [ ] +1 Yes, release [ ] 0 No opinion [ ] -1 No, don't release Here's my +1. Cheers, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Giniality AG - Michael Böckling; Steinenberg 21, CH-4051 Basel P: +41 61 226 99 63 - F: +41 61 226 99 69 [EMAIL PROTECTED]; http://www.giniality.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.0.3
I've fixed this issue in SVN, and will test it more throughly using my Mac tonight or tomorrow. If I can, I will release wagon-ssh-1.0-alpha-7 and modify Maven to depend on this new version prior to the 2.0.3 release. -john Michael Böckling wrote: I usually don't add my 2 cents to this, but I do hope that maven-2.0.3 includes the fix for WAGONSSH-36 (not MNG, I know, but since it comes bundled...). For CI, this is certainly a blocker! Regards, Michael On Wed, 22 Feb 2006, Stephane Nicoll wrote: +1, with 2 comments: 1) no earth shaking fixes.. why not wait a bit longer? 2) it might be nice if 2.0.3 included these: http://jira.codehaus.org/browse/MNG-1317 (mvn.bat doesn't work on win2k/xp) (and possibly this one: http://jira.codehaus.org/browse/MNG-1415 (fix quoted args for *nix) ) -- Kenney +1 On 2/22/06, John Casey [EMAIL PROTECTED] wrote: Hi, I think it's time to release Maven 2.0.3. This release will incorporate 21 resolved JIRA issues, including some critical fixes for Continuum and users of the embedder. The full listing of fixes can be found here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=12107 The remaining open issues are reminders for the site publishing process which should accompany this binary release. If you're interested, you can take the current release candidate for a test drive. The RC tarball is at: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060222.031501.tar.gz I'll leave the vote open for the customary 72 hours before summarizing. Please cast your vote as: [ ] +1 Yes, release [ ] 0 No opinion [ ] -1 No, don't release Here's my +1. Cheers, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .::You're welcome ::. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-754) new version to upload, groupId=org.tango-project artifactId=tango-icon-theme version=0.7.0
new version to upload, groupId=org.tango-project artifactId=tango-icon-theme version=0.7.0 -- Key: MAVENUPLOAD-754 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-754 Project: maven-upload-requests Type: Task Reporter: Michael Heuer The Tango Desktop Project exists to create a consistent user experience for free and Open Source software with graphical user interfaces. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote] Release maven-deploy-plugin 2.2
Hi, Allan Ramirez has been good enough to fix the remaining bugs filed against the maven-deploy-plugin. I think it's ready for a 2.2 release. This release will include fixes to address: * documentation * interpolated POM information making its way into the remote repository * deploy-file with a classifier * option to skip installation of an artifact in the local repo when using deploy-file mojo * deploy-file when install-file was previously executed for the same artifact Customary terms for the vote: +1/0/-1, 72h Here's my +1. Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-346) xpp3 filename invalid
[ http://jira.codehaus.org/browse/MEV-346?page=comments#action_59351 ] Michael Mattox commented on MEV-346: Sorry, didn't know about maven classifiers. Must be new for 2.0. xpp3 filename invalid - Key: MEV-346 URL: http://jira.codehaus.org/browse/MEV-346 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Michael Mattox Assignee: Carlos Sanchez The filename contains -RC8_min which doesn't match the version # in the directory -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-345) POM for dom4j-1.4-dev-8 is invalid
[ http://jira.codehaus.org/browse/MEV-345?page=comments#action_59352 ] Michael Mattox commented on MEV-345: I didn't think of that. It must have been invalid a month or so ago when I downloaded it for the first time. I wish maven would have given more information like where it was getting the pom. Thanks for the analysis. POM for dom4j-1.4-dev-8 is invalid -- Key: MEV-345 URL: http://jira.codehaus.org/browse/MEV-345 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Michael Mattox Assignee: Carlos Sanchez I get this error: [WARNING] POM for 'dom4j:dom4j:pom:1.4-dev-8' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: TEXT must be imme diately followed by END_TAG and not START_TAG (position: START_TAG seen ...arti factIdjunitartifactId... @47:36) but what I don't understand is that when I look at line 47 of this file: groupIdjunit/groupId IT'S CORRECT!!! Something really weird is going on here. I don't have any mirrors defined so I have no idea what it is. The solution for me was to copy these files exactly as-is from ibiblio to our local repository and it works. Very strange. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What are the defaults in report generation ?
reporting has a excludeDefaults element under it. What exactly are the defaults ? I thought they are the issue-tracking, license, team etc that's generated by default. I don't want my submodules in a multi-project build to generate this set of html files over and over again. How can I prevent them from doing so ? I have the following section in every one of my submodule. reporting excludeDefaultstrue/excludeDefaults /reporting But it doesn't seem to make a difference. In fact, having this in the top level pom also doesn't seem to make a difference. Those htmls are always created. So either my understanding of defaults is wrong or this doesn't work. If these are indeed the default reports, then it would also be nice if the reporting elemnt had a inherited under it. Cheers Prasad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-346) xpp3 filename invalid
[ http://jira.codehaus.org/browse/MEV-346?page=comments#action_59354 ] Wayne Fay commented on MEV-346: --- I actually opened a similar bug on this same issue the other day. Didn't know about the classifier either, at least not at the time... This works btw: dependency groupIdxpp3/groupId artifactIdxpp3/artifactId version1.1.3.4/version classifierRC8_min/classifier scopecompile/scope /dependency xpp3 filename invalid - Key: MEV-346 URL: http://jira.codehaus.org/browse/MEV-346 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Michael Mattox Assignee: Carlos Sanchez The filename contains -RC8_min which doesn't match the version # in the directory -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2099) Anchors in http://maven.apache.org/maven-model/maven.html are broken
[ http://jira.codehaus.org/browse/MNG-2099?page=comments#action_59355 ] Yann Le Du commented on MNG-2099: - I've noticed the same thing in FAQs, e.g. http://maven.apache.org/general.html Am I wrong or is it a problem with FML ? There is no # for name in HTML specs : http://www.w3.org/TR/html4/struct/links.html#edef-A Anchors in http://maven.apache.org/maven-model/maven.html are broken Key: MNG-2099 URL: http://jira.codehaus.org/browse/MNG-2099 Project: Maven 2 Type: Bug Components: Documentation: General Versions: 2.0.2 Reporter: Yann Le Du Priority: Minor Anchors in http://maven.apache.org/maven-model/maven.html should be (e.g.) : a name=class_project instead of a name=#class_project -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release maven-deploy-plugin 2.2
+1 Emmanuel John Casey a écrit : Hi, Allan Ramirez has been good enough to fix the remaining bugs filed against the maven-deploy-plugin. I think it's ready for a 2.2 release. This release will include fixes to address: * documentation * interpolated POM information making its way into the remote repository * deploy-file with a classifier * option to skip installation of an artifact in the local repo when using deploy-file mojo * deploy-file when install-file was previously executed for the same artifact Customary terms for the vote: +1/0/-1, 72h Here's my +1. Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What are the defaults in report generation ?
The defaults are what is in the project info menu. There was a bug in 2.0.2 that causes the value not to be inherited. Fixed in 2.0.3. Not sure why putting it in all the child projects didn't help, though. - Brett Prasad Kashyap wrote: reporting has a excludeDefaults element under it. What exactly are the defaults ? I thought they are the issue-tracking, license, team etc that's generated by default. I don't want my submodules in a multi-project build to generate this set of html files over and over again. How can I prevent them from doing so ? I have the following section in every one of my submodule. reporting excludeDefaultstrue/excludeDefaults /reporting But it doesn't seem to make a difference. In fact, having this in the top level pom also doesn't seem to make a difference. Those htmls are always created. So either my understanding of defaults is wrong or this doesn't work. If these are indeed the default reports, then it would also be nice if the reporting elemnt had a inherited under it. Cheers Prasad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release maven-deploy-plugin 2.2
John Casey wrote: * interpolated POM information making its way into the remote repository This was not fixed in the deploy plugin. It's because the release plugin no longer does it. * option to skip installation of an artifact in the local repo when using deploy-file mojo This was not changed, just documented. * deploy-file when install-file was previously executed for the same artifact Shouldn't this read deploy-file failed when deploying the from local repository? (MDEPLOY-21). Is there a reason most of the JIRA issues fixed are not on the roadmap for 2.2? Here's my +1. Regardless of the above, the release is sound. +1. We just need to get JIRA up to date. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2099) Anchors in http://maven.apache.org/maven-model/maven.html are broken
[ http://jira.codehaus.org/browse/MNG-2099?page=comments#action_59361 ] Emmanuel Venisse commented on MNG-2099: --- it's a pb with XhtmlSink in achor method Anchors in http://maven.apache.org/maven-model/maven.html are broken Key: MNG-2099 URL: http://jira.codehaus.org/browse/MNG-2099 Project: Maven 2 Type: Bug Components: Documentation: General Versions: 2.0.2 Reporter: Yann Le Du Priority: Minor Anchors in http://maven.apache.org/maven-model/maven.html should be (e.g.) : a name=class_project instead of a name=#class_project -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release maven-deploy-plugin 2.2
+1 John Casey wrote: Hi, Allan Ramirez has been good enough to fix the remaining bugs filed against the maven-deploy-plugin. I think it's ready for a 2.2 release. This release will include fixes to address: * documentation * interpolated POM information making its way into the remote repository * deploy-file with a classifier * option to skip installation of an artifact in the local repo when using deploy-file mojo * deploy-file when install-file was previously executed for the same artifact Customary terms for the vote: +1/0/-1, 72h Here's my +1. Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-2099) Anchors in http://maven.apache.org/maven-model/maven.html are broken
[ http://jira.codehaus.org/browse/MNG-2099?page=comments#action_59362 ] Yann Le Du commented on MNG-2099: - I don't get the problem with doxia trunk - anchors are correct. Maybe it's already corrected ?? Would it solve http://maven.apache.org/maven-model/maven.html also ? (I don't know how this page is generated from model) Anchors in http://maven.apache.org/maven-model/maven.html are broken Key: MNG-2099 URL: http://jira.codehaus.org/browse/MNG-2099 Project: Maven 2 Type: Bug Components: Documentation: General Versions: 2.0.2 Reporter: Yann Le Du Priority: Minor Anchors in http://maven.apache.org/maven-model/maven.html should be (e.g.) : a name=class_project instead of a name=#class_project -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build branches/continuum-1.0.x - SUCCESS - update] Thu Feb 23 23:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/branches/continuum-1.0.x/continuum-20060223.233000.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060223.233000.txt
[maven2 build trunk - SUCCESS - checkout] Fri Feb 24 00:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060224.01.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060224.01.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONTINUUM-604) Failure to remove working directory when deleteing project on Windows
[ http://jira.codehaus.org/browse/CONTINUUM-604?page=comments#action_59365 ] Emmanuel Venisse commented on CONTINUUM-604: do you have try to delete your project during a build or with a file open in this directory or with a dos console open in this directory? It's generally what's happen on windows Failure to remove working directory when deleteing project on Windows - Key: CONTINUUM-604 URL: http://jira.codehaus.org/browse/CONTINUUM-604 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Environment: Windows Server 2003 Reporter: Scott Ryan When I try to delete a project I get the following stack trace ognl.MethodFailedException: Method removeProject failed for object [EMAIL PROTECTED] [org.apache.maven.continuum.ContinuumException: Error while deleting project working directory.] at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:796) at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) at ognl.ASTMethod.getValueBody(ASTMethod.java:75) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) at ognl.SimpleNode.getValue(SimpleNode.java:210) at ognl.Ognl.getValue(Ognl.java:333) at ognl.Ognl.getValue(Ognl.java:378) at ognl.Ognl.getValue(Ognl.java:357) at org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57) at org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47) at org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) at org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) at org.mortbay.http.HttpServer.service(HttpServer.java:879) at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520) /-- Encapsulated exception \ org.apache.maven.continuum.ContinuumException: Error while deleting project working directory. at org.apache.maven.continuum.DefaultContinuum.logAndCreateException(DefaultContinuum.java:1834) at org.apache.maven.continuum.DefaultContinuum.removeProject(DefaultContinuum.java:265) 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:324) at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:491) at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:785) at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) at ognl.ASTMethod.getValueBody(ASTMethod.java:75) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) at ognl.SimpleNode.getValue(SimpleNode.java:210) at ognl.Ognl.getValue(Ognl.java:333) at ognl.Ognl.getValue(Ognl.java:378) at ognl.Ognl.getValue(Ognl.java:357) at org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57) at org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47) at org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) at org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) at
[maven2 build branches/maven-2.0.x - SUCCESS - checkout] Fri Feb 24 00:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060224.003001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060224.003001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build branches/continuum-1.0.x - SUCCESS - update] Fri Feb 24 00:30:01 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/branches/continuum-1.0.x/continuum-20060224.003001.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060224.003001.txt
[jira] Closed: (MRM-41) discover standalone POMs
[ http://jira.codehaus.org/browse/MRM-41?page=all ] Edwin Punzalan closed MRM-41: - Resolution: Fixed Patch applied. Thanks. discover standalone POMs Key: MRM-41 URL: http://jira.codehaus.org/browse/MRM-41 Project: Maven Repository Manager Type: Task Components: discovery Reporter: Brett Porter Assignee: John Tolentino Fix For: 1.0-alpha-1 Attachments: MRM-41-maven-repository-discovery.diff, MRM-41-maven-repository-discovery.diff, MRM-41-maven-repository-discovery.diff, repository-manager.diff Time Spent: 21 hours Remaining: 0 minutes where the pom is the artifact -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2106) Add dependency-maven-plugin to plugins list (patch attached)
Add dependency-maven-plugin to plugins list (patch attached) Key: MNG-2106 URL: http://jira.codehaus.org/browse/MNG-2106 Project: Maven 2 Type: Bug Components: Documentation: General Versions: 2.0.2 Reporter: Brian Fox Attachments: plugins-add-dependency.patch Added info about dependency plugin to plugins list in the mojo section -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release maven-deploy-plugin 2.2
+1 Vincent 2006/2/23, John Casey [EMAIL PROTECTED]: Hi, Allan Ramirez has been good enough to fix the remaining bugs filed against the maven-deploy-plugin. I think it's ready for a 2.2 release. This release will include fixes to address: * documentation * interpolated POM information making its way into the remote repository * deploy-file with a classifier * option to skip installation of an artifact in the local repo when using deploy-file mojo * deploy-file when install-file was previously executed for the same artifact Customary terms for the vote: +1/0/-1, 72h Here's my +1. Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Subscription: Design Best Practices
Issue Subscription Filter: Design Best Practices (32 issues) Subscriber: mavendevlist Key Summary MNG-612 implement conflict resolution techniques http://jira.codehaus.org/browse/MNG-612 MNG-474 performance improvement for forked lifecycles http://jira.codehaus.org/browse/MNG-474 MNG-1381best practices: testing strategies http://jira.codehaus.org/browse/MNG-1381 MNG-1305Document Maven's own development process http://jira.codehaus.org/browse/MNG-1305 MNG-1563how to write integration tests http://jira.codehaus.org/browse/MNG-1563 MNG-1936pattern: for mojo parameters which have default values in the POM we need standard usage http://jira.codehaus.org/browse/MNG-1936 MNG-1950Ability to introduce new lifecycles phases http://jira.codehaus.org/browse/MNG-1950 MNG-1931add a reportingManagement section http://jira.codehaus.org/browse/MNG-1931 MNG-1508Need a process-test-classes phase http://jira.codehaus.org/browse/MNG-1508 MNG-1440Developer Object Model (DOM) http://jira.codehaus.org/browse/MNG-1440 MNG-41 best practices: site management http://jira.codehaus.org/browse/MNG-41 MNG-1423best practices: setting up multi-module build http://jira.codehaus.org/browse/MNG-1423 MNG-1569Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare http://jira.codehaus.org/browse/MNG-1569 MNG-1439Organization Object Model (OOM) http://jira.codehaus.org/browse/MNG-1439 MNG-905 review clean repo install of m2 for download trimming http://jira.codehaus.org/browse/MNG-905 MNG-939 specify maven settings from command line http://jira.codehaus.org/browse/MNG-939 MNG-125 guarded mojo execution http://jira.codehaus.org/browse/MNG-125 MNG-657 possible chicken and egg problem with extensions http://jira.codehaus.org/browse/MNG-657 MNG-1425best practices: the location of configuration files vs resources http://jira.codehaus.org/browse/MNG-1425 MNG-139 server definitions should be reusable http://jira.codehaus.org/browse/MNG-139 MNG-140 refactor maven-artifact http://jira.codehaus.org/browse/MNG-140 MNG-367 best practices: multi-user installation http://jira.codehaus.org/browse/MNG-367 MNG-1468best practices: version management in multi project builds http://jira.codehaus.org/browse/MNG-1468 MNG-1452best practices: deployment of aggregate JARs produced by the assembly plug-in http://jira.codehaus.org/browse/MNG-1452 MNG-416 best practices: multiple profile deployments http://jira.codehaus.org/browse/MNG-416 MNG-1441Starting thinking about a proper distributed repository mechanism a la CPAN http://jira.codehaus.org/browse/MNG-1441 MNG-1885Uniquely identify modules by module name and version number http://jira.codehaus.org/browse/MNG-1885 MNG-647 Allow Maven 2 to be monitored using JMX. http://jira.codehaus.org/browse/MNG-647 MNG-1463best practices: plugin inheritance for a multi project build http://jira.codehaus.org/browse/MNG-1463 MNG-1437How to make additions to the POM and have it be backward/forward compatible http://jira.codehaus.org/browse/MNG-1437 MNG-1867deprecate system scope, analyse other use cases http://jira.codehaus.org/browse/MNG-1867 MNG-868 Use uniform format for properties and other tags http://jira.codehaus.org/browse/MNG-868 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MRM-95) Allow cache timeout configurations for each proxied remote repository
[ http://jira.codehaus.org/browse/MRM-95?page=all ] Edwin Punzalan closed MRM-95: - Resolution: Fixed Allow cache timeout configurations for each proxied remote repository - Key: MRM-95 URL: http://jira.codehaus.org/browse/MRM-95 Project: Maven Repository Manager Type: Task Components: remote proxy Versions: 1.0-alpha-1 Reporter: Edwin Punzalan Assignee: Edwin Punzalan Original Estimate: 12 hours Time Spent: 6 hours Remaining: 6 hours -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
