[jira] Commented: (CONTINUUM-1353) after a few weeks, continuum runs into outofmemory error
[ http://jira.codehaus.org/browse/CONTINUUM-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103747 ] tony nys commented on CONTINUUM-1353: - 367612 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Changes found, building 367612 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Performing action update-project-from-working-directory 367612 [pool-1-thread-1] INFO org.codehaus.plexus.action.Action:update-project-from-working-directory - Updating project 'WPM Solutions - Financial/Lending - Lease Service Implementation' from checkout. 367768 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Performing action execute-builder 367972 [pool-1-thread-1] INFO org.apache.maven.continuum.utils.shell.ShellCommandHelper:default - Executing: C:\apps\maven-2.0.7\bin\mvn --batch-mode --non-recursive -Dmaven.test.skip=true clean deploy 367972 [pool-1-thread-1] INFO org.apache.maven.continuum.utils.shell.ShellCommandHelper:default - Working directory: C:\apps\continuum-data\working-directory\11 377456 [pool-1-thread-1] INFO org.apache.maven.continuum.execution.ContinuumBuildExecutor:maven2 - Exit code: 0 377675 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Performing action deploy-artifact 377722 [pool-1-thread-1] INFO org.apache.maven.artifact.repository.metadata.RepositoryMetadataManager:default - Retrieving previous metadata from deployment-repository 377753 [pool-1-thread-1] INFO org.apache.maven.artifact.manager.WagonManager:default - Uploading project information for solutions-fl-lease-service-implementation 2.1.0 377768 [pool-1-thread-1] INFO org.apache.maven.artifact.repository.metadata.RepositoryMetadataManager:default - Retrieving previous metadata from deployment-repository 377768 [pool-1-thread-1] INFO org.apache.maven.artifact.manager.WagonManager:default - Uploading repository metadata for: 'artifact com.accelior.wpm:solutions-fl-lease-service-implementation' 377956 [pool-1-thread-1] INFO org.codehaus.plexus.notification.notifier.Notifier:mail - Same state, not sending message. 377956 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Initializing build 582504 [Thread-6] ERROR org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:build-project - Error executing task edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: Java heap space at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(FutureTask.java:299) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask.java:128) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.waitForTask(ThreadedTaskQueueExecutor.java:165) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:127) Caused by: java.lang.OutOfMemoryError: Java heap space 582504 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Initializing build 582535 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Starting build of Web Enabled Leasing Model 582582 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Purging exiting working copy 582582 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Performing action clean-working-directory 584035 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Updating working dir 584035 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Performing action check-working-directory 584035 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Performing action checkout-project 584035 [pool-1-thread-1] INFO org.apache.maven.continuum.scm.ContinuumScm:default - Checking out project: 'Web Enabled Leasing Model', id: '18' to 'C:\apps\continuum-data\working-directory\18'. 584035 [pool-1-thread-1] INFO org.apache.maven.scm.manager.ScmManager:default - Executing: cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/ACCELIOR_LOCAL -q checkout -d 18 ING-LEASE/WEL-302/wel-model 584035 [pool-1-thread-1] INFO org.apache.maven.scm.manager.ScmManager:default - Working directory: C:\apps\continuum-data\working-directory 584895 [pool-1-thread-1] INFO org.apache.maven.continuum.scm.ContinuumScm:default - Checked out 12 files. 584895 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Merging SCM results 584957 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontrolle
[jira] Commented: (CONTINUUM-1353) after a few weeks, continuum runs into outofmemory error
[ http://jira.codehaus.org/browse/CONTINUUM-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103746 ] tony nys commented on CONTINUUM-1353: - ij> select count(*) from changefile; 1 --- 3809325 select count(*) from changeset; 1 --- 16146 > after a few weeks, continuum runs into outofmemory error > > > Key: CONTINUUM-1353 > URL: http://jira.codehaus.org/browse/CONTINUUM-1353 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.1-alpha-2 >Reporter: tony nys >Priority: Blocker > > when clicking on the build history, memory of the jvm increases from 100MB > until 470MB > after that it crashes with outofmemory error (JDO exception) > Increasing the plexus jvm memory does have no affect: > %PLEXUS_JAVA_EXE% %PLEXUS_OPTS% -Xmx900M -XX:MaxPermSize=128m -classpath > "%PLEXUS_HOME%\core\boot\plexus-classworlds-1.2-alpha-7.jar" > -Dclassworlds.conf="%PLEXUS_HOME%\conf\classworlds.conf" > -Dplexus.core=%PLEXUS_CORE% -Dplexus.system.path="%PATH%" > -Djava.io.tmpdir=%PLEXUS_TMPDIR% -Dplexus.home="%PLEXUS_HOME%" > -Dappserver.base="%PLEXUS_BASE%" -Dtools.jar="%TOOLS_JAR%" > org.codehaus.plexus.classworlds.launcher.Launcher %PLEXUS_CMD_LINE_ARGS% > So probably bug in fetch from db where all objects are retrieved ? > For us this is a showstopper. Would MySQL DB be a workaround ? I guess the > query is the same, so will the memory usage be ? > Where can I find the complete DDL script for mysql ? On the wiki there is > only 1 table ... ? > javax.jdo.JDODataStoreException: Iteration request failed : > SELECT > THIS.CHANGEFILE_ID,THIS.MODEL_ENCODING,THIS."NAME",THIS.REVISION,THIS.STATUS,THIS.FILES_INTEGER_IDX > AS JPOXORDER0 FROM > CHANGEFILE THIS WHERE ? = THIS.FILES_CHANGESET_ID_OID AND > THIS.FILES_INTEGER_IDX >= ? ORDER BY JPOXORDER0 NestedThrowables: SQL > Exception: Java exception: > 'Java heap space: java.lang.OutOfMemoryError'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-329) The Reports link gives an HTTP 500
[ http://jira.codehaus.org/browse/MRM-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103745 ] Brett Porter commented on MRM-329: -- looks good! comments from the usage side: - what's the use case for searching by artifact ID? I can understand the group filter, but not sure about the others - can the repository list easily be a dropdown? - I'd put them all in one form, so each field is an additional constraint (and the default is just to show everything) - I don't think the final report should be skinned - it doesn't really fit - I'd drop the last 3 columns from the table - how come a separate java app is started when this is generated? (tanuki WrapperSimpleApp) - or is this just me? haven't eval'd the code... > The Reports link gives an HTTP 500 > -- > > Key: MRM-329 > URL: http://jira.codehaus.org/browse/MRM-329 > Project: Archiva > Issue Type: Bug > Components: reporting >Affects Versions: 1.0-alpha-1 >Reporter: Napoleon Esmundo C. Ramirez >Assignee: Joakim Erdfelt >Priority: Blocker > Fix For: 1.0-beta-1 > > Attachments: MRM-329-archiva-database-20070725.patch, > MRM-329-archiva-database-20070801.patch, > MRM-329-archiva-model-20070727.patch, MRM-329-archiva-model-20070801.patch, > MRM-329-archiva-webapp-20070725.patch, MRM-329-archiva-webapp-20070801.patch > > > Clicking the Reports link in the side navigation menu displays the following > (edited/snipped stacktrace): > HTTP ERROR: 500 > RequestURI=/admin/reports.action > Caused by: javax.el.PropertyNotFoundException: The class > 'org.apache.maven.archiva.reporting.artifact.OldArtifactReport' does not have > the property 'groupId'. > at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:574) > at javax.el.BeanELResolver.getValue(BeanELResolver.java:280) > at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143) > at com.sun.el.parser.AstValue.getValue(AstValue.java:118) > at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:192) > at > org.apache.jasper.runtime.PageContextImpl.evaluateExpression(PageContextImpl.java:974) > at > org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspx_meth_c_forEach_0(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:143) > at > org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspService(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:85) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRELEASE-87) Poms are written with wrong encodings
[ http://jira.codehaus.org/browse/MRELEASE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103719 ] Herve Boutemy edited comment on MRELEASE-87 at 8/1/07 1:22 AM: --- Here is a patch to use WriterFactory and XmlStreamWriter added in plexus-utils 1.4.5 to handle stream encoding detection according to the XML content written. see http://docs.codehaus.org/display/MAVENUSER/XML+encoding for the roadmap to XML encoding support in Maven2 was: Here is a patch to use WriterFactory and XmlStreamWriter added in plexus-utils 1.4.5 to handle stream encoding detection according to the XML content written > Poms are written with wrong encodings > - > > Key: MRELEASE-87 > URL: http://jira.codehaus.org/browse/MRELEASE-87 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4, 2.0-beta-5, 2.0-beta-6 >Reporter: Carlos Sanchez >Priority: Critical > Fix For: 2.0-beta-7 > > Attachments: MRELEASE-87.diff > > > I have committed a test that works in my Sun and IBM JDKs under windows but > breaks in the Continuum at codehaus. > Tomorrow i'll try with IBM JDK under linux. -- 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: (CONTINUUM-1353) after a few weeks, continuum runs into outofmemory error
[ http://jira.codehaus.org/browse/CONTINUUM-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103743 ] tony nys commented on CONTINUUM-1353: - really showstopper, apparently not only happens in webinterface, also at runtime, continuum queries db and.. bang ! > after a few weeks, continuum runs into outofmemory error > > > Key: CONTINUUM-1353 > URL: http://jira.codehaus.org/browse/CONTINUUM-1353 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.1-alpha-2 >Reporter: tony nys >Priority: Blocker > > when clicking on the build history, memory of the jvm increases from 100MB > until 470MB > after that it crashes with outofmemory error (JDO exception) > Increasing the plexus jvm memory does have no affect: > %PLEXUS_JAVA_EXE% %PLEXUS_OPTS% -Xmx900M -XX:MaxPermSize=128m -classpath > "%PLEXUS_HOME%\core\boot\plexus-classworlds-1.2-alpha-7.jar" > -Dclassworlds.conf="%PLEXUS_HOME%\conf\classworlds.conf" > -Dplexus.core=%PLEXUS_CORE% -Dplexus.system.path="%PATH%" > -Djava.io.tmpdir=%PLEXUS_TMPDIR% -Dplexus.home="%PLEXUS_HOME%" > -Dappserver.base="%PLEXUS_BASE%" -Dtools.jar="%TOOLS_JAR%" > org.codehaus.plexus.classworlds.launcher.Launcher %PLEXUS_CMD_LINE_ARGS% > So probably bug in fetch from db where all objects are retrieved ? > For us this is a showstopper. Would MySQL DB be a workaround ? I guess the > query is the same, so will the memory usage be ? > Where can I find the complete DDL script for mysql ? On the wiki there is > only 1 table ... ? > javax.jdo.JDODataStoreException: Iteration request failed : > SELECT > THIS.CHANGEFILE_ID,THIS.MODEL_ENCODING,THIS."NAME",THIS.REVISION,THIS.STATUS,THIS.FILES_INTEGER_IDX > AS JPOXORDER0 FROM > CHANGEFILE THIS WHERE ? = THIS.FILES_CHANGESET_ID_OID AND > THIS.FILES_INTEGER_IDX >= ? ORDER BY JPOXORDER0 NestedThrowables: SQL > Exception: Java exception: > 'Java heap space: java.lang.OutOfMemoryError'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-329) The Reports link gives an HTTP 500
[ http://jira.codehaus.org/browse/MRM-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103742 ] Brett Porter commented on MRM-329: -- and also one patch from the root directory is easier to apply :) > The Reports link gives an HTTP 500 > -- > > Key: MRM-329 > URL: http://jira.codehaus.org/browse/MRM-329 > Project: Archiva > Issue Type: Bug > Components: reporting >Affects Versions: 1.0-alpha-1 >Reporter: Napoleon Esmundo C. Ramirez >Assignee: Joakim Erdfelt >Priority: Blocker > Fix For: 1.0-beta-1 > > Attachments: MRM-329-archiva-database-20070725.patch, > MRM-329-archiva-database-20070801.patch, > MRM-329-archiva-model-20070727.patch, MRM-329-archiva-model-20070801.patch, > MRM-329-archiva-webapp-20070725.patch, MRM-329-archiva-webapp-20070801.patch > > > Clicking the Reports link in the side navigation menu displays the following > (edited/snipped stacktrace): > HTTP ERROR: 500 > RequestURI=/admin/reports.action > Caused by: javax.el.PropertyNotFoundException: The class > 'org.apache.maven.archiva.reporting.artifact.OldArtifactReport' does not have > the property 'groupId'. > at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:574) > at javax.el.BeanELResolver.getValue(BeanELResolver.java:280) > at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143) > at com.sun.el.parser.AstValue.getValue(AstValue.java:118) > at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:192) > at > org.apache.jasper.runtime.PageContextImpl.evaluateExpression(PageContextImpl.java:974) > at > org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspx_meth_c_forEach_0(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:143) > at > org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspService(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:85) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-329) The Reports link gives an HTTP 500
[ http://jira.codehaus.org/browse/MRM-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103741 ] Brett Porter commented on MRM-329: -- it's normally best not to date the patches - that way the new ones just obsolete the old ones and it's easiest to figure out which ones to apply :) > The Reports link gives an HTTP 500 > -- > > Key: MRM-329 > URL: http://jira.codehaus.org/browse/MRM-329 > Project: Archiva > Issue Type: Bug > Components: reporting >Affects Versions: 1.0-alpha-1 >Reporter: Napoleon Esmundo C. Ramirez >Assignee: Joakim Erdfelt >Priority: Blocker > Fix For: 1.0-beta-1 > > Attachments: MRM-329-archiva-database-20070725.patch, > MRM-329-archiva-database-20070801.patch, > MRM-329-archiva-model-20070727.patch, MRM-329-archiva-model-20070801.patch, > MRM-329-archiva-webapp-20070725.patch, MRM-329-archiva-webapp-20070801.patch > > > Clicking the Reports link in the side navigation menu displays the following > (edited/snipped stacktrace): > HTTP ERROR: 500 > RequestURI=/admin/reports.action > Caused by: javax.el.PropertyNotFoundException: The class > 'org.apache.maven.archiva.reporting.artifact.OldArtifactReport' does not have > the property 'groupId'. > at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:574) > at javax.el.BeanELResolver.getValue(BeanELResolver.java:280) > at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143) > at com.sun.el.parser.AstValue.getValue(AstValue.java:118) > at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:192) > at > org.apache.jasper.runtime.PageContextImpl.evaluateExpression(PageContextImpl.java:974) > at > org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspx_meth_c_forEach_0(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:143) > at > org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspService(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:85) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRM-329) The Reports link gives an HTTP 500
[ http://jira.codehaus.org/browse/MRM-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103739 ] Teodoro Cue Jr. edited comment on MRM-329 at 8/1/07 12:35 AM: -- Hi, Updated patch(20070801) attached. Comments and suggestions will be greatly appreciated. Thanks! was: Hi, Patch attached. Comments and suggestions will be greatly appreciated. Thanks! > The Reports link gives an HTTP 500 > -- > > Key: MRM-329 > URL: http://jira.codehaus.org/browse/MRM-329 > Project: Archiva > Issue Type: Bug > Components: reporting >Affects Versions: 1.0-alpha-1 >Reporter: Napoleon Esmundo C. Ramirez >Assignee: Joakim Erdfelt >Priority: Blocker > Fix For: 1.0-beta-1 > > Attachments: MRM-329-archiva-database-20070725.patch, > MRM-329-archiva-database-20070801.patch, > MRM-329-archiva-model-20070727.patch, MRM-329-archiva-model-20070801.patch, > MRM-329-archiva-webapp-20070725.patch, MRM-329-archiva-webapp-20070801.patch > > > Clicking the Reports link in the side navigation menu displays the following > (edited/snipped stacktrace): > HTTP ERROR: 500 > RequestURI=/admin/reports.action > Caused by: javax.el.PropertyNotFoundException: The class > 'org.apache.maven.archiva.reporting.artifact.OldArtifactReport' does not have > the property 'groupId'. > at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:574) > at javax.el.BeanELResolver.getValue(BeanELResolver.java:280) > at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143) > at com.sun.el.parser.AstValue.getValue(AstValue.java:118) > at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:192) > at > org.apache.jasper.runtime.PageContextImpl.evaluateExpression(PageContextImpl.java:974) > at > org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspx_meth_c_forEach_0(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:143) > at > org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspService(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:85) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373) -- 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: (MRM-329) The Reports link gives an HTTP 500
[ http://jira.codehaus.org/browse/MRM-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Teodoro Cue Jr. updated MRM-329: Attachment: MRM-329-archiva-webapp-20070801.patch MRM-329-archiva-model-20070801.patch MRM-329-archiva-database-20070801.patch Hi, Patch attached. Comments and suggestions will be greatly appreciated. Thanks! > The Reports link gives an HTTP 500 > -- > > Key: MRM-329 > URL: http://jira.codehaus.org/browse/MRM-329 > Project: Archiva > Issue Type: Bug > Components: reporting >Affects Versions: 1.0-alpha-1 >Reporter: Napoleon Esmundo C. Ramirez >Assignee: Joakim Erdfelt >Priority: Blocker > Fix For: 1.0-beta-1 > > Attachments: MRM-329-archiva-database-20070725.patch, > MRM-329-archiva-database-20070801.patch, > MRM-329-archiva-model-20070727.patch, MRM-329-archiva-model-20070801.patch, > MRM-329-archiva-webapp-20070725.patch, MRM-329-archiva-webapp-20070801.patch > > > Clicking the Reports link in the side navigation menu displays the following > (edited/snipped stacktrace): > HTTP ERROR: 500 > RequestURI=/admin/reports.action > Caused by: javax.el.PropertyNotFoundException: The class > 'org.apache.maven.archiva.reporting.artifact.OldArtifactReport' does not have > the property 'groupId'. > at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:574) > at javax.el.BeanELResolver.getValue(BeanELResolver.java:280) > at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143) > at com.sun.el.parser.AstValue.getValue(AstValue.java:118) > at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:192) > at > org.apache.jasper.runtime.PageContextImpl.evaluateExpression(PageContextImpl.java:974) > at > org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspx_meth_c_forEach_0(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:143) > at > org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspService(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:85) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-430) Archiva always writes to ~/.m2/archiva.xml
[ http://jira.codehaus.org/browse/MRM-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103735 ] Brett Porter commented on MRM-430: -- note on the "read" end of this behaviour, it should read both, and merge the results, taking ~/.m2/archiva.xml as the priority. This should already be achieved by the registry mechanism. > Archiva always writes to ~/.m2/archiva.xml > -- > > Key: MRM-430 > URL: http://jira.codehaus.org/browse/MRM-430 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-2 >Reporter: Wendy Smoak > Fix For: 1.0-beta-1 > > > From http://maven.apache.org/archiva/guides/configuration.html : > "When Archiva saves it's configuration, all configuration is stored to > a single file. The file chosen is by the following rules: > * If ~/.m2/archiva.xml exists, it is saved there > * Otherwise, it is saved to $ARCHIVA_BASE/conf/archiva.xml, > regardless of whether it previously existed. " > The latest code (r553963) always writes to ~/.m2/archiva.xml, even if it did > not exist, and completely ignores $ARCHIVA_BASE/conf/archiva.xml. > Related thread: > http://www.nabble.com/Archiva-now-always-writes-to-%7E-.m2-archiva.xml-t4053580.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1357) release data-management with beta2
[ http://jira.codehaus.org/browse/CONTINUUM-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse McConnell updated CONTINUUM-1357: --- Fix Version/s: 1.1-beta-2 Component/s: Database > release data-management with beta2 > -- > > Key: CONTINUUM-1357 > URL: http://jira.codehaus.org/browse/CONTINUUM-1357 > Project: Continuum > Issue Type: Task > Components: Database >Affects Versions: 1.1-beta-1 >Reporter: Jesse McConnell > Fix For: 1.1-beta-2 > > > we need to enable the data management with the next release of continuum -- 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-1357) release data-management with beta2
release data-management with beta2 -- Key: CONTINUUM-1357 URL: http://jira.codehaus.org/browse/CONTINUUM-1357 Project: Continuum Issue Type: Task Affects Versions: 1.1-beta-1 Reporter: Jesse McConnell Fix For: 1.1-beta-2 we need to enable the data management with the next release of continuum -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-312) WebContent folder linked to webapp folder is not generated
[
http://jira.codehaus.org/browse/MECLIPSE-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103731
]
Dan Tran commented on MECLIPSE-312:
---
what is your eclipse's configuration in the pom looks like?
This problem may have been fixed in 2.5-SNAPSHOT
> WebContent folder linked to webapp folder is not generated
> --
>
> Key: MECLIPSE-312
> URL: http://jira.codehaus.org/browse/MECLIPSE-312
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: WTP support
> Environment: Maven 2, Linux & Windows
>Reporter: Cyril JOUI
> Attachments: EclipseProjectWriter.java, EclipseWtpComponentWriter.java
>
>
> When I generate a eclipse project with wtpsupport, maven plugin doesn't
> create a WebContent folder in web project.
> Configuration part in eclipse is:
> in org.eclipse.wst.common.component:
>
> and /WebContent is refered by:
>
> WebContent
> 2
>
> //rpf/dev/modules/rpf-gateway/src/main/webapp
>
> in .project file
> I made modification on EclipseProjectWriter:
> // if war project (add WebContent => webapp)
> if ("war".equals(config.getProject().getPackaging())) {
> addLink (writer, "WebContent",
> config.getProject().getBasedir() +
> "/src/main/webapp", LINK_TYPE_DIRECTORY);
> }
> And
> writer.startElement( ELT_WB_RESOURCE );
> writer.addAttribute( ATTR_DEPLOY_PATH, "/" ); //$NON-NLS-1$
> writer.addAttribute( ATTR_SOURCE_PATH, "/WebContent");
> /*
> writer.addAttribute( ATTR_SOURCE_PATH, IdeUtils
> .toRelativeAndFixSeparator(
> config.getEclipseProjectDirectory(), warSourceDirectory, false ) );
> */
> writer.endElement();
> in EclipseWtpComponentWriter
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-313) AJDT feature
AJDT feature Key: MECLIPSE-313 URL: http://jira.codehaus.org/browse/MECLIPSE-313 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Environment: Windows / Linux Reporter: Cyril JOUI Priority: Minor Attachments: EclipsePlugin.java This feature adds configuration parameters for project which use AspectJ Compiler. It is a current preview version. I will go on my work this week ... To use it, add -Dajdtversion=1.5 (currently tested version of this plugin). Changes made on EclipsePlugin.java -- 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-467) observe folder for changes which can trigger a build
[ http://jira.codehaus.org/browse/CONTINUUM-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-467. -- Assignee: Emmanuel Venisse Resolution: Duplicate Fix Version/s: (was: Future) Duplicate CONTINUUM-347 > observe folder for changes which can trigger a build > > > Key: CONTINUUM-467 > URL: http://jira.codehaus.org/browse/CONTINUUM-467 > Project: Continuum > Issue Type: New Feature > Components: Core system > Environment: all >Reporter: yo >Assignee: Emmanuel Venisse >Priority: Minor > > It would be nice if another way to trigger a build would be to observe a > folder for changes. everytime someone commits something back to the repo a > file is created in a folder which continuum observes and triggers the build > of the project by the name of the file. That was conitnuum does not have to > say query a hundreds svnrepos if something changed. > Greetings > Yo -- 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-640) Auto Building triggered by svn commit
[ http://jira.codehaus.org/browse/CONTINUUM-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-640. -- Assignee: Emmanuel Venisse Resolution: Duplicate Fix Version/s: (was: Future) Duplicate CONTINUUM-347 > Auto Building triggered by svn commit > - > > Key: CONTINUUM-640 > URL: http://jira.codehaus.org/browse/CONTINUUM-640 > Project: Continuum > Issue Type: Improvement > Components: SCM >Affects Versions: 1.0.1 >Reporter: Kevin Wang >Assignee: Emmanuel Venisse > > Should we add the function to support auto build while subversion commit? > just like CruiseContril. -- 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-344) Complains about not finding m2 and then builds successfully
[ http://jira.codehaus.org/browse/CONTINUUM-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-344. -- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: Future) out of date with continuum profiles. > Complains about not finding m2 and then builds successfully > --- > > Key: CONTINUUM-344 > URL: http://jira.codehaus.org/browse/CONTINUUM-344 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.0-beta-1 > Environment: Linux >Reporter: Mark Hobson >Assignee: Emmanuel Venisse >Priority: Minor > Attachments: wrapper.log > > > When adding a m2 project it complains that it can't find m2 in the attached > log and then proceeds to build successfully. > m2 is actually at /usr/local/m2/bin/m2 and can be run from the command line > as the continuum user. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-312) WebContent folder linked to webapp folder is not generated
WebContent folder linked to webapp folder is not generated
--
Key: MECLIPSE-312
URL: http://jira.codehaus.org/browse/MECLIPSE-312
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: WTP support
Environment: Maven 2, Linux & Windows
Reporter: Cyril JOUI
Attachments: EclipseProjectWriter.java, EclipseWtpComponentWriter.java
When I generate a eclipse project with wtpsupport, maven plugin doesn't create
a WebContent folder in web project.
Configuration part in eclipse is:
in org.eclipse.wst.common.component:
and /WebContent is refered by:
WebContent
2
//rpf/dev/modules/rpf-gateway/src/main/webapp
in .project file
I made modification on EclipseProjectWriter:
// if war project (add WebContent => webapp)
if ("war".equals(config.getProject().getPackaging())) {
addLink (writer, "WebContent",
config.getProject().getBasedir() +
"/src/main/webapp", LINK_TYPE_DIRECTORY);
}
And
writer.startElement( ELT_WB_RESOURCE );
writer.addAttribute( ATTR_DEPLOY_PATH, "/" ); //$NON-NLS-1$
writer.addAttribute( ATTR_SOURCE_PATH, "/WebContent");
/*
writer.addAttribute( ATTR_SOURCE_PATH, IdeUtils
.toRelativeAndFixSeparator(
config.getEclipseProjectDirectory(), warSourceDirectory, false ) );
*/
writer.endElement();
in EclipseWtpComponentWriter
--
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-1255) FATAL EnvironmentCheck Failure on Continuum Startup
[ http://jira.codehaus.org/browse/CONTINUUM-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1255: Fix Version/s: (was: Future) 1.1-beta-2 > FATAL EnvironmentCheck Failure on Continuum Startup > --- > > Key: CONTINUUM-1255 > URL: http://jira.codehaus.org/browse/CONTINUUM-1255 > Project: Continuum > Issue Type: Sub-task >Affects Versions: 1.1-alpha-1 > Environment: JBoss 4.0.5.GA, JDK 1.4.2_12 >Reporter: Gabriel Misura > Fix For: 1.1-beta-2 > > > 42734 [http-0.0.0.0-8080-1] INFO > org.codehaus.plexus.security.system.check.EnvironmentCheck:required-roles - > Checking the existance of required roles. > 43501 [http-0.0.0.0-8080-1] FATAL > com.opensymphony.xwork.interceptor.Interceptor:pssEnvironmentCheckInterceptor > - EnvironmentCheck Failure. > == > ENVIRONMENT FAILURE !! > Missing "/security" package namespace in xwork.xml > Missing [1] xwork.xml configuration elements. > == > 43651 [http-0.0.0.0-8080-1] INFO > com.opensymphony.xwork.interceptor.Interceptor:pssSecureActionInterceptor - > org.codehaus.plexus.security.ui.web.interceptor.SecureActionInterceptor > initialized! > 43876 [http-0.0.0.0-8080-1] INFO > com.opensymphony.xwork.interceptor.Interceptor:pssSecureActionInterceptor - > org.codehaus.plexus.security.ui.web.interceptor.SecureActionInterceptor > initialized! > 43886 [http-0.0.0.0-8080-1] INFO > com.opensymphony.xwork.interceptor.Interceptor:pssSecureActionInterceptor - > org.codehaus.plexus.security.ui.web.interceptor.SecureActionInterceptor > initialized! > 45228 [http-0.0.0.0-8080-1] INFO > com.opensymphony.xwork.interceptor.Interceptor:pssForceAdminUserInterceptor > - Admin user found. No need to configure admin user. > 49640 [http-0.0.0.0-8080-2] INFO > com.opensymphony.webwork.views.freemarker.FreemarkerManager - Instantiating > Freemarker ConfigManager!, > com.opensymphony.webwork.views.freemarker.FreemarkerManager -- 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-1265) NullPointerException when adding modules to a project group
[ http://jira.codehaus.org/browse/CONTINUUM-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1265: Fix Version/s: (was: Future) 1.1-beta-2 need to test > NullPointerException when adding modules to a project group > --- > > Key: CONTINUUM-1265 > URL: http://jira.codehaus.org/browse/CONTINUUM-1265 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-alpha-1 > Environment: Windows 2004 server installation >Reporter: Kristoffer Moum > Fix For: 1.1-beta-2 > > Attachments: stacktrace.txt > > > I have three Continuum instances running now and for one of them there seems > to be some state issue when attempting to add a module to a project group. > There is no problem adding modules to the other two instances. > When invoking this operation I get a NullPointerException (see the > attachment). -- 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-1333) show in project group summary per project also the status counters (as they are shown on the project groups pages)
[ http://jira.codehaus.org/browse/CONTINUUM-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1333: Priority: Minor (was: Major) Fix Version/s: (was: Future) 1.1-beta-2 > show in project group summary per project also the status counters (as they > are shown on the project groups pages) > --- > > Key: CONTINUUM-1333 > URL: http://jira.codehaus.org/browse/CONTINUUM-1333 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.1-alpha-2 >Reporter: tony nys >Priority: Minor > Fix For: 1.1-beta-2 > > > show in project group summary per project also the status counters (as they > are shown on the project groups pages) -- 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-1310) "cancel build" button no longer present when a build is in progress
[ http://jira.codehaus.org/browse/CONTINUUM-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1310: Fix Version/s: (was: Future) 1.1-beta-2 > "cancel build" button no longer present when a build is in progress > --- > > Key: CONTINUUM-1310 > URL: http://jira.codehaus.org/browse/CONTINUUM-1310 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-alpha-2 >Reporter: Brett Porter > Fix For: 1.1-beta-2 > > > just getting the greyed out link to "build now" on the group summary 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-1079) show "cancel build" as disabled, not "build now" a disabled when build is in progress, but user has insufficient permissions
[ http://jira.codehaus.org/browse/CONTINUUM-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1079: Fix Version/s: (was: Future) 1.1-beta-2 > show "cancel build" as disabled, not "build now" a disabled when build is in > progress, but user has insufficient permissions > > > Key: CONTINUUM-1079 > URL: http://jira.codehaus.org/browse/CONTINUUM-1079 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1-alpha-1 >Reporter: Brett Porter > Fix For: 1.1-beta-2 > > > currently, instead of showing the "cancel build" button in a disabled state, > it shows the "build now" button in a disabled state when a build is in > progress but the user doesn't have permission to cancel the 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] Updated: (CONTINUUM-811) Documentation of Deployment Repository Directory
[ http://jira.codehaus.org/browse/CONTINUUM-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-811: --- Fix Version/s: (was: Future) 1.1 > Documentation of Deployment Repository Directory > > > Key: CONTINUUM-811 > URL: http://jira.codehaus.org/browse/CONTINUUM-811 > Project: Continuum > Issue Type: Bug > Components: Documentation >Affects Versions: 1.0.3 >Reporter: Scott Cytacki > Fix For: 1.1 > > > I can't find any good documenation on how the deployment repository directory > works. As far as I can tell continuum magically runs a special mvn deploy > goal after any sucess build. > But I can't find this in the log. Also it isn't clear how this relates to an > explicit mvn deploy. -- 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-1037) Ant projects inherit a default build definition for Maven 2.
[ http://jira.codehaus.org/browse/CONTINUUM-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1037: Fix Version/s: (was: Future) 1.1-beta-2 need to test it > Ant projects inherit a default build definition for Maven 2. > > > Key: CONTINUUM-1037 > URL: http://jira.codehaus.org/browse/CONTINUUM-1037 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-alpha-1 >Reporter: Brett Porter > Fix For: 1.1-beta-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
[jira] Closed: (CONTINUUM-618) Refresh after "Build Now" create multiple builds
[ http://jira.codehaus.org/browse/CONTINUUM-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-618. -- Assignee: Emmanuel Venisse (was: Kenney Westerhof) Resolution: Won't Fix Fix Version/s: (was: Future) out of date > Refresh after "Build Now" create multiple builds > > > Key: CONTINUUM-618 > URL: http://jira.codehaus.org/browse/CONTINUUM-618 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.0.3 > Environment: xp >Reporter: Dan Tran >Assignee: Emmanuel Venisse > > After hitting "build now", the browser pauses for sometime and user loses > patient by hitting multiple refreshes > creating multiple forced builds > For a long build, it can be very annoyed. > Worst, we user put up a daily release build in Continuum, it will cause > multiple release builds -- 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-815) directory configuration
[ http://jira.codehaus.org/browse/CONTINUUM-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-815: --- Fix Version/s: (was: Future) 1.1 > directory configuration > --- > > Key: CONTINUUM-815 > URL: http://jira.codehaus.org/browse/CONTINUUM-815 > Project: Continuum > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.0.3 >Reporter: Torsten Curdt > Fix For: 1.1 > > > When I was installing maven it was not clear what the directories are for > that I had to specify. > - working directory > - build output directory > - local repository > The installation guide should explain values like these. Especially awkward > is that the builds happen in the working area - not in the build output area. > Just needs some documentation. -- 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-1063) get rid of old models in continuum-webapp
[ http://jira.codehaus.org/browse/CONTINUUM-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1063: Fix Version/s: (was: Future) 1.1-beta-2 > get rid of old models in continuum-webapp > - > > Key: CONTINUUM-1063 > URL: http://jira.codehaus.org/browse/CONTINUUM-1063 > Project: Continuum > Issue Type: Task >Reporter: Brett Porter > Fix For: 1.1-beta-2 > > > the mdo's in this directory either are not or should not be used. In > addition, I think the ContinuumState bean in the main model belongs as a > separate rather than generated class to avoid being caught up in the > XML/JDO/etc processing. If we really need to generate enums, we should just > use Java 5 already :) -- 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-692) Add specific continuum values as variables on build parameters input
[
http://jira.codehaus.org/browse/CONTINUUM-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse closed CONTINUUM-692.
--
Assignee: Emmanuel Venisse
Resolution: Duplicate
Fix Version/s: (was: Future)
Duplicate CONTINUUM-990
> Add specific continuum values as variables on build parameters input
>
>
> Key: CONTINUUM-692
> URL: http://jira.codehaus.org/browse/CONTINUUM-692
> Project: Continuum
> Issue Type: New Feature
> Components: Core system, Web interface
>Affects Versions: 1.0.3
>Reporter: Christian Gruber
>Assignee: Emmanuel Venisse
>Priority: Critical
>
> The idea is to add certain key continuum values as variables that can be
> passed into the parameters of a build. The main one at question is a build
> #. This would allow someone to do something like:
> (mvn) clean source:jar javadoc:jar deploy scm:tag
> -Dtag=DAILY_BUILD_${continuum.build.number}
> This way, if the thing deployed successfully, it would be tagged.
> Other examples of variables that might be substituted include build timestamp
> (on server), and continuum group.
> This would also be highly useful in ant builds, I suspect.
--
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-347) document push build technique by project id
[ http://jira.codehaus.org/browse/CONTINUUM-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-347: --- Fix Version/s: (was: Future) 1.1 > document push build technique by project id > --- > > Key: CONTINUUM-347 > URL: http://jira.codehaus.org/browse/CONTINUUM-347 > Project: Continuum > Issue Type: Task > Components: Documentation >Reporter: Brett Porter > Fix For: 1.1 > > > this could use some further explanation -- 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-1253) Allow to deploy artifact without timestamps
[
http://jira.codehaus.org/browse/CONTINUUM-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse closed CONTINUUM-1253.
---
Assignee: Emmanuel Venisse
Resolution: Won't Fix
Fix Version/s: (was: Future)
use mvn deploy instead
> Allow to deploy artifact without timestamps
> ---
>
> Key: CONTINUUM-1253
> URL: http://jira.codehaus.org/browse/CONTINUUM-1253
> Project: Continuum
> Issue Type: New Feature
> Components: Core system, Integration - Maven 2, Web - UI
>Affects Versions: 1.0.3
>Reporter: Damian Golda
>Assignee: Emmanuel Venisse
>
> In our organisation we don't use unique names of jars in repository. So we
> have set uniqueVersion to false in pom.xml:
>
>
> maven2-repo
> Maven2 Repository
> file://${repoPath}
> false
>
>
> And it works while running mvn from command line.
> But when we build project from continuum, it deploys built jar into
> Deployment Repository Directory and unfortunately always adds timestamps to
> filename.
> The reason is that in
> org.apache.maven.continuum.core.action.DeployArtifactContinuumAction is
> specified "true" as uniqueVersion parameter of
> ArtifactRepositoryFactory.createDeploymentArtifactRepository method:
> ArtifactRepository deploymentRepository =
>
> artifactRepositoryFactory.createDeploymentArtifactRepository(
> "deployment-repository", location,
>
> repositoryLayout, true );
> PLEASE, change it, and allow to set required behavior by admin in Edit
> Configuration page.
> We have strange problems with hundreds of fat jars in repository, caused by
> unique names of them.
> I think it's needed to:
> -add to Configuration new field, for example DeployWithUniqueVersion
> -change DeployArtifactContinuumAction, to uset that field instead of
> hard-coded true
> -add new field to EditContinuumConfiguration.vm
> -add some code to ConfigurationAction and InitializationChecker
--
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-1249) Remote repository JAR manifest not updated if dependancy scope is changed
[ http://jira.codehaus.org/browse/CONTINUUM-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1249. --- Assignee: Emmanuel Venisse Resolution: Won't Fix Fix Version/s: (was: Future) It isn't a Continuum bug > Remote repository JAR manifest not updated if dependancy scope is changed > - > > Key: CONTINUUM-1249 > URL: http://jira.codehaus.org/browse/CONTINUUM-1249 > Project: Continuum > Issue Type: Bug > Components: Integration - Maven 2 >Affects Versions: 1.0.3 > Environment: Windows XP >Reporter: Mark Jeffery >Assignee: Emmanuel Venisse > > If Maven2 dependancy scope is changed from the default to provided, and the > "clean install" goals are run everything is fine. The referenced jars > manifest entry is removed and the jar is installed in the local repository. > If you run a "clean deploy" straight afterwards, the project state has not > changed and the resulting jars are not deployed to the remote repository. > So the problem is that the jars deployed on a previous "clean deploy" are > still in the repository with incorrect manifest entries. (Still referencing > the "provided" dependancy. > If the pom is updated and a "clean deploy" is done straight away, it works > fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1248) site:stage doesn't work for cobertura report
[ http://jira.codehaus.org/browse/CONTINUUM-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1248. --- Assignee: Emmanuel Venisse Resolution: Won't Fix Fix Version/s: (was: Future) It isn't a Continuum bug > site:stage doesn't work for cobertura report > > > Key: CONTINUUM-1248 > URL: http://jira.codehaus.org/browse/CONTINUUM-1248 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.0.3 > Environment: windows server 2003; java 1.5 >Reporter: Larry Hamel >Assignee: Emmanuel Venisse > > create project with cobertura report. > use goal site:stage -DstagingDirectory=..\..\webapp\ > notice that other reports stage to given directory OK, but cobertura shows > normal logging (no errors), but does not copy -- 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-1176) Mail configuration is consistent (registration email vs. build result email)
[ http://jira.codehaus.org/browse/CONTINUUM-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1176. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: Future) 1.1-alpha-2 All use the jndi session > Mail configuration is consistent (registration email vs. build result email) > > > Key: CONTINUUM-1176 > URL: http://jira.codehaus.org/browse/CONTINUUM-1176 > Project: Continuum > Issue Type: Bug > Components: Notifier - Mail >Affects Versions: 1.1-alpha-1 > Environment: Webapp SNAPSHOT - 20070214.0300 >Reporter: Stephane Nicoll >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.1-alpha-2 > > > Mail configuration is inconsistent: > * Mail sent for build results uses the application.xml configuration > (MailNotifier) > * Mail sent to validate a new user registration seems to use roughly the JNDI > Mail session. It does not set the fromName and fromAddress parameter > specified in application.xml -- 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-1247) Too many open files Exception when building large projects
[ http://jira.codehaus.org/browse/CONTINUUM-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1247. --- Assignee: Emmanuel Venisse Resolution: Won't Fix Fix Version/s: (was: Future) It isn't a Continuum bug > Too many open files Exception when building large projects > -- > > Key: CONTINUUM-1247 > URL: http://jira.codehaus.org/browse/CONTINUUM-1247 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.0.3 > Environment: Linux (debian) >Reporter: Ivo van Dongen >Assignee: Emmanuel Venisse > > When building large projects we run into a problem in the last stages of a > maven2 build. We've alreadye upped the OS limits on open file handles per > proces and in general. > The last part of the maven output is: > [INFO] [war:war] > [INFO] Exploding webapp... > [INFO] Copy webapp webResources to > /opt/continuum-1.0.3/apps/continuum/working-directory/55/target/ROOT > [INFO] Copy webapp webResources to > /opt/continuum-1.0.3/apps/continuum/working-directory/55/target/ROOT > [INFO] Assembling webapp tesis in > /opt/continuum-1.0.3/apps/continuum/working-directory/55/target/ROOT > [INFO] Generating war > /opt/continuum-1.0.3/apps/continuum/working-directory/55/target/ROOT.war > [INFO] Building war: > /opt/continuum-1.0.3/apps/continuum/working-directory/55/target/ROOT.war > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error assembling WAR: Problem creating war: > /opt/continuum-1.0.3/apps/continuum/working-directory/55/target/ROOT/WEB-INF/lib/XmlSchema-1.1.jar > (Too many open files) > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling WAR: > Problem creating war: > /opt/continuum-1.0.3/apps/continuum/working-directory/55/target/ROOT/WEB-INF/lib/XmlSchema-1.1.jar > (Too many open files) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error assembling > WAR: Problem creating war: > /opt/continuum-1.0.3/apps/continuum/working-directory/55/target/ROOT/WEB-INF/lib/XmlSchema-1.1.jar > (Too many open files) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:149) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > ... 16 more > Caused by: org.codehaus.plexus.archiver.ArchiverException: Problem creating > war: > /opt/continuum-1.0.3/apps/continuum/working-directory/55/target/ROOT/WEB-INF/lib/XmlSchema-1.1.jar > (Too many open files) > at > org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:403) > at > org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchive(AbstractZipArchiver.java:229) > at > org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:332) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:183) > at org.apach
[jira] Closed: (CONTINUUM-752) Create a tag
[ http://jira.codehaus.org/browse/CONTINUUM-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-752. -- Assignee: Emmanuel Venisse Resolution: Won't Fix Fix Version/s: (was: Future) > Create a tag > -- > > Key: CONTINUUM-752 > URL: http://jira.codehaus.org/browse/CONTINUUM-752 > Project: Continuum > Issue Type: Task > Components: Web interface >Affects Versions: 1.1-alpha-1 >Reporter: Emmanuel Venisse >Assignee: Emmanuel Venisse > > Thsi tag will replace in jsp -- 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-751) Create a table tag
[ http://jira.codehaus.org/browse/CONTINUUM-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-751. -- Assignee: Emmanuel Venisse Resolution: Won't Fix Fix Version/s: (was: Future) > Create a table tag > -- > > Key: CONTINUUM-751 > URL: http://jira.codehaus.org/browse/CONTINUUM-751 > Project: Continuum > Issue Type: Task > Components: Web interface >Affects Versions: 1.1-alpha-1 >Reporter: Emmanuel Venisse >Assignee: Emmanuel Venisse >Priority: Minor > > This tag will replace in jsp -- 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-660) One or more module in a project is added twice during adding maven2 projects
[ http://jira.codehaus.org/browse/CONTINUUM-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-660. -- Assignee: Emmanuel Venisse Resolution: Won't Fix Fix Version/s: (was: Future) out of date > One or more module in a project is added twice during adding maven2 projects > > > Key: CONTINUUM-660 > URL: http://jira.codehaus.org/browse/CONTINUUM-660 > Project: Continuum > Issue Type: Bug > Components: Integration - Maven 2 >Affects Versions: 1.0.3 > Environment: Solaris10 on sparc >Reporter: Kaare Nilsen >Assignee: Emmanuel Venisse > Attachments: stacktrace_when_delete.txt > > > In the latest rc when adding a project with multiple modules one or more of > the modules are added twice (duplicated). When this happens there is no way > of deleting one of them eighter so basicly you are stuck with one module > which always will have the "new" state and are never built. > I will attach some log showing what happens when I get to work in the morning -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-87) Poms are written with wrong encodings
[ http://jira.codehaus.org/browse/MRELEASE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MRELEASE-87: -- Affects Version/s: 2.0-beta-5 2.0-beta-6 Fix Version/s: 2.0-beta-7 Patch Submitted: [Yes] > Poms are written with wrong encodings > - > > Key: MRELEASE-87 > URL: http://jira.codehaus.org/browse/MRELEASE-87 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4, 2.0-beta-5, 2.0-beta-6 >Reporter: Carlos Sanchez >Priority: Critical > Fix For: 2.0-beta-7 > > Attachments: MRELEASE-87.diff > > > I have committed a test that works in my Sun and IBM JDKs under windows but > breaks in the Continuum at codehaus. > Tomorrow i'll try with IBM JDK under linux. -- 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-737) Database log contains continuum user passwords in clear text
[ http://jira.codehaus.org/browse/CONTINUUM-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-737. -- Assignee: Emmanuel Venisse Resolution: Won't Fix Fix Version/s: (was: Future) out of date > Database log contains continuum user passwords in clear text > > > Key: CONTINUUM-737 > URL: http://jira.codehaus.org/browse/CONTINUUM-737 > Project: Continuum > Issue Type: Bug > Components: Database >Affects Versions: 1.0.3 >Reporter: Bernhard Wellhöfer >Assignee: Emmanuel Venisse >Priority: Minor > > Hello, > The database log contains the continuum user passwords in clear text. This is > kind of a security issue. > Regards, > Bernd -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-721) JDO Deadlock stack whilst removing a POM
[
http://jira.codehaus.org/browse/CONTINUUM-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse closed CONTINUUM-721.
--
Assignee: Emmanuel Venisse
Resolution: Won't Fix
Fix Version/s: (was: Future)
out of date
> JDO Deadlock stack whilst removing a POM
>
>
> Key: CONTINUUM-721
> URL: http://jira.codehaus.org/browse/CONTINUUM-721
> Project: Continuum
> Issue Type: Bug
> Components: Core system, Database
>Affects Versions: 1.0.3
> Environment: linux amd64
>Reporter: Andy Brook
>Assignee: Emmanuel Venisse
>
> ognl.MethodFailedException: Method "removeProject" failed for object [EMAIL
> PROTECTED] [javax.jdo.JDODataStoreException: Update request failed: UPDATE
> PROJECT SET CHECKOUT_RESULT_SCMRESULT_ID_OID=? WHERE ID=?
> NestedThrowables:
> SQL Exception: A lock could not be obtained due to a deadlock, cycle of locks
> and waiters is:
> Lock : ROW, PROJECT, (3,17)
> Waiting XID : {64696941, X} , SA, UPDATE PROJECT SET
> CHECKOUT_RESULT_SCMRESULT_ID_OID=? WHERE ID=?
> Granted XID : {64696933, X}
> Lock : ROW, BUILDDEFINITION, (3,28)
> Waiting XID : {64696933, X} , SA, INSERT INTO BUILDDEFINITION
> (SCHEDULE_ID_OID,LATEST_BUILD_ID,MODEL_ENCODING,BUILD_FILE,GOALS,DEFAULT_FOR_PROJECT,PROFILE_ID_OID,ARGUMENTS,ID)
> VALUES (?,?,?,?,?,?,?,?,?)
> Granted XID : {64696941, X}
> . The selected victim is XID : 64696941.]
> 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 \
> javax.jdo.JDODataStoreException: Update request failed: UPDATE PROJECT SET
> CHECKOUT_RESULT_SCMRESULT_ID_OID=? WHERE ID=?
> at
> org.jpox.store.rdbms.request.UpdateRequest.execute(UpdateRequest.java:267)
> at org.jpox.store.rdbms.table.ClassTable.update(ClassTable.java:2200)
> at org.jpox.store.StoreManager.update(StoreManager.java:786)
> at org.jpox.state.StateManagerImpl.flush(StateManagerImpl.java:4596)
> at
> org.jpox.AbstractPersistenceManager.flush(AbstractPersistenceManager.java:3167)
> at
> org.jpox.NonmanagedTransaction.getConnection(NonmanagedTransaction.java:235)
> at
> org.jpox.NonmanagedTransaction.getConnection(NonmanagedTransaction.java:204)
> at
> org.jpox.AbstractPersistenceManager.getConnection(AbstractPersistenceManager.java:370)
> at
> org.jpox.store.rdbms.scostore.InverseListStore.clear(InverseListStore.java:986)
> at
> org.jpox.store.mapping.CollectionMapping.preDelete(CollectionMapping.java:304)
> at
> org.jpox.store.mapping.CollectionMapping.deleteDependent(CollectionMapping.java:332)
>
[jira] Updated: (MRELEASE-87) Poms are written with wrong encodings
[ http://jira.codehaus.org/browse/MRELEASE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MRELEASE-87: -- Attachment: MRELEASE-87.diff Here is a patch to use WriterFactory and XmlStreamWriter added in plexus-utils 1.4.5 to handle stream encoding detection according to the XML content written > Poms are written with wrong encodings > - > > Key: MRELEASE-87 > URL: http://jira.codehaus.org/browse/MRELEASE-87 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4, 2.0-beta-5, 2.0-beta-6 >Reporter: Carlos Sanchez >Priority: Critical > Fix For: 2.0-beta-7 > > Attachments: MRELEASE-87.diff > > > I have committed a test that works in my Sun and IBM JDKs under windows but > breaks in the Continuum at codehaus. > Tomorrow i'll try with IBM JDK under linux. -- 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-960) Build definitions relationship with projects is not one to one
[ http://jira.codehaus.org/browse/CONTINUUM-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-960. -- Assignee: Emmanuel Venisse Resolution: Won't Fix this issue is out of date > Build definitions relationship with projects is not one to one > -- > > Key: CONTINUUM-960 > URL: http://jira.codehaus.org/browse/CONTINUUM-960 > Project: Continuum > Issue Type: Bug > Components: Core system, Web interface >Affects Versions: 1.1-alpha-1 >Reporter: Carlos Sanchez >Assignee: Emmanuel Venisse > Fix For: Future > > > The assumption of build definition relationship one to one to project is > wrong now that we have project groups. > It makes more sense to have a N to M > The problem can be seen in input() method > http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-webapp/src/main/java/org/apache/maven/continuum/web/action/BuildDefinitionAction.java?view=markup > Where for a project group build definition it just assumes that the executor > id is the one of the first project, wrong assumption. -- 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-960) Build definitions relationship with projects is not one to one
[ http://jira.codehaus.org/browse/CONTINUUM-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-960. -- Resolution: Fixed Fix Version/s: (was: Future) > Build definitions relationship with projects is not one to one > -- > > Key: CONTINUUM-960 > URL: http://jira.codehaus.org/browse/CONTINUUM-960 > Project: Continuum > Issue Type: Bug > Components: Core system, Web interface >Affects Versions: 1.1-alpha-1 >Reporter: Carlos Sanchez >Assignee: Emmanuel Venisse > > The assumption of build definition relationship one to one to project is > wrong now that we have project groups. > It makes more sense to have a N to M > The problem can be seen in input() method > http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-webapp/src/main/java/org/apache/maven/continuum/web/action/BuildDefinitionAction.java?view=markup > Where for a project group build definition it just assumes that the executor > id is the one of the first project, wrong assumption. -- 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-128) Generate XML-RPC server and client
[ http://jira.codehaus.org/browse/CONTINUUM-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-128. -- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: Future) no longer needed > Generate XML-RPC server and client > -- > > Key: CONTINUUM-128 > URL: http://jira.codehaus.org/browse/CONTINUUM-128 > Project: Continuum > Issue Type: Improvement > Components: Core system, XMLRPC Interface >Reporter: Trygve Laugstol >Assignee: Emmanuel Venisse > -- 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] Reopened: (CONTINUUM-960) Build definitions relationship with projects is not one to one
[ http://jira.codehaus.org/browse/CONTINUUM-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse reopened CONTINUUM-960: > Build definitions relationship with projects is not one to one > -- > > Key: CONTINUUM-960 > URL: http://jira.codehaus.org/browse/CONTINUUM-960 > Project: Continuum > Issue Type: Bug > Components: Core system, Web interface >Affects Versions: 1.1-alpha-1 >Reporter: Carlos Sanchez >Assignee: Emmanuel Venisse > > The assumption of build definition relationship one to one to project is > wrong now that we have project groups. > It makes more sense to have a N to M > The problem can be seen in input() method > http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-webapp/src/main/java/org/apache/maven/continuum/web/action/BuildDefinitionAction.java?view=markup > Where for a project group build definition it just assumes that the executor > id is the one of the first project, wrong assumption. -- 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-938) Prevent user from unsetting default build definitions
[ http://jira.codehaus.org/browse/CONTINUUM-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-938. -- Assignee: Emmanuel Venisse (was: Teodoro Cue Jr.) Resolution: Fixed Fix Version/s: (was: Future) 1.1-alpha-1 > Prevent user from unsetting default build definitions > - > > Key: CONTINUUM-938 > URL: http://jira.codehaus.org/browse/CONTINUUM-938 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1-alpha-1 >Reporter: Carlos Sanchez >Assignee: Emmanuel Venisse > Fix For: 1.1-alpha-1 > > > When trying to save a default build definition unchecking the box an error > occurs. > If it's default it must be disabled, the only way to change the default is by > checking the box in any other build definition. > 2006-09-23 10:43:34,125 [http-8080-Processor20] INFO > Action:update-build-definition-from-project-group - processing this build > definition would result in no default build definition for project group > 2006-09-23 10:43:34,140 [http-8080-Processor20] INFO > Interceptor:exceptionLogging - Error ocurred during execution > org.apache.maven.continuum.ContinuumException: processing this build > definition would result in no default build definition for project group > at > org.apache.maven.continuum.core.action.AbstractBuildDefinitionContinuumAction.resolveDefaultBuildDefinitionsForProjectGroup(AbstractBuildDefinitionContinuumAction.java:112) > at > org.apache.maven.continuum.core.action.UpdateBuildDefinitionFromProjectGroupAction.execute(UpdateBuildDefinitionFromProjectGroupAction.java:46) > at > org.apache.maven.continuum.DefaultContinuum.executeAction(DefaultContinuum.java:2278) > at > org.apache.maven.continuum.DefaultContinuum.updateBuildDefinitionForProjectGroup(DefaultContinuum.java:1430) > at > org.apache.maven.continuum.security.acegi.ContinuumDelegate.updateBuildDefinitionForProjectGroup_aroundBody140(ContinuumDelegate.java:510) > at > org.apache.maven.continuum.security.acegi.ContinuumDelegate$AjcClosure141.run(ContinuumDelegate.java:1) > at > org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0cproceed(SecurityAspect.aj:1) > at > org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect$1.proceedWithObject(SecurityAspect.aj:59) > at > org.acegisecurity.intercept.method.aspectj.AspectJSecurityInterceptor.invoke(AspectJSecurityInterceptor.java:67) > at > org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0c(SecurityAspect.aj:62) > at > org.apache.maven.continuum.security.acegi.ContinuumDelegate.updateBuildDefinitionForProjectGroup(ContinuumDelegate.java:1) > at > org.apache.maven.continuum.web.action.BuildDefinitionAction.saveToGroup(BuildDefinitionAction.java:163) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:364) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:216) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at >
[jira] Closed: (CONTINUUM-882) Exception during shutdown
[ http://jira.codehaus.org/browse/CONTINUUM-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-882. -- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: Future) 1.1-alpha-1 > Exception during shutdown > - > > Key: CONTINUUM-882 > URL: http://jira.codehaus.org/browse/CONTINUUM-882 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.1-alpha-1 > Environment: continuum-acegi > tomcat 5.5 >Reporter: Carlos Sanchez >Assignee: Emmanuel Venisse > Fix For: 1.1-alpha-1 > > > Sep 14, 2006 2:05:55 PM org.apache.catalina.core.AprLifecycleListener > lifecycleEvent > INFO: Failed shutdown of Apache Portable Runtime > Exception in thread "Thread-1" javax.jdo.JDOUserException: Can't access or > use PersistenceManagerFactory after it has been closed. > at > org.jpox.AbstractPersistenceManagerFactory.assertIsOpen(AbstractPersistenceManagerFactory.java:153) > at > org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceManagerFactoryImpl.java:145) > at > org.apache.maven.continuum.store.JdoContinuumStore.getPersistenceManager(JdoContinuumStore.java:1382) > at > org.apache.maven.continuum.store.JdoContinuumStore.updateObject(JdoContinuumStore.java:661) > at > org.apache.maven.continuum.store.JdoContinuumStore.updateSystemConfiguration(JdoContinuumStore.java:1132) > at > org.apache.maven.continuum.configuration.DefaultConfigurationService.store(DefaultConfigurationService.java:279) > at > org.apache.maven.continuum.DefaultContinuum.stopContinuum(DefaultContinuum.java:2195) > at > org.apache.maven.continuum.DefaultContinuum$1.run(DefaultContinuum.java:170) -- 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-1112) Unable to use DB without username and password
[ http://jira.codehaus.org/browse/CONTINUUM-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1112. --- Assignee: Emmanuel Venisse Resolution: Won't Fix Fix Version/s: (was: Future) > Unable to use DB without username and password > -- > > Key: CONTINUUM-1112 > URL: http://jira.codehaus.org/browse/CONTINUUM-1112 > Project: Continuum > Issue Type: Bug > Components: Database >Affects Versions: 1.1-alpha-1 > Environment: mysql jdbc driver 5.0.3, mysql server 5.0.24 >Reporter: Carlos Sanchez >Assignee: Emmanuel Venisse > Attachments: log.txt > > > Changed plexus.conf database definition to use mysql db that anyone can > access (no user / no password) and got an error because it's trying to use a > null username. > java.sql.SQLException: Access denied for user 'null'@'localhost' (using > password: YES) > > jdbc/continuum > javax.sql.DataSource > > > driverClassName > com.mysql.jdbc.Driver > > > url > jdbc:mysql://localhost/test > > > username > > > > password > > > > -- 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-841) Notifier get duplicated during builds
[ http://jira.codehaus.org/browse/CONTINUUM-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-841. -- Assignee: Emmanuel Venisse Resolution: Duplicate > Notifier get duplicated during builds > - > > Key: CONTINUUM-841 > URL: http://jira.codehaus.org/browse/CONTINUUM-841 > Project: Continuum > Issue Type: Bug > Components: Notification Subsystem >Affects Versions: 1.0.3 > Environment: maven 1.1-beta3 on Windows 2000 / JDK 5 >Reporter: nicolas de loof >Assignee: Emmanuel Venisse > Fix For: Future > > Attachments: wrapper.log > > > I receive my failure mail 12 times. Looking at the project configuration in > continuum, my notifier eMail is registered 12 times. I delete all and > register a fresh new email account. After some (failed) builds, it gets > duplicated as notifier. -- 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-924) Add ability to edit group
[ http://jira.codehaus.org/browse/CONTINUUM-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-924. -- Assignee: Emmanuel Venisse (was: Henry S. Isidro) Resolution: Fixed Fix Version/s: (was: Future) 1.1-alpha-1 > Add ability to edit group > - > > Key: CONTINUUM-924 > URL: http://jira.codehaus.org/browse/CONTINUUM-924 > Project: Continuum > Issue Type: Sub-task > Components: Project Grouping >Affects Versions: 1.1-alpha-1 >Reporter: Carlos Sanchez >Assignee: Emmanuel Venisse > Fix For: 1.1-alpha-1 > > > Now that groups are added it'd be nice to have the ability of changing group > name or moving projects from group. -- 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-37) Add a professional user interface
[ http://jira.codehaus.org/browse/CONTINUUM-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-37. - Assignee: Emmanuel Venisse Resolution: Won't Fix Fix Version/s: (was: Future) We'll review it later and will describe what we want to do in a new issue > Add a professional user interface > - > > Key: CONTINUUM-37 > URL: http://jira.codehaus.org/browse/CONTINUUM-37 > Project: Continuum > Issue Type: New Feature > Components: Web interface >Reporter: Emmanuel Venisse >Assignee: Emmanuel Venisse > > I'd like to see a professional interface with some flash components like a > Macromedia Flex interface. > Laszlo provides an open source implementation of this technology (CPL > License). http://www.laszlosystems.com/ > You can see some demo here (http://www.laszlosystems.com/demos/). > The screen creation is very simple, it a very simple xml. > I'll hope you'll be interesting. -- 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-516) Add a wait page when enqueuing projects
[ http://jira.codehaus.org/browse/CONTINUUM-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-516. -- Assignee: Emmanuel Venisse Resolution: Won't Fix Fix Version/s: (was: Future) enqueue is fast > Add a wait page when enqueuing projects > --- > > Key: CONTINUUM-516 > URL: http://jira.codehaus.org/browse/CONTINUUM-516 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Reporter: Emmanuel Venisse >Assignee: Emmanuel Venisse > -- 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-450) Publish the build results to a different machine
[ http://jira.codehaus.org/browse/CONTINUUM-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-450. -- Assignee: Emmanuel Venisse Resolution: Duplicate Duplicate CONTINUUM-1052 > Publish the build results to a different machine > > > Key: CONTINUUM-450 > URL: http://jira.codehaus.org/browse/CONTINUUM-450 > Project: Continuum > Issue Type: New Feature > Components: Notification Subsystem >Affects Versions: 1.0 >Reporter: Carlos Sanchez >Assignee: Emmanuel Venisse > Fix For: Future > > > The build machine won't be usually available to other people, so do something > to publish the build results to a machine that it is available. -- 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-933) Build result page doesn't show changes
[ http://jira.codehaus.org/browse/CONTINUUM-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-933. -- Assignee: Emmanuel Venisse (was: Teodoro Cue Jr.) Resolution: Fixed Fix Version/s: (was: Future) 1.1-alpha-2 > Build result page doesn't show changes > -- > > Key: CONTINUUM-933 > URL: http://jira.codehaus.org/browse/CONTINUUM-933 > Project: Continuum > Issue Type: Bug > Components: SCM, Web interface >Affects Versions: 1.1-alpha-1 > Environment: acegi branch >Reporter: Carlos Sanchez >Assignee: Emmanuel Venisse >Priority: Critical > Fix For: 1.1-alpha-2 > > > I have Plexus XWork Integration in continuum, a build was triggered due some > changes to the pom, > I see no author, date or comment in the changes section > Changes > > AuthorDateComment Files > pom.xml -- 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: (CONTINUUM-1356) intermittent (machine wise) test failure on trunk
[ http://jira.codehaus.org/browse/CONTINUUM-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103705 ] Jesse McConnell commented on CONTINUUM-1356: seems to me that the test case is just wrong, that the profile work altered the test case behavior... what I don't understand is why certain of us don't have the behavior exhibited like it is... > intermittent (machine wise) test failure on trunk > - > > Key: CONTINUUM-1356 > URL: http://jira.codehaus.org/browse/CONTINUUM-1356 > Project: Continuum > Issue Type: Bug > Components: Core - Profiles >Affects Versions: 1.1-beta-1 >Reporter: Jesse McConnell > > I have been noticing an odd test case that has been failing on certain > machines but have been unable to reproduce it locally on my dev box. > Working on a fresh installation on a friends machine I was able to find and > maybe isolate the error with some more output. > Maybe the profile work lately has caused this to happen but some of us have > something installed in our local repo's that suppress the problem. It looks > to me that the creation of a project with a bogus module definition is adding > an additional error to the building results on these machines and with this > output we can see that its not the /test-classes/projects/continuum/pom.xml > artifact causing the problem but the I'm-not-here-project one. > I am making this issue so we have a bit of a record on it and maybe we can > track down why this doesn't manifest on installations such as mine (and I > think emm as well) > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-core/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-model/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-plexus-application/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-web/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-xmlrpc/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-notifiers/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/I'm-not-here-project/pom.xml > add.project.artifact.not.found.error > add.project.missing.pom.error > [ stderr ] --- > [ stacktrace ] --- > junit.framework.AssertionFailedError: expected:<1> but was:<2> > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.failNotEquals(Assert.java:282) > at junit.framework.Assert.assertEquals(Assert.java:64) > at junit.framework.Assert.assertEquals(Assert.java:201) > at junit.framework.Assert.assertEquals(Assert.java:207) > at > org.apache.maven.continuum.project.builder.maven.MavenTwoContinuumPro > jectBuilderTest.testCreateProjectsWithModules(MavenTwoContinuumProjectBuilderTes > t.java:200) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codeh
[jira] Commented: (CONTINUUM-1356) intermittent (machine wise) test failure on trunk
[ http://jira.codehaus.org/browse/CONTINUUM-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103704 ] Christian Gruber commented on CONTINUUM-1356: - Tried it on my mac, and I still get the three failures. All the errors went away after defining JAVA_HOME and M2_HOME. Just the three failures. > intermittent (machine wise) test failure on trunk > - > > Key: CONTINUUM-1356 > URL: http://jira.codehaus.org/browse/CONTINUUM-1356 > Project: Continuum > Issue Type: Bug > Components: Core - Profiles >Affects Versions: 1.1-beta-1 >Reporter: Jesse McConnell > > I have been noticing an odd test case that has been failing on certain > machines but have been unable to reproduce it locally on my dev box. > Working on a fresh installation on a friends machine I was able to find and > maybe isolate the error with some more output. > Maybe the profile work lately has caused this to happen but some of us have > something installed in our local repo's that suppress the problem. It looks > to me that the creation of a project with a bogus module definition is adding > an additional error to the building results on these machines and with this > output we can see that its not the /test-classes/projects/continuum/pom.xml > artifact causing the problem but the I'm-not-here-project one. > I am making this issue so we have a bit of a record on it and maybe we can > track down why this doesn't manifest on installations such as mine (and I > think emm as well) > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-core/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-model/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-plexus-application/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-web/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-xmlrpc/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-notifiers/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/I'm-not-here-project/pom.xml > add.project.artifact.not.found.error > add.project.missing.pom.error > [ stderr ] --- > [ stacktrace ] --- > junit.framework.AssertionFailedError: expected:<1> but was:<2> > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.failNotEquals(Assert.java:282) > at junit.framework.Assert.assertEquals(Assert.java:64) > at junit.framework.Assert.assertEquals(Assert.java:201) > at junit.framework.Assert.assertEquals(Assert.java:207) > at > org.apache.maven.continuum.project.builder.maven.MavenTwoContinuumPro > jectBuilderTest.testCreateProjectsWithModules(MavenTwoContinuumProjectBuilderTes > t.java:200) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) -- 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 in
[jira] Commented: (CONTINUUM-1354) meta refresh causes build loop
[
http://jira.codehaus.org/browse/CONTINUUM-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103699
]
Jesse McConnell commented on CONTINUUM-1354:
there is something in webwork that is suppose to address this actually,
something regarding tokens I think it was...
think there was an interceptor that would eat the request if it had been
submitted already
> meta refresh causes build loop
> --
>
> Key: CONTINUUM-1354
> URL: http://jira.codehaus.org/browse/CONTINUUM-1354
> Project: Continuum
> Issue Type: Bug
> Components: Web interface
>Affects Versions: 1.1-beta-1
> Environment: all
>Reporter: Olivier Lamy
> Fix For: 1.1-beta-2
>
>
> Simple scenario :
> - edit a project group
> - force a project build with the link "Build Now"
> - go to drink some coffe (longer than 5 minutes)
> - some project build have build enqueuing
> It due to the link
> http://${ip}:${pwd}/continuum/buildProject.action?fromGroupPage=true&projectGroupId=15&projectId=79
> The meta refresh force the build.
> As some browser have the tabs, this can cause a lot of not needed builds .
> --
> Olivier
> PS : I will provide a patch next week.
--
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: (CONTINUUM-1355) No admin user found after Tomcat shutdown
[ http://jira.codehaus.org/browse/CONTINUUM-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103698 ] Jesse McConnell commented on CONTINUUM-1355: this sounds like the user database is not getting linked up correctly with tomcat or something.. what database are you using, the derby one or are you setting up jndi goop in tomcat? > No admin user found after Tomcat shutdown > - > > Key: CONTINUUM-1355 > URL: http://jira.codehaus.org/browse/CONTINUUM-1355 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-1 > Environment: Linux, Tomcat 5.5.17 >Reporter: Pavel Halas >Priority: Critical > > Hi, > using the latest snapshot (from yesterday) running on Tomcat 5.5.17. After > the Tomcat kill and running again, Continuum starts with "Create Admin User" > page saying "No admin user found" in the log. > This has been experienced even with the older versions (1.1 snapshots). -- 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: (MPIR-70) NullPointerException when generating Dependencies report
[ http://jira.codehaus.org/browse/MPIR-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MPIR-70. --- Resolution: Fixed Fix Version/s: 2.1 > NullPointerException when generating Dependencies report > > > Key: MPIR-70 > URL: http://jira.codehaus.org/browse/MPIR-70 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Windows, JDK 1.5 >Reporter: Joel Wiegman >Assignee: Dennis Lundberg > Fix For: 2.1 > > Attachments: MPIR-70-minimal.patch, MPIR-70-test-case.zip, > MPIR70-20070716-exec-206.txt, MPIR70-20070716-exec-207.txt > > > The stack trace is attached below. Please note that this is NOT a duplicate > of MPIR-2 (I was told to create a separate issue). Let me know if there's > any other information I can provide. Thanks! > [INFO] Generating "Dependencies" report. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:991) > at java.lang.Double.parseDouble(Double.java:482) > at > org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:375) > at > org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:165) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) > at > org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:140) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:266) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:99) > at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:130) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:97) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2471) Add search box to the index page
[ http://jira.codehaus.org/browse/MNG-2471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103694 ] Denis Cabasson commented on MNG-2471: - Thanks for your comment Jason, but I'm not to any extend a maven comitter :) (only a modello one, and I ain't doing anything on modello right now). Anyway, why was this abandonned? Can you tell me a bit more about what you would like to be done about it? Thanks! > Add search box to the index page > > > Key: MNG-2471 > URL: http://jira.codehaus.org/browse/MNG-2471 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: General >Reporter: Marvin King > Attachments: index-wfocus-woutlogo-wmojocodehausoption.html, > index-with-focus.html, index-without-logo-with-mojocodehausoption.html, > index.html, index[wlogo_wfocus_XHTML].html, > index[wlogo_wfocus_XHTML_CSS2].html, index[wlogo_wfocus_XHTML_CSS].html, > MNG-2471-site.patch, > MNG-2471-site[with_focus_smallsearchbox_withmojocodehausoption].patch, > MNG-2471-site[wlogo_wfocus_XHTML].patch, > site-without-logo-with-mojocodehausoption.css, site[wlogo_wfocus_XHTML].css > > > - google for now -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPIR-70) NullPointerException when generating Dependencies report
[ http://jira.codehaus.org/browse/MPIR-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103693 ] Denis Cabasson commented on MPIR-70: Everything working fine here with the latest snapshot version. Was the highestJdk parameter really interesting? Why wasn't it resolved? Anyway, thanks for the fix Dennis, at least the build is back on the tracks. (I guess status and fix version can be updated) > NullPointerException when generating Dependencies report > > > Key: MPIR-70 > URL: http://jira.codehaus.org/browse/MPIR-70 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Windows, JDK 1.5 >Reporter: Joel Wiegman >Assignee: Dennis Lundberg > Attachments: MPIR-70-minimal.patch, MPIR-70-test-case.zip, > MPIR70-20070716-exec-206.txt, MPIR70-20070716-exec-207.txt > > > The stack trace is attached below. Please note that this is NOT a duplicate > of MPIR-2 (I was told to create a separate issue). Let me know if there's > any other information I can provide. Thanks! > [INFO] Generating "Dependencies" report. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:991) > at java.lang.Double.parseDouble(Double.java:482) > at > org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:375) > at > org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:165) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) > at > org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:140) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:266) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:99) > at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:130) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:97) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3128) Enforcer Plugin Messes Up Dependencies
Enforcer Plugin Messes Up Dependencies -- Key: MNG-3128 URL: http://jira.codehaus.org/browse/MNG-3128 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.7 Reporter: James Carman Attachments: toplevel.zip When using the enforcer plugin, it somehow messes up the dependencies in a reactor-based build. The attached zip file exhibits the problem. Our project structure is a bit weird. We have one top-level project which contains a bunch of modules. One of the modules is a pom-based "tempalte" project which sets up all of our build settings (src/target for the compiler, turns on the aspectj compiler, etc.). All of the other modules extend the "template" project and they themselves have multiple sub-project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3127) Plugins cannot contribute custom ArtifactTransformation objects
Plugins cannot contribute custom ArtifactTransformation objects --- Key: MNG-3127 URL: http://jira.codehaus.org/browse/MNG-3127 Project: Maven 2 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 2.0.5 Reporter: Kohsuke Kawaguchi I was hoping to provide a custom ArtifactTransformation object from a plugin so that I can define the likes of RELEASE and LATEST in my project. But it turns out that because DefaultArtifactTransformationManager is instantiated and composed very early on, even before any plugin gets loaded, DefaultArtifactTransformationManager.artifactTransformations do not get my ArtifactTransformation. Note that the fact that DefaultArtifactTransformationManager is created early on by itself makes sense because to load a plugin you'd need to be able to resolve plugin versions. I think what's really needed here is for DefaultArtifactTransformationManager to have smaller scopes like PerLookup (so that it gets the list of ArtifactTransformation that matches the current context.) -- 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: (MCHANGES-79) Allow for overriding the announcement email from address
[
http://jira.codehaus.org/browse/MCHANGES-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Schwartz updated MCHANGES-79:
---
Attachment: MCHANGES-79-patch.txt
Created patch following the idea of Dennis.
The patch adds an optional property {{fromDeveloperId}} to
{{AnnouncementMailMojo}}.
This property should match the id of one of the developers in the pom. If a
matching developer is found it will be used as the sending developer of the
announcement mail. If there is no such developer the mojo fails with an
exception.
If the property {{fromDeveloperId}} is not given the first developer in the
list is chosen.
No other files than {{AnnouncementMailMojo.java}} are effected by the patch.
> Allow for overriding the announcement email from address
>
>
> Key: MCHANGES-79
> URL: http://jira.codehaus.org/browse/MCHANGES-79
> Project: Maven 2.x Changes Plugin
> Issue Type: New Feature
> Components: announcement
>Reporter: Alexander Schwartz
> Attachments: MCHANGES-79-patch.txt
>
>
> Currently the goal {{changes:announcement-mail}} uses the email address of
> the first developer found in the pom as the from address of the announcement
> email. Very often a project is released by a developer that is not the first
> on in the list of developers in the pom -- which results is an announcement
> email with awron, confusing from address. (Of course one can change the list
> of developers for each release, or add a dummy developer "buildmaster" as the
> first one in the developer list, but this is not my preferred option).
> The maven1 announcement plugin has a parameter {{from}} which allows to
> specify a different from address.
> I suggest to add an optional parameter {{fromAdress}} to the goal
> {{changes:announcement-mail}} of the {{maven-changes-plugin}} such that one
> can specify the sender as follows:
> {noformat}
>
> ...
>
>
>
> org.apache.maven.plugins
> maven-changes-plugin
>
>
> [EMAIL PROTECTED]
>
>
>
>
>
> ...
>
> {noformat}
> If the paremter {{fromAdress}} is given its content is taken as the the
> sender address of the announcement mail. If the option is not specified, the
> fallback is the email address of the first developer in the POM.
--
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: (MRM-428) managed and remote repositories with same name causes problems
[ http://jira.codehaus.org/browse/MRM-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-428: --- Priority: Critical (was: Minor) Fix Version/s: 1.0-beta-1 Issue Type: Bug (was: Improvement) > managed and remote repositories with same name causes problems > -- > > Key: MRM-428 > URL: http://jira.codehaus.org/browse/MRM-428 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-2 >Reporter: Eli Miller >Priority: Critical > Fix For: 1.0-beta-1 > > > I created both a managed and remote repository entry with the name central -- > the intent was for one to proxy the other. The administrative interfaces did > not gripe about using duplicate names but the proxy did not seem to work. In > the logs I found the following information (which looked suspect): > 328579 [SocketListener0-1] DEBUG > org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - > Attempting connector: ProxyConnector[ > source:ArchivaRepository[central,file:/u01/home/proj/.repos/central/] > target:ArchivaRepository[central,file:/u01/home/proj/.repos/central/] > proxyId:mpare > policy[releases]:once > policy[checksum]:fix > policy[snapshots]:disabled > policy[cache-failures]:ignored > ] > When I requested that the remote central repository be deleted, the managed > repository entry was deleted instead. After I removed all central > repositories I created a managed repository named central and a remote > repository named centralExt and the proxying seemed to work as expected. -- 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: (MRM-435) need to review repository defaults
[
http://jira.codehaus.org/browse/MRM-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt updated MRM-435:
---
Fix Version/s: 1.0-beta-2
> need to review repository defaults
> --
>
> Key: MRM-435
> URL: http://jira.codehaus.org/browse/MRM-435
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0-beta-1
>Reporter: Brett Porter
> Fix For: 1.0-beta-2
>
>
> when running the appserver, the default is file:/${appserver.home}/... which
> is incorrect (it should be pre-filled with the value of appserver.home).
> Moreover, it should really be appserver.base, not appserver.home anyway.
--
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: (MRM-438) broken images in the download box on the artifact page
[ http://jira.codehaus.org/browse/MRM-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-438: --- Fix Version/s: 1.0-beta-2 > broken images in the download box on the artifact page > -- > > Key: MRM-438 > URL: http://jira.codehaus.org/browse/MRM-438 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter > Fix For: 1.0-beta-2 > > > these don't appear to work at all in the latest version - it isn't noticeable > in firefox but in ie you get the big white square with an X in it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-437) admin editing of proxy connectors fails in multiple instances
[ http://jira.codehaus.org/browse/MRM-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-437: --- Fix Version/s: 1.0-beta-2 > admin editing of proxy connectors fails in multiple instances > - > > Key: MRM-437 > URL: http://jira.codehaus.org/browse/MRM-437 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter > Fix For: 1.0-beta-2 > > > I've seen the following: > - edit first one and save (order changes) > - edit new first one and save (end up with the same connector for both, eg > the blacklist is duplicated) > - in other circumstances, I'd seen editing the proxy connector produce a > second one > - removing the corresponding remote repository doesn't remove the associated > network proxy. > I believe this entire set of actions needs a review. -- 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: (MRM-436) incorrect default cron expression for snapshots repository
[ http://jira.codehaus.org/browse/MRM-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-436: --- Fix Version/s: 1.0-beta-2 > incorrect default cron expression for snapshots repository > -- > > Key: MRM-436 > URL: http://jira.codehaus.org/browse/MRM-436 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter > Fix For: 1.0-beta-2 > > > it is '0 0' which is not a valid value - it should probably be the same as > for releases -- 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: (MRM-433) Artifacts file types aren't take in account
[ http://jira.codehaus.org/browse/MRM-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-433: --- Fix Version/s: 1.0-beta-2 > Artifacts file types aren't take in account > --- > > Key: MRM-433 > URL: http://jira.codehaus.org/browse/MRM-433 > Project: Archiva > Issue Type: Bug > Components: repository interface >Affects Versions: 1.0-alpha-2 > Environment: maven 2.0.7 >Reporter: Mathieu Godlewski > Fix For: 1.0-beta-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
[jira] Updated: (MRM-432) Proxy Connectors are unable to download artifacts with alpha numerical version numbers
[ http://jira.codehaus.org/browse/MRM-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-432: --- Fix Version/s: 1.0-beta-2 > Proxy Connectors are unable to download artifacts with alpha numerical > version numbers > -- > > Key: MRM-432 > URL: http://jira.codehaus.org/browse/MRM-432 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Affects Versions: 1.0-alpha-2 > Environment: Solaris 5.9, java 1.5.0_11, maven 2.0.7 >Reporter: Mathias Arens > Fix For: 1.0-beta-2 > > > Archiva is unable to download this artifact: > > ch.ethz.ganymed > ganymed-ssh2 > build210 > > although it is in the central repository. I can download the artifact if a > switch the central mirror of, just downloading the artifact directly over > maven. I didn't had any problems with all the other artifacts from the > central repository. > I assume that there is a problem with alpha numerical version numbers. But > it's just a guess. -- 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: (MRM-427) maven-upload-bundle doesn't generate metadata xml files
[ http://jira.codehaus.org/browse/MRM-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-427: --- Affects Version/s: 1.0-alpha-2 Fix Version/s: 1.0.x Should create an archiva-cli component to assign this too. > maven-upload-bundle doesn't generate metadata xml files > --- > > Key: MRM-427 > URL: http://jira.codehaus.org/browse/MRM-427 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-2 >Reporter: Henri Yandell > Fix For: 1.0.x > > > (Putting in MRM for want of anywhere else to record this). > When handling Maven bundles, the maven metadata xml's are not generated nor > updated. -- 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: (MRM-285) change 'main' link for artifact download
[ http://jira.codehaus.org/browse/MRM-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRM-285. Resolution: Fixed Fix Version/s: (was: 1.0.x) 1.0-alpha-2 this was satisfactorily fixed > change 'main' link for artifact download > > > Key: MRM-285 > URL: http://jira.codehaus.org/browse/MRM-285 > Project: Archiva > Issue Type: Improvement > Components: web application >Affects Versions: 1.0-alpha-1 >Reporter: Brett Porter >Priority: Trivial > Fix For: 1.0-alpha-2 > > > I think the 'main' link should be the more prominent - previous design had > just a download button and the source/javadoc were elsewhere in the page. > Perhaps the better solution is to keep them centralised as now, but have a > large download link, then 'other downloads' below it for the source/javadoc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3126) mvn.bat always exits 0 on WinXP
[ http://jira.codehaus.org/browse/MNG-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Gilday closed MNG-3126. -- Resolution: Duplicate Thanks Dan, Marking this as a duplicate. > mvn.bat always exits 0 on WinXP > --- > > Key: MNG-3126 > URL: http://jira.codehaus.org/browse/MNG-3126 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.7 >Reporter: Martin Gilday > > http://jira.codehaus.org/browse/MNG-2127 seems to have started again with > 2.0.7. Regardless of a build passing or failing an %ERRORLVEL%/exit code of > 0 is set. When you change back to 2.0.6 an exir code of 1 is correctly > output for a failure. -- 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: (MRM-207) POM error when indexing an m1 repository
[ http://jira.codehaus.org/browse/MRM-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRM-207. Assignee: Brett Porter (was: Henri Yandell) Resolution: Won't Fix Fix Version/s: (was: 1.0.x) no longer relevant to trunk > POM error when indexing an m1 repository > > > Key: MRM-207 > URL: http://jira.codehaus.org/browse/MRM-207 > Project: Archiva > Issue Type: Bug > Components: indexing >Reporter: Henri Yandell >Assignee: Brett Porter > > org.apache.maven.project.InvalidProjectModelException: Not a v4.0.0 POM. > > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1299) > > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1270) > > org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:471) > > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:225) > > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:235) > > org.apache.maven.archiva.web.action.ShowArtifactAction.readProject(ShowArtifactAction.java:257) > > org.apache.maven.archiva.web.action.ShowArtifactAction.artifact(ShowArtifactAction.java:127) > So seems pretty simple - Archiva is looking for m2 poms in the m1 repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3126) mvn.bat always exits 0 on WinXP
[ http://jira.codehaus.org/browse/MNG-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103670 ] Dan Tran commented on MNG-3126: --- see http://jira.codehaus.org/browse/MNG-3084. You will need to manually patch your local maven-2.0.7 > mvn.bat always exits 0 on WinXP > --- > > Key: MNG-3126 > URL: http://jira.codehaus.org/browse/MNG-3126 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.7 >Reporter: Martin Gilday > > http://jira.codehaus.org/browse/MNG-2127 seems to have started again with > 2.0.7. Regardless of a build passing or failing an %ERRORLVEL%/exit code of > 0 is set. When you change back to 2.0.6 an exir code of 1 is correctly > output for a failure. -- 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: (MRM-412) Add support for maven1 (legacy) request to access a maven2 (default layout) repo
[ http://jira.codehaus.org/browse/MRM-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-412: - Fix Version/s: (was: 1.0.x) 1.0-beta-1 patch to review > Add support for maven1 (legacy) request to access a maven2 (default layout) > repo > > > Key: MRM-412 > URL: http://jira.codehaus.org/browse/MRM-412 > Project: Archiva > Issue Type: Improvement > Components: WebDAV interface >Affects Versions: 1.0-alpha-2 >Reporter: nicolas de loof >Priority: Minor > Fix For: 1.0-beta-1 > > Attachments: archiva-1.0-alpha-2.patch > > > archiva 1.0-alpha-1 doesn't support converting legacy-layout request to > default layout. This behaviour is usefull to allow maven1 to access a maven2 > repository, and avoid having multiple managed repo as proxies to central. > The attached patch add this support : > - it adds to BidirectionalRepositoryLayout the new method boolean > isValidPath( String path ) > - it adds to BidirectionalRepositoryLayoutFactory the new method > BidirectionalRepositoryLayout getLayoutForPath( String path ) > - it use them to detect the layout used by incoming request and build the > ArchivaArtifact object used to proxy the request. It aslo overrides the > pathInfo to make the request point to the real-file path in the managed > repository > BidirectionalRepositoryLayoutFactoryTest also updated -- 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: (MRM-347) Undefined ${appserver.home} and ${appserver.base}
[
http://jira.codehaus.org/browse/MRM-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MRM-347:
-
Fix Version/s: (was: 1.0.x)
1.0-beta-1
> Undefined ${appserver.home} and ${appserver.base}
> -
>
> Key: MRM-347
> URL: http://jira.codehaus.org/browse/MRM-347
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0-alpha-1, 1.0-alpha-2
> Environment: Windows, Maven 2.0.6, JDK 5 or JDK 6
>Reporter: Jan Nielsen
> Fix For: 1.0-beta-1
>
>
> When I run:
> mvn jetty:run
> from trunk at r538691, the "appserver.base" property is undefined, resulting
> in the creation of this directory:
> Directory of C:\dev\apache-maven\archiva\archiva-web\archiva-webapp
> 05/17/2007 02:24 PM ${appserver.base}
> 05/16/2007 11:40 AM 14,681 pom.xml
> 05/16/2007 11:40 AM src
> 05/17/2007 11:06 AM target
--
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: (MRM-408) The mvn deploy:deploy-file command gives "Parent doesn't exist" in a fresh install
[ http://jira.codehaus.org/browse/MRM-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-408: - Fix Version/s: (was: 1.0.x) 1.0-beta-2 seen this too - a major nuisance! > The mvn deploy:deploy-file command gives "Parent doesn't exist" in a fresh > install > -- > > Key: MRM-408 > URL: http://jira.codehaus.org/browse/MRM-408 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-1 > Environment: Archiva 0.9-alpha-2 (bin) >Reporter: Damon Rand > Fix For: 1.0-beta-2 > > > I'm trying to follow the docs at this page. > > http://maven.apache.org/archiva/guides/getting-started/maven-configuration.html > I'm setting security credentials and issuing this command with a pom.xml to > include wagon-webdav > mvn deploy:deploy-file -DgroupId=com.orbeon -DartifactId=blah > -Dversion=3.5.1 -Dpackaging=jar -Dfile=lib/blah.jar > -DrepositoryId=3rdp-releases > -Durl=http://jerboa.intsec.amnesty.org:8081/archiva/repository/3rdp-releases/ > I get this error message > [INFO] Error deploying artifact: Failed to transfer file: > http://jerboa.intsec.a > mnesty.org:8081/archiva/repository/3rdp-releases//com/orbeon/blah/3.5.1/blah-3.5 > .1.jar. Return code is: 409 > An ethereal trace shows this request >PUT /archiva/repository/3rdp-releases/com/orbeon/blah/3.5.1/blah-3.5.1.jar > HTTP/1.1 > And this response.. > > Error 409 Conflict > > Error 409 Conflict > Resource in error: href="http://jerboa.intsec.amnesty.org:8081/archiva/repository/com/orbeon/blah/3.5.1/blah-3.5.1.jar/com/orbeon/blah/3.5.1/blah-3.5.1.jar";> > http://jerboa.intsec.amnesty.org:8081/archiva/repository/com/orbeon/blah/3.5.1/blah-3.5.1.jar/com/orbeon/blah/3.5.1/blah-3.5.1.jar > Exception details: > it.could.webdav.DAVException: Parent doesn't exist > at it.could.webdav.DAVResource.write(DAVResource.java:465) > at it.could.webdav.methods.PUT.process(PUT.java:59) > at it.could.webdav.DAVProcessor.process(DAVProcessor.java:79) > at > org.codehaus.plexus.webdav.simple.SimpleDavServerComponent.process(SimpleDavServerComponent.java:142) > at > org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:156) > at > org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:111) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) > at > com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) > at > com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) > at > com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88) > at > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) > at > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) > at org.mortbay.http.HttpServer.service(HttpServer.java:909) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) > at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) > > > > Note that request and response are very different.. > /archiva/repository/3rdp-releases/com/orbeon/blah/3.5.1/blah-3.5.1.jar > > /archiva/repository/com/orbeon/blah/3.5.1/blah-3.5.1.jar/com/orbeon/blah/3.5.1/blah-3.5.1.jar > Has anyone got this working? I can't imagine how it could work, at least in > the release I have. -- 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
[jira] Commented: (MRM-325) Create web UI tests for Archiva - Maven connection to Archiva
[ http://jira.codehaus.org/browse/MRM-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103666 ] Brett Porter commented on MRM-325: -- Deng, can we close this one now? > Create web UI tests for Archiva - Maven connection to Archiva > - > > Key: MRM-325 > URL: http://jira.codehaus.org/browse/MRM-325 > Project: Archiva > Issue Type: Task >Affects Versions: 1.0-alpha-1 >Reporter: Maria Odea Ching >Assignee: Maria Odea Ching > Fix For: 1.0.x > > > Test: > 1. Using a bad dependency > 2. Using a dependency that is in the snapshot repository > 3. Using a dependency that is in the central (ibiblio) proxied repository > but not yet in the managed repository -- 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: (MRM-220) Guard against null groupIds in metadata during conversion of legacy repositories
[ http://jira.codehaus.org/browse/MRM-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-220: - Assignee: (was: Jason van Zyl) Fix Version/s: (was: 1.0.x) Future > Guard against null groupIds in metadata during conversion of legacy > repositories > > > Key: MRM-220 > URL: http://jira.codehaus.org/browse/MRM-220 > Project: Archiva > Issue Type: Bug > Components: repository converter >Reporter: Jason van Zyl > Fix For: Future > > -- 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: (MRM-309) relocated artifacts are not delivered
[ http://jira.codehaus.org/browse/MRM-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-309: - Fix Version/s: (was: 1.0.x) 1.0-beta-2 > relocated artifacts are not delivered > - > > Key: MRM-309 > URL: http://jira.codehaus.org/browse/MRM-309 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-1 > Environment: latest version from SVN (rev. 521221) > archiva running in tomcat-5.5.17 on a linux system >Reporter: Joerg Vater > Fix For: 1.0-beta-2 > > > One managed repository with two proxied repositories. > When I request an artifact that is relocated in the proxied repository, the > relocaated artifact is downloaded to the local repository but not delivered > to the requestor. > -- log messages: > 2007-03-22 13:32:05,478 8868395 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact > requested is: easymock:easymock:jar:2.0:runtime > 2007-03-22 13:32:05,478 8868395 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving > easymock/easymock/2.0/easymock-2.0.pom from ComBOTS Maven2 Repository > 2007-03-22 13:32:05,478 8868395 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact not > found in repository: ComBOTS Maven2 Repository: File: > /data/maven-repo/combots-maven2-repo/easymock/easymock/2.0/easymock-2.0.pom > does not exist > 2007-03-22 13:32:05,478 8868395 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving > easymock/easymock/2.0/easymock-2.0.pom from Maven2 Central Repository > 2007-03-22 13:32:05,877 8868794 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Successfully > downloaded > 2007-03-22 13:32:05,889 8868806 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact > easymock:easymock:2.0 has been relocated to org.easymock:easymock:2.0 > 2007-03-22 13:32:05,890 8868807 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving > org/easymock/easymock/2.0/easymock-2.0.pom from ComBOTS Maven2 Repository > 2007-03-22 13:32:05,890 8868807 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact not > found in repository: ComBOTS Maven2 Repository: File: > /data/maven-repo/combots-maven2-repo/org/easymock/easymock/2.0/easymock-2.0.pom > does not exist > 2007-03-22 13:32:05,890 8868807 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving > org/easymock/easymock/2.0/easymock-2.0.pom from Maven2 Central Repository > 2007-03-22 13:32:06,157 8869074 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Successfully > downloaded > 2007-03-22 13:32:06,158 8869075 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving > org/easymock/easymock/2.0/easymock-2.0.jar from ComBOTS Maven2 Repository > 2007-03-22 13:32:06,158 8869075 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact not > found in repository: ComBOTS Maven2 Repository: File: > /data/maven-repo/combots-maven2-repo/org/easymock/easymock/2.0/easymock-2.0.jar > does not exist > 2007-03-22 13:32:06,159 8869076 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving > org/easymock/easymock/2.0/easymock-2.0.jar from Maven2 Central Repository > 2007-03-22 13:32:07,017 8869934 [http-9080-Processor25] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Successfully > downloaded > -- html response: > Error 404 Not Found > Resource in error: > http://mavenproxy:9080/archiva/repository/easymock/easymock/2.0/easymock-2.0.jar/easymock/easymock/2.0/easymock-2.0.jar > Exception details: > it.could.webdav.DAVException: Not found > at it.could.webdav.methods.HEAD.process(HEAD.java:52) > at it.could.webdav.methods.GET.process(GET.java:58) > at it.could.webdav.DAVProcessor.process(DAVProcessor.java:79) > at > org.codehaus.plexus.webdav.simple.SimpleDavServerComponent.process(SimpleDavServerComponent.java:142) > at > org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:147) > at > org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:111) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > a
[jira] Closed: (MRM-210) Error while indexing m1 plugin
[
http://jira.codehaus.org/browse/MRM-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MRM-210.
Resolution: Won't Fix
Fix Version/s: (was: 1.0.x)
I believe this is no longer relevant to the trunk codebase.
> Error while indexing m1 plugin
> --
>
> Key: MRM-210
> URL: http://jira.codehaus.org/browse/MRM-210
> Project: Archiva
> Issue Type: Bug
> Components: indexing
> Environment: last from trunk
>Reporter: Arnaud Heritier
>
> trying to index my local m1 repository I encounter the following stacktrace :
> {code}
> java.lang.IllegalStateException: Couldn't find artifact
> E:\Data\maven-1\repository\cargo\plugins\cargo-maven-plugin-0.6.plugin
>
> org.apache.maven.archiva.reporting.LocationArtifactReportProcessor.processArtifact(LocationArtifactReportProcessor.java:143)
>
> org.apache.maven.archiva.reporting.AbstractReportGroup.processArtifact(AbstractReportGroup.java:53)
>
> org.apache.maven.archiva.reporting.DefaultReportExecutor.runArtifactReports(DefaultReportExecutor.java:126)
>
> org.apache.maven.archiva.scheduler.task.IndexerTask.execute(IndexerTask.java:201)
>
> org.apache.maven.archiva.scheduler.task.IndexerTask.execute(IndexerTask.java:122)
>
> org.apache.maven.archiva.scheduler.DefaultRepositoryTaskScheduler.runIndexer(DefaultRepositoryTaskScheduler.java:175)
>
> org.apache.maven.archiva.web.action.admin.RunRepositoryTaskAction.runIndexer(RunRepositoryTaskAction.java:45)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:585)
>
> com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:364)
>
> com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:216)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.apache.maven.archiva.web.interceptor.ConfigurationInterceptor.intercept(ConfigurationInterceptor.java:67)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)
>
> org.codehaus.plexus.security.ui.web.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:141)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)
>
> org.codehaus.plexus.security.ui.web.interceptor.AutoLoginInterceptor.intercept(AutoLoginInterceptor.java:89)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)
>
> org.codehaus.plexus.security.ui.web.interceptor.ForceAdminUserInterceptor.intercept(ForceAdminUserInterceptor.java:59)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)
>
> org.codehaus.plexus.security.ui.web.interceptor.EnvironmentCheckInterceptor.intercept(EnvironmentCheckInterceptor.java:123)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)
>
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168)
>
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)
>
> com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
>
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)
>
> com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)
>
> com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)
>
> com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)
>
> com.opensymphony.webwork.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:171)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)
>
> com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)
>
> com.open
[jira] Updated: (MRM-211) Cannot use Archiva to get Maven1 Plugins
[ http://jira.codehaus.org/browse/MRM-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-211: - Fix Version/s: (was: 1.0.x) 1.0-beta-2 > Cannot use Archiva to get Maven1 Plugins > > > Key: MRM-211 > URL: http://jira.codehaus.org/browse/MRM-211 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Reporter: nicolas de loof > Fix For: 1.0-beta-2 > > Attachments: MRM-211.patch > > > I request maven PMD plugin 1.9 using maven1 > Archiva looks into http://repo1.maven.org/maven2/maven/maven-pmd-plugin/1.9/ > and get the POM -> OK > It then searchs the Artifact as > "maven/maven-pmd-plugin/1.9/maven-pmd-plugin-1.9.plugin" -> NOK > Even looking at maven/maven-pmd-plugin/1.9/maven-pmd-plugin-1.9.jar fails : > the artifact doesn't exist ! It has a POM and a sources-jar but no binary > artifact. Maybe a m1-to-m2 repo-converter error ? -- 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: (MRM-185) revise logging granularity
[ http://jira.codehaus.org/browse/MRM-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-185: - Fix Version/s: (was: 1.0.x) 1.0-beta-2 > revise logging granularity > -- > > Key: MRM-185 > URL: http://jira.codehaus.org/browse/MRM-185 > Project: Archiva > Issue Type: Improvement > Components: system >Reporter: Brett Porter > Fix For: 1.0-beta-2 > > > in particular, check that JPOX logging is at the correct level, but generally > turn the noise down. -- 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: (MRM-243) 507 Insufficient Storage when deploying artifact with webdav
[ http://jira.codehaus.org/browse/MRM-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-243: - Fix Version/s: (was: 1.0.x) 1.0-beta-2 I got this using the plexus runtime. Seems to only happen when running on a Windows box. Path length, perhaps? > 507 Insufficient Storage when deploying artifact with webdav > > > Key: MRM-243 > URL: http://jira.codehaus.org/browse/MRM-243 > Project: Archiva > Issue Type: Bug > Components: web application > Environment: mvn 2.0.4, Windows Server 2003, Tomcat 5.5.17, Sun JDK > 1.5.0_08, archiva HEAD >Reporter: Magne Rasmussen > Fix For: 1.0-beta-2 > > > Sometimes when deploying with dav I get a "507 Insufficient Storage" error. > The artifact (.../group/artifact/version/artifact-version.jar) gets deployed > (with checksums). > The metadata (.../group/artifact/version/maven-metatdata.xml) gets deployed > (with checksums). > It seems to happen when maven tries to upload the updated parent metadata > (.../group/artifact/maven-metadata.xml). The checksums for this metadata > deploys OK. -- 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: (MRM-308) Maven1 requests are not served
[ http://jira.codehaus.org/browse/MRM-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-308: - Fix Version/s: (was: 1.0.x) 1.0-beta-2 > Maven1 requests are not served > -- > > Key: MRM-308 > URL: http://jira.codehaus.org/browse/MRM-308 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-1 > Environment: using latest version from SVN: revision 521221 > archiva running on Tomcat-5.5.17 >Reporter: Joerg Vater > Fix For: 1.0-beta-2 > > > I got one managed repository with two proxied repositories, one for our > locally built artifacts and the central repository. > When I try to retreive an artifact with maven2 path layout (e.g. > ant/ant/1.6.5/ant-1.6.5.jar) everything works fine. > When I try to retreive the same artifact with maven1 path layout > (ant/jars/ant-1.6.5.jar) the jar gets downloaded from the proxied repository > but is not delivered to the client. Client response is a 404 (s. below). In > the local directory it is stored with the maven2 path layout > -- log output: > 2007-03-22 12:20:51,278 4594195 [http-9080-Processor24] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact > requested is: ant:ant:jar:1.6.5:runtime > 2007-03-22 12:20:51,279 4594196 [http-9080-Processor24] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving > ant/ant/1.6.5/ant-1.6.5.pom from ComBOTS Maven2 Repository > 2007-03-22 12:20:51,279 4594196 [http-9080-Processor24] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Artifact not > found in repository: ComBOTS Maven2 Repository: File: > /data/maven-repo/combots-maven2-repo/ant/ant/1.6.5/ant-1.6.5.pom does not > exist > 2007-03-22 12:20:51,281 4594198 [http-9080-Processor24] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Retrieving > ant/ant/1.6.5/ant-1.6.5.pom from Maven2 Central Repository > 2007-03-22 12:20:51,728 4594645 [http-9080-Processor24] DEBUG > org.apache.maven.archiva.proxy.ProxyRequestHandler:default - Successfully > downloaded > -- http response: > Error 404 Not Found > Resource in error: > http://mavenproxy:9080/archiva/repository/ant/jars/ant-1.6.5.jar/ant/jars/ant-1.6.5.jar > Exception details: > it.could.webdav.DAVException: Not found > at it.could.webdav.methods.HEAD.process(HEAD.java:52) > at it.could.webdav.methods.GET.process(GET.java:58) > at it.could.webdav.DAVProcessor.process(DAVProcessor.java:79) > at > org.codehaus.plexus.webdav.simple.SimpleDavServerComponent.process(SimpleDavServerComponent.java:142) > at > org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:147) > at > org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:111) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) > at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHan
[jira] Updated: (MRM-218) When converting legacy repositories create the checksums for for metadata files
[ http://jira.codehaus.org/browse/MRM-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-218: - Assignee: (was: Jason van Zyl) Fix Version/s: (was: 1.0.x) Future no longer a shared thing, but the archiva converter isn't wired in to the main application for 1.0 (just a separate tool) > When converting legacy repositories create the checksums for for metadata > files > --- > > Key: MRM-218 > URL: http://jira.codehaus.org/browse/MRM-218 > Project: Archiva > Issue Type: New Feature > Components: repository converter >Reporter: Jason van Zyl > Fix For: Future > > -- 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: (DOXIA-130) Macro renaming
[
http://jira.codehaus.org/browse/DOXIA-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed DOXIA-130.
-
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: (was: 1.0-beta-1)
1.0-alpha-9
Fixed.
Now to call a macro in xdoc, you should write the following:
{noformat}
http://myserver/path/to/file.txt"/>
{noformat}
> Macro renaming
> --
>
> Key: DOXIA-130
> URL: http://jira.codehaus.org/browse/DOXIA-130
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Xdoc
>Affects Versions: 1.0-alpha-9
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 1.0-alpha-9
>
>
> Something like the following:
> {code:xml}
>
>
> http://myserver.org/toto.xml"/>
>
> {code}
> instead of:
> {code:xml}
> http://myserver.org/toto.xml"/>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-346) build failure when there is any class with name matching the test pattern, but is not a testcase
build failure when there is any class with name matching the test pattern, but is not a testcase Key: SUREFIRE-346 URL: http://jira.codehaus.org/browse/SUREFIRE-346 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.3 Reporter: Domingos Creado When there is a class (or classes) that match the name pattern (Test* ou *Test), but it is not a testcase, like for example a helper class or a mock, the plugin tries to instantiate it. The plugin could check if the class is assignable to a test case prior trying to instantiate it. [INFO] [surefire:test] [INFO] Surefire report directory: c:\views\Clearing_1.0\GSUP2\Clearing\Implementacao\ctup-web-app\target\surefire-reports org.apache.maven.surefire.booter.SurefireExecutionException: Unable to instantiate POJO 'class br.com.cpqd.ctup.batch.cdrinterno.filtros.FonteDadosTest'; nested exception is java.lang.InstantiationException: br.com.cpqd.ctup.batch.cdrinterno.filtros.FonteDadosTest; nested exception is org.apache.maven.surefire.testset.TestSetFailedException: Unable to instantiate POJO 'class br.com.cpqd.ctup.batch.cdrinterno.filtros.FonteDadosTest'; nested exception is java.lang.InstantiationException: br.com.cpqd.ctup.batch.cdrinterno.filtros.FonteDadosTestorg.apache.maven.surefire.testset.TestSetFailedException: Unable to instantiate POJO 'class br.com.cpqd.ctup.batch.cdrinterno.filtros.FonteDadosTest'; nested exception is java.lang.InstantiationException: br.com.cpqd.ctup.batch.cdrinterno.filtros.FonteDadosTest java.lang.InstantiationException: br.com.cpqd.ctup.batch.cdrinterno.filtros.FonteDadosTest at java.lang.Class.newInstance0(Class.java:340) at java.lang.Class.newInstance(Class.java:308) at org.apache.maven.surefire.testset.PojoTestSet.(PojoTestSet.java:55) at org.apache.maven.surefire.junit.JUnitDirectoryTestSuite.createTestSet(JUnitDirectoryTestSuite.java:64) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:150) at org.apache.maven.surefire.Surefire.run(Surefire.java:111) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j ava:818) [INFO] [ERROR] BUILD FAILURE -- 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: (MAVENUPLOAD-1651) junit 4.4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103648 ] Mauro Talevi commented on MAVENUPLOAD-1651: --- Unless junit decide to change their packaging strategy, I would opt to keep junit artifact as is and create a separate artifact, junit-dep, in which the junit jar is stripped of its hamcrest dependencies, and has a transitive dependency on hamcrest-1.1 artifacts. Regardless though of future junit decisions, being that junit 4.4 has been released, I would think this is only viable option ATM. > junit 4.4 > - > > Key: MAVENUPLOAD-1651 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1651 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Tomislav Stojcevich > Attachments: junit-4.4-bundle.jar, junit-4.4-bundle.jar > > > Upload new version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-774) Better support for multiprojects
[
http://jira.codehaus.org/browse/CONTINUUM-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103646
]
Radakovic Stevan commented on CONTINUUM-774:
Modules section from pom:
modules/jaas_security
modules/outlook
modules/ssh-cm
modules/webconference-common
modules/webconference
modules/telephonyadapter
modules/userweb
modules/directoryservice
modules/primaryserver
modules/ipphone
scm:
scm:clearcase:${user.home}/.default.configspec
Well, what occured to me is that the problem might be the fact that the pom.xml
isn't actually a file but a symbolic link to master_pom.xml which is elsewhere
(dir below). That didn't bother me before(i.e. during the adding of the
project), but it's only a thought.
Thanks,
Stevan
> Better support for multiprojects
>
>
> Key: CONTINUUM-774
> URL: http://jira.codehaus.org/browse/CONTINUUM-774
> Project: Continuum
> Issue Type: Improvement
> Components: Project Grouping
>Reporter: Tomasz Pik
>Assignee: Emmanuel Venisse
>Priority: Minor
> Fix For: 1.1-beta-1
>
> Attachments: CONTINUUM-774
>
>
> Currently when multiproject is being added to continuum, then top project is
> being registered as 'non-recursive' and all submodules are being added as
> separate projects.
> It will be nice to have the possibility to define (during initiial POM
> loading) if project should be treat that way or as a multiproject with full
> recursive build and without adding subprojects.
> I'm doing that manually, by redefining build section for top project and
> removing subprojects.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3126) mvn.bat always exits 0 on WinXP
mvn.bat always exits 0 on WinXP --- Key: MNG-3126 URL: http://jira.codehaus.org/browse/MNG-3126 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 2.0.7 Reporter: Martin Gilday http://jira.codehaus.org/browse/MNG-2127 seems to have started again with 2.0.7. Regardless of a build passing or failing an %ERRORLVEL%/exit code of 0 is set. When you change back to 2.0.6 an exir code of 1 is correctly output for a failure. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2127) mvn.bat always exits 0 on Windows 2000 and higher
[ http://jira.codehaus.org/browse/MNG-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103645 ] Martin Gilday commented on MNG-2127: What is the situation with this on WinXP SP2, with Maven 2.0.7? I have set MAVEN_TERMINATE_CMD=on and regardless of which command I run I am always getting %ERRORLEVEL% as 0. > mvn.bat always exits 0 on Windows 2000 and higher > - > > Key: MNG-2127 > URL: http://jira.codehaus.org/browse/MNG-2127 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0, 2.0.1, 2.0.2 > Environment: I'm on Windows 2003 Server, but this will affect any OS > for which the %OS% environment variable is Windows_NT, including Windows XP > and Windows 2000. >Reporter: Dan Fabulich >Assignee: Brett Porter >Priority: Blocker > Attachments: maven-task.xml, mvnfixed.bat, mvnfixed.bat > > > Write the following ant script and run it on Windows 2000 or higher: > failonerror="true" /> > This will run "mvn" with no arguments, which will always fail. But the ant > script will claim "build successful", because the exit value of mvn.bat was > 0. It is absolutely critical that this work correctly, or else I can't > integrate Maven into any other automated system. > This is happening because mvn.bat is improperly abusing local scoping. On > line 130 of mvn.bat, we execute maven, but we don't do anything with its exit > value... we just always goto end. The fix for this is to add a line 131 that > says "if errorlevel 1 goto error", which will behave correctly. > (I marked this as having a test case because I've included a test ant script, > but technically this isn't a JUnit test case, so it may be an inappropriate > use of the "testcase included" marker.) -- 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: (MECLIPSE-311) Project build error null
[
http://jira.codehaus.org/browse/MECLIPSE-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Hart closed MECLIPSE-311.
Resolution: Won't Fix
sorry i selected the wrong project
see MNGECLIPSE-380 for the problem
> Project build error null
>
>
> Key: MECLIPSE-311
> URL: http://jira.codehaus.org/browse/MECLIPSE-311
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
>Reporter: Thomas Hart
>Priority: Critical
>
> In the problem view is a {{Project build error null}} entry for a pom.xml
> file. Also on the console i get the same message. I don't know why it
> happens. I have 126 POM Files and sometimes some of these get this error
> message.
> Plugin Version: 0.0.11.20070603-1200
--
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: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103643 ] Lars Duvaas commented on MIDEA-102: --- It appears that the bug only occurs in maven 2.0.7.. When I run the goal in maven 2.0.6 it works fine. > CLONE -still broken - Module filepath is generated incorrectly > -- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRM-143) improve error reporting on corrupt jars, poms, etc
[ http://jira.codehaus.org/browse/MRM-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103642 ] Maria Odea Ching edited comment on MRM-143 at 7/31/07 4:48 AM: --- The corrupt artifacts/poms are included in the reporting in MRM-329. These are added to the database as RepositoryProblem(s) (during validation) and can be retrieved via the CorrupArtifactReport. This issue can be closed when MRM-329 is completed. was: The corrupt artifacts/poms are included in the reporting in MRM-329. These are added to the database as RepositoryProblem(s) (during validation) and can be retrieved via the CorrupArtifactReport. > improve error reporting on corrupt jars, poms, etc > -- > > Key: MRM-143 > URL: http://jira.codehaus.org/browse/MRM-143 > Project: Archiva > Issue Type: Improvement > Components: indexing >Reporter: Brett Porter >Assignee: Maria Odea Ching > Fix For: 1.0-beta-1 > > > currently, many failures can be detected during indexing but none are > reported anywhere other than the logs. Either these need to be sent through > the regular reporting mechanism, or the regular reporting mechanism needs to > be able to come back later and pick up the same issues. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRM-143) improve error reporting on corrupt jars, poms, etc
[ http://jira.codehaus.org/browse/MRM-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103642 ] Maria Odea Ching edited comment on MRM-143 at 7/31/07 4:48 AM: --- The corrupt artifacts/poms are included in the reporting in MRM-329. These are added to the database as RepositoryProblem(s) (during validation) and can be retrieved via the CorrupArtifactReport. was: This can be closed when MRM-329 is completed. The corrupt poms/artifacts are added to the database (during validation) and can be retrieved via the CorrupArtifactReport. > improve error reporting on corrupt jars, poms, etc > -- > > Key: MRM-143 > URL: http://jira.codehaus.org/browse/MRM-143 > Project: Archiva > Issue Type: Improvement > Components: indexing >Reporter: Brett Porter >Assignee: Maria Odea Ching > Fix For: 1.0-beta-1 > > > currently, many failures can be detected during indexing but none are > reported anywhere other than the logs. Either these need to be sent through > the regular reporting mechanism, or the regular reporting mechanism needs to > be able to come back later and pick up the same issues. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-143) improve error reporting on corrupt jars, poms, etc
[ http://jira.codehaus.org/browse/MRM-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103642 ] Maria Odea Ching commented on MRM-143: -- This can be closed when MRM-329 is completed. The corrupt poms/artifacts are added to the database (during validation) and can be retrieved via the CorrupArtifactReport. > improve error reporting on corrupt jars, poms, etc > -- > > Key: MRM-143 > URL: http://jira.codehaus.org/browse/MRM-143 > Project: Archiva > Issue Type: Improvement > Components: indexing >Reporter: Brett Porter >Assignee: Maria Odea Ching > Fix For: 1.0-beta-1 > > > currently, many failures can be detected during indexing but none are > reported anywhere other than the logs. Either these need to be sent through > the regular reporting mechanism, or the regular reporting mechanism needs to > be able to come back later and pick up the same issues. -- 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
