[jira] Created: (MECLIPSE-125) Review Eclipse Plugin Site Documentation
Review Eclipse Plugin Site Documentation Key: MECLIPSE-125 URL: http://jira.codehaus.org/browse/MECLIPSE-125 Project: Maven 2.x Eclipse Plugin Type: Improvement Versions: 2.2 Reporter: Edwin Punzalan Assigned to: Edwin Punzalan Fix For: 2.3 Also, apply docck rules -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSUREFIREREP-24) Review Plugin Documentation
Review Plugin Documentation --- Key: MSUREFIREREP-24 URL: http://jira.codehaus.org/browse/MSUREFIREREP-24 Project: Maven 2.x Surefire report Plugin Type: Task Reporter: Allan Ramirez Assigned to: Allan Ramirez -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MASSEMBLY-122) Apply docck rules to the assembly plugin
[ http://jira.codehaus.org/browse/MASSEMBLY-122?page=all ] Edwin Punzalan updated MASSEMBLY-122: - Assign To: Edwin Punzalan Remaining Estimate: 1 day, 9 hours Original Estimate: 1 day, 9 hours Apply docck rules to the assembly plugin Key: MASSEMBLY-122 URL: http://jira.codehaus.org/browse/MASSEMBLY-122 Project: Maven 2.x Assembly Plugin Type: Improvement Versions: 2.1 Reporter: Edwin Punzalan Assignee: Edwin Punzalan Original Estimate: 1 day, 9 hours Remaining: 1 day, 9 hours -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-158) Review and revise plugin documentation
Review and revise plugin documentation -- Key: MSITE-158 URL: http://jira.codehaus.org/browse/MSITE-158 Project: Maven 2.x Site Plugin Type: Task Reporter: Maria Odea Ching Assigned to: Maria Odea Ching -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHECKSTYLE-49) Review and revise plugin documentation
Review and revise plugin documentation -- Key: MCHECKSTYLE-49 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-49 Project: Maven 2.x Checkstyle Plugin Type: Task Reporter: Maria Odea Ching Assigned to: Maria Odea Ching -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSUREFIRE-147) Review Plugin Documentation
Review Plugin Documentation --- Key: MSUREFIRE-147 URL: http://jira.codehaus.org/browse/MSUREFIRE-147 Project: Maven 2.x Surefire Plugin Type: Task Reporter: Allan Ramirez -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSUREFIRE-147) Review Plugin Documentation
[ http://jira.codehaus.org/browse/MSUREFIRE-147?page=all ] Allan Ramirez updated MSUREFIRE-147: Assign To: Allan Ramirez Remaining Estimate: 15 hours Original Estimate: 15 hours Review Plugin Documentation --- Key: MSUREFIRE-147 URL: http://jira.codehaus.org/browse/MSUREFIRE-147 Project: Maven 2.x Surefire Plugin Type: Task Reporter: Allan Ramirez Assignee: Allan Ramirez Original Estimate: 15 hours Remaining: 15 hours -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MVERIFIER-2) review plugin documentation
review plugin documentation --- Key: MVERIFIER-2 URL: http://jira.codehaus.org/browse/MVERIFIER-2 Project: Maven 2.x Verifier Plugin Type: Task Reporter: Marvin King Assigned to: Marvin King -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-218) review plugin documentation
review plugin documentation --- Key: SCM-218 URL: http://jira.codehaus.org/browse/SCM-218 Project: Maven SCM Type: Task Components: maven-plugin Reporter: Marvin King -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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] Créée: (MPECLIPSE-120) No source path is created for integrationUnitTestSourceDirectory
No source path is created for integrationUnitTestSourceDirectory Key: MPECLIPSE-120 URL: http://jira.codehaus.org/browse/MPECLIPSE-120 Project: maven-eclipse-plugin Type: Bug Versions: 1.11 Reporter: nicolas de loof Priority: Minor Fix For: 1.11.1 A project that includes a integrationUnitTestSourceDirectory element has no source path created by the plugin in eclipse .classpath A workaround is to set maven.eclipse.classpath.include -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-218) review plugin documentation
[ http://jira.codehaus.org/browse/SCM-218?page=all ] Marvin King updated SCM-218: Assign To: Marvin King Due Date: 19/Jul/06 Remaining Estimate: 1 day, 5 hours Original Estimate: 1 day, 5 hours review plugin documentation --- Key: SCM-218 URL: http://jira.codehaus.org/browse/SCM-218 Project: Maven SCM Type: Task Components: maven-plugin Reporter: Marvin King Assignee: Marvin King Original Estimate: 1 day, 5 hours Remaining: 1 day, 5 hours -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRAR-12) Review Plugin Documentation
[ http://jira.codehaus.org/browse/MRAR-12?page=comments#action_69553 ] Allan Ramirez commented on MRAR-12: --- for review.. Thanks Review Plugin Documentation --- Key: MRAR-12 URL: http://jira.codehaus.org/browse/MRAR-12 Project: Maven 2.x Rar Plugin Type: Task Reporter: Allan Ramirez Assignee: Allan Ramirez Original Estimate: 14 hours Time Spent: 16 hours Remaining: 0 minutes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MECLIPSE-125) Review Eclipse Plugin Site Documentation
[ http://jira.codehaus.org/browse/MECLIPSE-125?page=all ] Edwin Punzalan updated MECLIPSE-125: Due Date: 17/Jul/06 Review Eclipse Plugin Site Documentation Key: MECLIPSE-125 URL: http://jira.codehaus.org/browse/MECLIPSE-125 Project: Maven 2.x Eclipse Plugin Type: Improvement Versions: 2.2 Reporter: Edwin Punzalan Assignee: Edwin Punzalan Fix For: 2.3 Original Estimate: 1 day, 3 hours Remaining: 1 day, 3 hours Also, apply docck rules -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MASSEMBLY-122) Apply docck rules to the assembly plugin
[ http://jira.codehaus.org/browse/MASSEMBLY-122?page=all ] Edwin Punzalan updated MASSEMBLY-122: - Due Date: 20/Jul/06 Apply docck rules to the assembly plugin Key: MASSEMBLY-122 URL: http://jira.codehaus.org/browse/MASSEMBLY-122 Project: Maven 2.x Assembly Plugin Type: Improvement Versions: 2.1 Reporter: Edwin Punzalan Assignee: Edwin Punzalan Original Estimate: 1 day, 9 hours Remaining: 1 day, 9 hours -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-140) Tests fail during release:perform but work elsewhere
Tests fail during release:perform but work elsewhere
Key: MRELEASE-140
URL: http://jira.codehaus.org/browse/MRELEASE-140
Project: Maven 2.x Release Plugin
Type: Bug
Versions: 2.0-beta-4
Environment: Maven 2.0.4. Linux
Reporter: Adrian
Priority: Blocker
Attachments: TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml,
com.dolby.pics.core.ejb.bean.CountryBeanTestCase.txt, perform-output
h2. Summary
I have a project that builds successfully when {{mvn clean install}} is
executed.
When {{mvn clean release:prepare}} is executed the integration tests run
successfully too.
When {{mvn release:perform}} is executed the junit tests using surefire fail.
h2. Details
h3. The project layout
The project is an EJB 3 project. The unit tests bootstrap/startup an embedded
EJB container to test the EJBs. The container is configured via a set of xml
and property files that are specified in the testResources section of the pom.
The embedded container is a dependency of the project with _test_ scope.
h3. release:perform output
The output of the release:perform goal is attached to this issue.
h3. surefire junit test report
The output of the release:perform goal is attached to this issue. A snippet is
shown here:
{code}
---
Battery: com.dolby.pics.core.ejb.bean.CountryBeanTestCase
---
Tests run: 11, Failures: 0, Errors: 11, Time elapsed: 7.234 sec
testGetAll(com.dolby.pics.core.ejb.bean.CountryBeanTestCase) Time elapsed:
2.255 sec ERROR!
[ stdout ] ---
[ stderr ] ---
[ stacktrace ] ---
java.lang.RuntimeException: org.jboss.xb.binding.JBossXBRuntimeException:
Failed to create a new SAX parser
at
org.jboss.ejb3.embedded.EJB3StandaloneBootstrap.boot(EJB3StandaloneBootstrap.java:391)
at
com.dolby.pics.test.AbstractEJBTestCase.startupEmbeddedJboss(AbstractEJBTestCase.java:63)
at
com.dolby.pics.test.AbstractEJBTestCase.setUp(AbstractEJBTestCase.java:145)
at
com.dolby.pics.core.ejb.bean.CountryBeanTestCase.setUp(CountryBeanTestCase.java:43)
at junit.framework.TestCase.runBare(TestCase.java:128)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:228)
at junit.framework.TestSuite.run(TestSuite.java:223)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:242)
at
org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:216)
at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215)
at org.apache.maven.surefire.Surefire.run(Surefire.java:163)
at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.SurefireBooter.runTestsInProcess(SurefireBooter.java:313)
at org.apache.maven.surefire.SurefireBooter.run(SurefireBooter.java:221)
at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:371)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
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)
[jira] Created: (MNG-2437) pom.xml for Spring 1.2.8 missing from Ibiblio
pom.xml for Spring 1.2.8 missing from Ibiblio - Key: MNG-2437 URL: http://jira.codehaus.org/browse/MNG-2437 Project: Maven 2 Type: Bug Environment: Any Reporter: Anthony Hilario Priority: Blocker As stated in the summary, the pom.xml and associated checksum files are missing from Ibiblio, preventing download of that dependency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-140) Tests fail during release:perform but work elsewhere
[ http://jira.codehaus.org/browse/MRELEASE-140?page=all ]
Adrian updated MRELEASE-140:
Attachment:
WORKING-TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml
Tests fail during release:perform but work elsewhere
Key: MRELEASE-140
URL: http://jira.codehaus.org/browse/MRELEASE-140
Project: Maven 2.x Release Plugin
Type: Bug
Versions: 2.0-beta-4
Environment: Maven 2.0.4. Linux
Reporter: Adrian
Priority: Blocker
Attachments: TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml,
WORKING-TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml,
com.dolby.pics.core.ejb.bean.CountryBeanTestCase.txt, perform-output
h2. Summary
I have a project that builds successfully when {{mvn clean install}} is
executed.
When {{mvn clean release:prepare}} is executed the integration tests run
successfully too.
When {{mvn release:perform}} is executed the junit tests using surefire fail.
h2. Details
h3. The project layout
The project is an EJB 3 project. The unit tests bootstrap/startup an embedded
EJB container to test the EJBs. The container is configured via a set of xml
and property files that are specified in the testResources section of the
pom. The embedded container is a dependency of the project with _test_ scope.
h3. release:perform output
The output of the release:perform goal is attached to this issue.
h3. surefire junit test report
The output of the release:perform goal is attached to this issue. A snippet
is shown here:
{code}
---
Battery: com.dolby.pics.core.ejb.bean.CountryBeanTestCase
---
Tests run: 11, Failures: 0, Errors: 11, Time elapsed: 7.234 sec
testGetAll(com.dolby.pics.core.ejb.bean.CountryBeanTestCase) Time elapsed:
2.255 sec ERROR!
[ stdout ] ---
[ stderr ] ---
[ stacktrace ] ---
java.lang.RuntimeException: org.jboss.xb.binding.JBossXBRuntimeException:
Failed to create a new SAX parser
at
org.jboss.ejb3.embedded.EJB3StandaloneBootstrap.boot(EJB3StandaloneBootstrap.java:391)
at
com.dolby.pics.test.AbstractEJBTestCase.startupEmbeddedJboss(AbstractEJBTestCase.java:63)
at
com.dolby.pics.test.AbstractEJBTestCase.setUp(AbstractEJBTestCase.java:145)
at
com.dolby.pics.core.ejb.bean.CountryBeanTestCase.setUp(CountryBeanTestCase.java:43)
at junit.framework.TestCase.runBare(TestCase.java:128)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:228)
at junit.framework.TestSuite.run(TestSuite.java:223)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:242)
at
org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:216)
at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215)
at org.apache.maven.surefire.Surefire.run(Surefire.java:163)
at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.SurefireBooter.runTestsInProcess(SurefireBooter.java:313)
at org.apache.maven.surefire.SurefireBooter.run(SurefireBooter.java:221)
at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:371)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
[jira] Commented: (MRELEASE-140) Tests fail during release:perform but work elsewhere
[ http://jira.codehaus.org/browse/MRELEASE-140?page=comments#action_69559 ]
Adrian commented on MRELEASE-140:
-
Note that in the working junit xml test report the java.class.path is set as
follows:
{code:xml}property
value=/home/apill/.m2/repository/org/apache/maven/surefire/surefire-api/2.0/surefire-api-2.0.jar:/home/apill/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar:/home/apill/.m2/repository/org/apache/maven/surefire/surefire-booter/2.0/surefire-booter-2.0.jar
name=java.class.path/{code}
and in the broken test it is
{code:xml}property value=/usr/local/apps/maven/core/boot/classworlds-1.1.jar
name=java.class.path/{code}
This may be a red herring though?
Tests fail during release:perform but work elsewhere
Key: MRELEASE-140
URL: http://jira.codehaus.org/browse/MRELEASE-140
Project: Maven 2.x Release Plugin
Type: Bug
Versions: 2.0-beta-4
Environment: Maven 2.0.4. Linux
Reporter: Adrian
Priority: Blocker
Attachments: TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml,
WORKING-TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml,
com.dolby.pics.core.ejb.bean.CountryBeanTestCase.txt, perform-output
h2. Summary
I have a project that builds successfully when {{mvn clean install}} is
executed.
When {{mvn clean release:prepare}} is executed the integration tests run
successfully too.
When {{mvn release:perform}} is executed the junit tests using surefire fail.
h2. Details
h3. The project layout
The project is an EJB 3 project. The unit tests bootstrap/startup an embedded
EJB container to test the EJBs. The container is configured via a set of xml
and property files that are specified in the testResources section of the
pom. The embedded container is a dependency of the project with _test_ scope.
h3. release:perform output
The output of the release:perform goal is attached to this issue.
h3. surefire junit test report
The output of the release:perform goal is attached to this issue. A snippet
is shown here:
{code}
---
Battery: com.dolby.pics.core.ejb.bean.CountryBeanTestCase
---
Tests run: 11, Failures: 0, Errors: 11, Time elapsed: 7.234 sec
testGetAll(com.dolby.pics.core.ejb.bean.CountryBeanTestCase) Time elapsed:
2.255 sec ERROR!
[ stdout ] ---
[ stderr ] ---
[ stacktrace ] ---
java.lang.RuntimeException: org.jboss.xb.binding.JBossXBRuntimeException:
Failed to create a new SAX parser
at
org.jboss.ejb3.embedded.EJB3StandaloneBootstrap.boot(EJB3StandaloneBootstrap.java:391)
at
com.dolby.pics.test.AbstractEJBTestCase.startupEmbeddedJboss(AbstractEJBTestCase.java:63)
at
com.dolby.pics.test.AbstractEJBTestCase.setUp(AbstractEJBTestCase.java:145)
at
com.dolby.pics.core.ejb.bean.CountryBeanTestCase.setUp(CountryBeanTestCase.java:43)
at junit.framework.TestCase.runBare(TestCase.java:128)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:228)
at junit.framework.TestSuite.run(TestSuite.java:223)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:242)
at
org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:216)
at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215)
at org.apache.maven.surefire.Surefire.run(Surefire.java:163)
at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.SurefireBooter.runTestsInProcess(SurefireBooter.java:313)
at org.apache.maven.surefire.SurefireBooter.run(SurefireBooter.java:221)
at
[jira] Commented: (MRELEASE-140) Tests fail during release:perform but work elsewhere
[ http://jira.codehaus.org/browse/MRELEASE-140?page=comments#action_69560 ]
Adrian commented on MRELEASE-140:
-
bq. This file is the equivelent to
TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml but the output that
is given when the tests compile successfully.
My comment quoted above is referring to the attached file
WORKING-TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml
Tests fail during release:perform but work elsewhere
Key: MRELEASE-140
URL: http://jira.codehaus.org/browse/MRELEASE-140
Project: Maven 2.x Release Plugin
Type: Bug
Versions: 2.0-beta-4
Environment: Maven 2.0.4. Linux
Reporter: Adrian
Priority: Blocker
Attachments: TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml,
WORKING-TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml,
com.dolby.pics.core.ejb.bean.CountryBeanTestCase.txt, perform-output
h2. Summary
I have a project that builds successfully when {{mvn clean install}} is
executed.
When {{mvn clean release:prepare}} is executed the integration tests run
successfully too.
When {{mvn release:perform}} is executed the junit tests using surefire fail.
h2. Details
h3. The project layout
The project is an EJB 3 project. The unit tests bootstrap/startup an embedded
EJB container to test the EJBs. The container is configured via a set of xml
and property files that are specified in the testResources section of the
pom. The embedded container is a dependency of the project with _test_ scope.
h3. release:perform output
The output of the release:perform goal is attached to this issue.
h3. surefire junit test report
The output of the release:perform goal is attached to this issue. A snippet
is shown here:
{code}
---
Battery: com.dolby.pics.core.ejb.bean.CountryBeanTestCase
---
Tests run: 11, Failures: 0, Errors: 11, Time elapsed: 7.234 sec
testGetAll(com.dolby.pics.core.ejb.bean.CountryBeanTestCase) Time elapsed:
2.255 sec ERROR!
[ stdout ] ---
[ stderr ] ---
[ stacktrace ] ---
java.lang.RuntimeException: org.jboss.xb.binding.JBossXBRuntimeException:
Failed to create a new SAX parser
at
org.jboss.ejb3.embedded.EJB3StandaloneBootstrap.boot(EJB3StandaloneBootstrap.java:391)
at
com.dolby.pics.test.AbstractEJBTestCase.startupEmbeddedJboss(AbstractEJBTestCase.java:63)
at
com.dolby.pics.test.AbstractEJBTestCase.setUp(AbstractEJBTestCase.java:145)
at
com.dolby.pics.core.ejb.bean.CountryBeanTestCase.setUp(CountryBeanTestCase.java:43)
at junit.framework.TestCase.runBare(TestCase.java:128)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:228)
at junit.framework.TestSuite.run(TestSuite.java:223)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:242)
at
org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:216)
at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215)
at org.apache.maven.surefire.Surefire.run(Surefire.java:163)
at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.SurefireBooter.runTestsInProcess(SurefireBooter.java:313)
at org.apache.maven.surefire.SurefireBooter.run(SurefireBooter.java:221)
at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:371)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
[jira] Closed: (MAVENUPLOAD-983) Upload struts-menu 2.4.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-983?page=all ] Carlos Sanchez closed MAVENUPLOAD-983: -- Assign To: Carlos Sanchez Resolution: Fixed Upload struts-menu 2.4.1 Key: MAVENUPLOAD-983 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-983 Project: maven-upload-requests Type: Bug Reporter: Tomislav Stojcevich Assignee: Carlos Sanchez Attachments: struts-menu-2.4.1-bundle.jar Upload with sources. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-966) Upload Retroweaver 1.2.3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-966?page=comments#action_69563 ] Carlos Sanchez commented on MAVENUPLOAD-966: groupId must be net.sourceforge.retroweaver there must be a bundle per artifact with jar and pom inside (http://maven.apache.org/guides/mini/guide-ibiblio-upload.html) Upload Retroweaver 1.2.3 Key: MAVENUPLOAD-966 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-966 Project: maven-upload-requests Type: Task Reporter: Jochen Wiedmann Attachments: retroweaver-1.2.3-upload.jar RetroWeaver transforms Java classes, which have been compiled by a Java 5 compiler, into class files, that are accepable by Java 1.4. Ibiblio already contains version 1.0 (under the group net.sourceforge.retroweaver). I am not the author, but would like to use this version in plugins. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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] Moved: (MEV-423) pom.xml for Spring 1.2.8 missing from Ibiblio
[ http://jira.codehaus.org/browse/MEV-423?page=all ] Carlos Sanchez moved MNG-2437 to MEV-423: - Priority: (was: Blocker) Environment: (was: Any) Complexity: (was: Intermediate) Workflow: jira (was: Maven New) Key: MEV-423 (was: MNG-2437) Project: Maven Evangelism (was: Maven 2) pom.xml for Spring 1.2.8 missing from Ibiblio - Key: MEV-423 URL: http://jira.codehaus.org/browse/MEV-423 Project: Maven Evangelism Type: Bug Reporter: Anthony Hilario As stated in the summary, the pom.xml and associated checksum files are missing from Ibiblio, preventing download of that dependency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MEV-423) pom.xml for Spring 1.2.8 missing from Ibiblio
[ http://jira.codehaus.org/browse/MEV-423?page=all ] Carlos Sanchez closed MEV-423: -- Assign To: Carlos Sanchez Resolution: Incomplete See http://opensource.atlassian.com/projects/spring/browse/SPR-1484 pom.xml for Spring 1.2.8 missing from Ibiblio - Key: MEV-423 URL: http://jira.codehaus.org/browse/MEV-423 Project: Maven Evangelism Type: Bug Reporter: Anthony Hilario Assignee: Carlos Sanchez As stated in the summary, the pom.xml and associated checksum files are missing from Ibiblio, preventing download of that dependency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MNGECLIPSE-159) using install goal creates invalid
[ http://jira.codehaus.org/browse/MNGECLIPSE-159?page=comments#action_69576 ] Ryan Sonnek commented on MNGECLIPSE-159: I've had this issue happen on more than one computer, and here's the invalid repository metadata file: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0.1; URL=/com/codecrate/shard/shard-core/0.5.0-SNAPSHOT/maven-metadata.xml META HTTP-EQUIV=Pragma CONTENT=no cache META HTTP-EQUIV=Expires CONTENT=-1 /HEAD/HTML I can't put my finger on this as either a core maven issue or an m2eclipse issue, but it *only* throws errors in the m2eclipse plugin. I've been forced to build from the command line to get around this problem. using install goal creates invalid --- Key: MNGECLIPSE-159 URL: http://jira.codehaus.org/browse/MNGECLIPSE-159 Project: Maven 2.x Extension for Eclipse Type: Bug Versions: 0.0.9 Environment: eclipse 3.2, m2eclipse 0.0.9 Reporter: Ryan Sonnek Assignee: Eugene Kuleshov When I install my project using the m2eclise plugin (external tools integration), i get the following error. Either maven or the m2eclipse plugin created an invalid repository xml file and installed it in my local repository. The only solution is to nuke the local repository files and install from the command line. Is this because my project has custom repositories defined in my POM? Project ID: com.codecrate.shard:shard-gui-core Reason: Error getting POM for 'com.codecrate.shard:shard-gui-core' from the repository: Unable to read local copy of metadata: Cannot read metadata from '/home/rsonnek/.m2/repository/com/codecrate/shard/shard-gui-core/0.5.0-SNAPSHOT/maven-metadata-codecrate-maven-repo.xml': end tag name /HEAD must be the same as start tag META from line 3 (position: TEXT seen ...META HTTP-EQUIV=Expires CONTENT=-1\r\n/HEAD... @4:8) com.codecrate.shard:shard-gui-core:pom:0.5.0-SNAPSHOT -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MNGECLIPSE-159) using install goal creates invalid
[ http://jira.codehaus.org/browse/MNGECLIPSE-159?page=comments#action_69577 ] Ryan Sonnek commented on MNGECLIPSE-159: I have verified that this repository metadata file is created on startup of the m2eclipse plugin, so this isn't an issue with the maven core. using install goal creates invalid --- Key: MNGECLIPSE-159 URL: http://jira.codehaus.org/browse/MNGECLIPSE-159 Project: Maven 2.x Extension for Eclipse Type: Bug Versions: 0.0.9 Environment: eclipse 3.2, m2eclipse 0.0.9 Reporter: Ryan Sonnek Assignee: Eugene Kuleshov When I install my project using the m2eclise plugin (external tools integration), i get the following error. Either maven or the m2eclipse plugin created an invalid repository xml file and installed it in my local repository. The only solution is to nuke the local repository files and install from the command line. Is this because my project has custom repositories defined in my POM? Project ID: com.codecrate.shard:shard-gui-core Reason: Error getting POM for 'com.codecrate.shard:shard-gui-core' from the repository: Unable to read local copy of metadata: Cannot read metadata from '/home/rsonnek/.m2/repository/com/codecrate/shard/shard-gui-core/0.5.0-SNAPSHOT/maven-metadata-codecrate-maven-repo.xml': end tag name /HEAD must be the same as start tag META from line 3 (position: TEXT seen ...META HTTP-EQUIV=Expires CONTENT=-1\r\n/HEAD... @4:8) com.codecrate.shard:shard-gui-core:pom:0.5.0-SNAPSHOT -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-660) One or more module in a project is added twice during adding maven2 projects
[ http://jira.codehaus.org/browse/CONTINUUM-660?page=comments#action_69588 ] Dan Allen commented on CONTINUUM-660: - Please see CONTINUUM-656 for details. It is possible to not reproduce this problem. It all depends on your actions while importing the project. If you try to kick off a build before the checkout of the source is finished, bad data is getting inserted into the database. At this point, continuum is corrupt and you are forced to delete and start over. 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 Type: Bug Versions: 1.0.3 Environment: Solaris10 on sparc Reporter: Kaare Nilsen Fix For: 1.1 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] Created: (CONTINUUM-772) delete project group optionally deletes all of its modules
delete project group optionally deletes all of its modules -- Key: CONTINUUM-772 URL: http://jira.codehaus.org/browse/CONTINUUM-772 Project: Continuum Type: Sub-task Components: Web interface Versions: 1.0.3 Environment: linux Reporter: Dan Allen It would be very convenience (aka a huge time-saver) if it were possible to delete all the modules related to a project group when deleting the project group itself. Perhaps this could be an option on the confirm screen. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-69) can plugin support equivalent of maven.eclipse.classpath.include feature found in 1.x version?
[ http://jira.codehaus.org/browse/MECLIPSE-69?page=comments#action_69592 ] Hiram Chirino commented on MECLIPSE-69: --- Please implement.. this is a great feature. can plugin support equivalent of maven.eclipse.classpath.include feature found in 1.x version? -- Key: MECLIPSE-69 URL: http://jira.codehaus.org/browse/MECLIPSE-69 Project: Maven 2.x Eclipse Plugin Type: New Feature Reporter: Evan Eustace In the Maven 1.x version of the plugin I used : maven.eclipse.classpath.include to specify extra folders that I wanted to add to the classpath. Is it possible to implement this as a feature in the 2.x version. is there a workaround? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MEV-424) missing plexus-tools-1.0.5
missing plexus-tools-1.0.5 -- Key: MEV-424 URL: http://jira.codehaus.org/browse/MEV-424 Project: Maven Evangelism Type: Bug Components: Missing POM Reporter: Dan Tran this is required to build maven-repository-manager -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MPANT-27) Generated Ant script does not work unless mvn has previously been run to create the repo directory structure
Generated Ant script does not work unless mvn has previously been run to create the repo directory structure Key: MPANT-27 URL: http://jira.codehaus.org/browse/MPANT-27 Project: maven-ant-plugin Type: Bug Environment: Windows XP Reporter: Jon Tayler This is for version 2.0-beta-1 The generated ant script creates a get-deps target that is a list of get tasks downloading dependencies from remote repos into the local repos. It attempts to create the maven 2 directory structure. Unfortunately if this structure does not exist, then the script will fail silently (due to the ignoreErrors flag) since the ant get task doesn't automatically create the missing folders. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSUREFIRE-122) Support tests written in Jython
[ http://jira.codehaus.org/browse/MSUREFIRE-122?page=comments#action_69602 ] Charlie Groves commented on MSUREFIRE-122: -- Have we hit enough votes to start integrating this? Support tests written in Jython --- Key: MSUREFIRE-122 URL: http://jira.codehaus.org/browse/MSUREFIRE-122 Project: Maven 2.x Surefire Plugin Type: New Feature Reporter: Charlie Groves Attachments: jythonProvider.tar.gz I've written a first pass at a surefire-provider for JUnit and Python unittest TestCases written in Jython. Before I continue any further I'd like to make sure that the provider is wanted and that I'm heading in the right direction. To do the minimum to get it up and running, I've hooked into the maven-surefire-plugin to hook my provider into the system somewhat like the TestNG provider did. maven-surefire-plugin passes a path(defaults to src/test/jython) to the provider. The provider searches the path for files matching include patterns and loads those as Python modules. For every class in the matching modules that extends junit or unittest TestCase, it makes a SurefireTestSuite and exposes them for running. Sound like a decent approach? To give it a spin, apply maven-surefire-plugin.patch, mvn install on the surefire-jython project and run mvn test in jythonProviderTest. It's just contains a single Junit testcase with a failing and passing test. I haven't even checked what happens when the jython tests throw exceptions, and I know there's alot to be done as far as making it a usable plugin, but I felt like getting some feedback before continuing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-159) Absolute URI rendered as relative URI if absolute URI related to domain of POM URI
Absolute URI rendered as relative URI if absolute URI related to domain of POM URI -- Key: MSITE-159 URL: http://jira.codehaus.org/browse/MSITE-159 Project: Maven 2.x Site Plugin Type: Bug Reporter: Ted Husted Under site-beta5 if the POM references a URI like urlhttp://struts.apache.org/url absolute URLs used in the site.xml file are converted to relative references. For example a reference to to http://struts.apache.org/1.x; becomes 1.x, and a reference to just http://struts.apache.org; becomes an empty string. If the documentation is being used offline, there are many cases when we want to refer people back to the website, to be sure the current information is used. The best use case is a download page that determines the mirror via CGI. Another use case is referring to a sister site in the domain, that might refer to another version. If used locally, the other site might not be in the relative location. Switching back to beta4 cures the behavior, and absolute URIs remain absolute, 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] Commented: (CONTINUUM-733) can Mail notifier be configurable as to whether it sends a msg even when the state is not changed from previous build?
[ http://jira.codehaus.org/browse/CONTINUUM-733?page=comments#action_69606 ] Xiheng commented on CONTINUUM-733: -- I failed to notice that there is a alwaysSend element in the applications.xml to specify whether I want to get a notification no matter what. I apologize. can Mail notifier be configurable as to whether it sends a msg even when the state is not changed from previous build? -- Key: CONTINUUM-733 URL: http://jira.codehaus.org/browse/CONTINUUM-733 Project: Continuum Type: Improvement Components: Mail Notifier Versions: 1.0.3 Environment: Windows XP (doesn't really matter) Reporter: Xiheng Priority: Minor Fix For: 1.1 It's desirable that the mail notifier be made configurable so that the user can choose to have continuum deliver a notification even when the build state is not changed from the previous one (both success, or both failure, etc.). Also, if continuum determines that The project was not built because all changes are unknown, it is desirable for the user to have an option of receiving a message indicate as such. Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MPANT-27) Generated Ant script does not work unless mvn has previously been run to create the repo directory structure
[ http://jira.codehaus.org/browse/MPANT-27?page=comments#action_69611 ]
Jon Tayler commented on MPANT-27:
-
Looks like the plugin will have to generate something like:
dirname property=groupId.artifactId
file=${maven.repo.local}/org/votech/ds6/plastic/plastic-window-frame/0.5.2-SNAPSHOT/plastic-window-frame-0.5.2-SNAPSHOT.jar/
!--property name will have to be some mangled version of the artifact and
group id--
mkdir dir=${groupId.artifactId}/
get verbose=on
src=http://www.astrogrid.org/maven/org/votech/ds6/plastic/plastic-window-frame/0.5.2-SNAPSHOT/plastic-window-frame-0.5.2-SNAPSHOT.jar;
dest=${maven.repo.local}/org/votech/ds6/plastic/plastic-window-frame/0.5.2-SNAPSHOT/plastic-window-frame-0.5.2-SNAPSHOT.jar
usetimestamp=true ignoreerrors=true/
for each depdency.
Generated Ant script does not work unless mvn has previously been run to
create the repo directory structure
Key: MPANT-27
URL: http://jira.codehaus.org/browse/MPANT-27
Project: maven-ant-plugin
Type: Bug
Environment: Windows XP
Reporter: Jon Tayler
This is for version 2.0-beta-1
The generated ant script creates a get-deps target that is a list of get
tasks downloading dependencies from remote repos into the local repos. It
attempts to create the maven 2 directory structure. Unfortunately if this
structure does not exist, then the script will fail silently (due to the
ignoreErrors flag) since the ant get task doesn't automatically create the
missing folders.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MPLUGIN-1) Maven fails while developing plugin with 1.5 compliant sources
[ http://jira.codehaus.org/browse/MPLUGIN-1?page=comments#action_69613 ] Jimisola Laursen commented on MPLUGIN-1: There doesn't seem to be any activity around this issue. The use of Java 1.5 functionality is being more and more common nowadays. This improvement/bug fix is therefore becoming more and more important. Because of this issue I can't reuse code since most other source I write is in Java 1.5. Found mvn-anno-mojo (http://sourceforge.net/projects/mvn-anno-mojo) btw: Maven 2 build system extention that allows writing annotatd Mojos using JDK 1.5 annotations instead of doclet comments.: It uses APT and QDox-1.6-SNAPSHOT Maven fails while developing plugin with 1.5 compliant sources -- Key: MPLUGIN-1 URL: http://jira.codehaus.org/browse/MPLUGIN-1 Project: Maven 2.x Plugin Plugin Type: Bug Reporter: Jose Gonzalez Gomez I'm developing a plugin for Maven, and my sources contains 1.5 features, such as use of generics. When I try to install the plugin in my local repository I get the following: [INFO] Scanning for projects... [INFO] [INFO] Building Maven Docbook plugin [INFO]task-segment: [install] [INFO] [INFO] [plugin:descriptor] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] syntax error @[129,64] in file:/C:/Documents and Settings/jgonzalez/Mis documentos/proyectos/otros/maven-opendocbook-plugin/src/ main/java/com/openinput/tools/maven/opendocbook/TransformMojo.java [INFO] [INFO] Trace com.thoughtworks.qdox.parser.ParseException: syntax error @[129,64] in file:/C:/Documents and Settings/jgonzalez/Mis documentos/proyectos/otros/maven-opendocbook-plugin/src/main/java/com/openinput/tools/maven/opendocbook/TransformMojo.java at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:504) at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:610) at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:488) at com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:296) at com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:312) at com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:308) at com.thoughtworks.qdox.JavaDocBuilder$1.visitFile(JavaDocBuilder.java:365) at com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:43) at com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34) at com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34) at com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34) at com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34) at com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34) at com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34) at com.thoughtworks.qdox.directorywalker.DirectoryScanner.scan(DirectoryScanner.java:52) at com.thoughtworks.qdox.JavaDocBuilder.addSourceTree(JavaDocBuilder.java:362) at org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.execute(JavaMojoDescriptorExtractor.java:477) at org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:69) at org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:99) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) at
[jira] Closed: (MNG-2221) Multiple Executions of Plugin at Difference Inhertiance levels causes plugin executions to run multiple times
[ http://jira.codehaus.org/browse/MNG-2221?page=all ] John Casey closed MNG-2221: --- Resolution: Fixed Added two new unit tests to maven-project:org.apache.maven.project.ModelUtilsTest to verify that merged plugins are no longer added to the child POM twice. Merged plugin definitions were not being cached, and could not be checked before being added a second time to the resulting plugins list (along with plugins that didn't undergo a merge). Multiple Executions of Plugin at Difference Inhertiance levels causes plugin executions to run multiple times - Key: MNG-2221 URL: http://jira.codehaus.org/browse/MNG-2221 Project: Maven 2 Type: Bug Components: Inheritence and Interpolation Versions: 2.0.4 Reporter: Stephen Duncan Jr Assignee: John Casey Priority: Critical Fix For: 2.0.5 Attachments: repeat-test.zip Can occur in a variety of ways, but the attached test case shows a parent pom defining an antrun-execution, and then a child specifying another execution with a different id. Both executions run twice when running from the child. I believe this is the same as Kenney Westerhof's comment: http://jira.codehaus.org/browse/MNG-2054#action_62477 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-160) Generate a web site for multiple projects
Generate a web site for multiple projects - Key: MSITE-160 URL: http://jira.codehaus.org/browse/MSITE-160 Project: Maven 2.x Site Plugin Type: Improvement Versions: 2.0 Environment: Debian + Tomcat Reporter: Franck HUGOT Priority: Minor Hello, Is there a way to generate only one web site for multiple projects? I can't find a way to do this, except generate a web site for each project and develop a specific home page that refer to each project home page. Thanks in advance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-126) DependencySet: Jars with scope runtime not assembled anymore in 2.1
DependencySet: Jars with scope runtime not assembled anymore in 2.1 --- Key: MASSEMBLY-126 URL: http://jira.codehaus.org/browse/MASSEMBLY-126 Project: Maven 2.x Assembly Plugin Type: Bug Versions: 2.1 Reporter: Michael Schneider Attachments: descriptor-bin.xml, pom.xml Hi! After upgrading from 2.0.1 to 2.1 suddenly only my scope=compile dependencies are assembled, no runtime anymore. I therefore had to downgrade again to 2.0.1 in my POM to have the correct behaviour again. I attach my POM and my assembly-descriptor. Maybe this is a hint: All runtime deps in the POM are originally compile deps within the indirect POMs (POMs of other projects which have compile scope in my POM), in most cases with different versions. This means I overwrite the original references, replace them with other versions and move scope to runtime (because I do not need them for compilation). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (WAGON-56) WebDAV Wagon putDirectory fails when multiple directories in path don't exist
[ http://jira.codehaus.org/browse/WAGON-56?page=all ] Nathan Beyer (Cerner) updated WAGON-56: --- Attachment: wagontestcase_deepdest.diff WebDAV Wagon putDirectory fails when multiple directories in path don't exist - Key: WAGON-56 URL: http://jira.codehaus.org/browse/WAGON-56 Project: wagon Type: Bug Components: wagon-webdav Versions: 1.0-beta-2, 1.0-beta-1 Reporter: Nathan Beyer (Cerner) Priority: Blocker Attachments: wagontestcase_deepdest.diff, webdavwagon_putdirectory.diff The implementation of the 'putDirectory' method isn't properly checking that all directories (WebDAV collections) have been created. I've attached a patch that reworks the 'putDirectory' such that it relies on the 'put' method for each upload. This will guarantee that all file uploads are treated the same way and resolves this issue, as the 'put' method implements the appropriate directory checks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2261) Profiles ignored when working with non-projects (such as archetype:create)
[ http://jira.codehaus.org/browse/MNG-2261?page=comments#action_69626 ] John Casey commented on MNG-2261: - I found that a similar piece of code already exists in the trunk, written by mkleint in revId 415000. I'm trying to lift that piece instead, for consistency's sake. If that works, I'll add some unit tests and call it good. At a basic level, all we need to do is verify that the superPOM, when loaded standalone, is injected with existing properties from active profiles. We should be able to work up a much more elemental unit test to give this a try, and then come back around to the type of test explained above for one more level of verification. Profiles ignored when working with non-projects (such as archetype:create) -- Key: MNG-2261 URL: http://jira.codehaus.org/browse/MNG-2261 Project: Maven 2 Type: Bug Components: General Versions: 2.0.4 Reporter: Joakim Erdfelt Assignee: John Casey Priority: Blocker Fix For: 2.0.5 Attachments: MNG-2261-2.patch, MNG-2261.patch Several conditions have to be met to show this bug. 1) Be in an environment that does not have access to repo1.maven.org, (such as a corporate environment) 2) Have no content in your local repository (a fresh install of maven 2.0.4) 3) Attempt to use a plugin that has no project requirement (such as archetype:create) The plugin fails because access to repo1.maven.org cannot be accessed. Recommended solution: Create a settings.xml profile that changes the location of the 'central' repository to point to an internal resource (such as a maven-proxy installation). settings profiles profile iduse_internal/id repositories repository idcentral/id nameInternal Central Repository/name urlhttp://repo.internal.com/maven2/url releases enabledtrue/enabled /releases snapshots enabledtrue/enabled /snapshots /repository /repositories pluginRepositories pluginRepository idcentral/id nameInternal Central Repository/name urlhttp://repo.internal.com/maven2/url releases enabledtrue/enabled /releases snapshots enabledtrue/enabled /snapshots /pluginRepository /pluginRepositories /profile /profiles activeProfiles activeProfileuse_internal/activeProfile /activeProfiles /settings Try again. Still fails. The reason is that the default behaviour for non-project execution is to use the maven super pom, however there is a bug with that flow that does not allow for the merging of the settings.xml profiles. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2236) DefaultMavenProjectBuilder.buildStandaloneSuperProject() should include a ProfileManager that includes active profiles from settings.xml
[ http://jira.codehaus.org/browse/MNG-2236?page=all ] John Casey closed MNG-2236: --- Assign To: John Casey Resolution: Duplicate More description in MNG-2261, and that's the issue I'm working against as I resolve this. DefaultMavenProjectBuilder.buildStandaloneSuperProject() should include a ProfileManager that includes active profiles from settings.xml Key: MNG-2236 URL: http://jira.codehaus.org/browse/MNG-2236 Project: Maven 2 Type: Bug Components: Inheritence and Interpolation Versions: 2.0.4 Reporter: Aaron Anderson Assignee: John Casey Fix For: 2.0.5 Attachments: patch.txt I have a custom plugin that performs JMX operations using properties defined in a profile. I have defined an active profile in the settings.xml that specifies properties that the plugin uses and everything works fine when a POM is present. Now I would like the plugin to work from any directory and have added the plugin annotation requiresProject=false to it. If I run the plugin in a directory without a POM the profile properties from settings.xml are never loaded. After performing some debugging I have determined that the default super-pom's model that is used when no POM xml file is available does not contain the profile properties defined in settings.xml while if a POM.xml is available the settings.xml profiles are loaded into the POM. This all appears to boil down to the lack of a ProfileManager parameter to thebuildStandaloneSuperProject method defined in the MavenProjectBuilder interface. While DefaultMaven's invocation of the component has a globalProfileManager available (with the active settings profiles set) it cannot be passed into the MavenProjectBuilder component. Alternatively, If the DefaultMavenProjectBuilder had the Settings component injected into it could pass it into the constructor of the DefaultProfileManager instance it creates and then the DefaultProfileManager would load the active profiles into the POM. By enabling this fix it would make plugins useful for management tasks, for example starting or stoping an application server. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-104) fileMode doesn't work with Cygwin
[ http://jira.codehaus.org/browse/MASSEMBLY-104?page=comments#action_69628 ] toli kuznets commented on MASSEMBLY-104: I have a similar problem on both OSX 10.4.7 and on Ubuntu Linux. for me, permissions are completely ignored, regardless of whether i specify them or not In fact, they come up as this: [EMAIL PROTECTED]:~/dev/ossProjects/assembly-bug$ l target/assembly-bug-1.0-bin/ total 16 --wr-T 1 toli toli 12 Jul 12 15:08 fileA --wr-T 1 toli toli 12 Jul 12 15:08 fileB i'm attaching the tarball with the sample POM that produces this. it doesn't matter whether i run assembly:directory or assembly:assembly Seems like this was fixed in bug #70 but maybe it came back? fileMode doesn't work with Cygwin - Key: MASSEMBLY-104 URL: http://jira.codehaus.org/browse/MASSEMBLY-104 Project: Maven 2.x Assembly Plugin Type: Bug Versions: 2.1 Environment: Windows 2002 XP Pro running Cygwin Reporter: Mark Heinze The fileMode does not correctly set the permissions on the file. This happens in the filesfile/file/files tag in the asssembly XML file. Any files copied with this tag ends up with strange permissions (including those with the default fileMode). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MASSEMBLY-104) fileMode doesn't work with Cygwin
[ http://jira.codehaus.org/browse/MASSEMBLY-104?page=all ] toli kuznets updated MASSEMBLY-104: --- Attachment: assembly-bug.tar fileMode doesn't work with Cygwin - Key: MASSEMBLY-104 URL: http://jira.codehaus.org/browse/MASSEMBLY-104 Project: Maven 2.x Assembly Plugin Type: Bug Versions: 2.1 Environment: Windows 2002 XP Pro running Cygwin Reporter: Mark Heinze Attachments: assembly-bug.tar The fileMode does not correctly set the permissions on the file. This happens in the filesfile/file/files tag in the asssembly XML file. Any files copied with this tag ends up with strange permissions (including those with the default fileMode). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MPSITE-53) maven -N site does not generate index.html
maven -N site does not generate index.html -- Key: MPSITE-53 URL: http://jira.codehaus.org/browse/MPSITE-53 Project: maven-site-plugin Type: Bug Components: plugin Environment: solaris 8 Reporter: Andrew Williams when using maven -N (through continuum) I run the site goal (and site:deploy) but it fails to generate index.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] Moved: (MANT-12) Generated Ant script does not work unless mvn has previously been run to create the repo directory structure
[ http://jira.codehaus.org/browse/MANT-12?page=all ] Dennis Lundberg moved MPANT-27 to MANT-12: -- Workflow: Maven New (was: jira) Key: MANT-12 (was: MPANT-27) Project: Maven 2.x Ant Plugin (was: maven-ant-plugin) Generated Ant script does not work unless mvn has previously been run to create the repo directory structure Key: MANT-12 URL: http://jira.codehaus.org/browse/MANT-12 Project: Maven 2.x Ant Plugin Type: Bug Environment: Windows XP Reporter: Jon Tayler This is for version 2.0-beta-1 The generated ant script creates a get-deps target that is a list of get tasks downloading dependencies from remote repos into the local repos. It attempts to create the maven 2 directory structure. Unfortunately if this structure does not exist, then the script will fail silently (due to the ignoreErrors flag) since the ant get task doesn't automatically create the missing folders. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MASSEMBLY-45) Support for mappers in assembly desriptors
[ http://jira.codehaus.org/browse/MASSEMBLY-45?page=all ] Prasad Kashyap updated MASSEMBLY-45: Attachment: maven-assembly-plugin.patch Support for mappers in assembly desriptors -- Key: MASSEMBLY-45 URL: http://jira.codehaus.org/browse/MASSEMBLY-45 Project: Maven 2.x Assembly Plugin Type: Bug Reporter: Anuerin Diaz Attachments: maven-assembly-plugin.patch I would like to forward a wish to have the assembly plugin support the notion of file mappers similar to the ones in Ant[1]. To illustrate, assuming a multi-module project with the following layout: Root |-Module1 |-Module2 |-Container | |-Module3 | |-Module4 |-Module5 |- pom.xml and an assembly desriptor entry for the contained modules like this fileSets fileSets directoryContainer/directory outputDirectory/outputDirectory includes include**/target/*.jar/include /includes /fileSets /fileSets The assembly plugin will be able to get all jar files produced by Module3 and Module4 but the Container/ModuleName/target structure will still be included. One workaround is to enumerate each ModuleName artifact but problematic if the number of contained sub-modules is numerous. Support for filemappers which look like this: fileSets fileSets directoryContainer/directory outputDirectory/outputDirectory includes include**/target/*.jar/include /includes mapper type=flatten /fileSets /fileSets will cause all contained jar files to be copied without their original structure. This feature would be useful for globbing artifact names as well as for physically organizing project structures according to type. [1] http://ant.apache.org/manual/CoreTypes/mapper.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-219) broken link online documentation
broken link online documentation Key: SCM-219 URL: http://jira.codehaus.org/browse/SCM-219 Project: Maven SCM Type: Bug Components: documentation Reporter: Valerio Schiavoni There's a broken link to the scm plugin documentation, reachable from: http://maven.apache.org/plugins/index.html scm Subversion (from left menu the broken link is: http://maven.apache.org/scm/plugins/subversion.html it should be: http://maven.apache.org/scm/subversion.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-984) Please upload Connector/J 5.0.2
Please upload Connector/J 5.0.2 --- Key: MAVENUPLOAD-984 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-984 Project: maven-upload-requests Type: Task Reporter: Mark Matthews The 5.0 version of the JDBC driver for MySQL (we'll start publishing these for Maven 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: (MASSEMBLY-116) Provide ability to use a temp dir which doesn't get included in the assembly archive
[ http://jira.codehaus.org/browse/MASSEMBLY-116?page=comments#action_69637 ] Prasad Kashyap commented on MASSEMBLY-116: -- Please close this. It will be fixed (partly) in the patch submitted to http://jira.codehaus.org/browse/MASSEMBLY-45 Provide ability to use a temp dir which doesn't get included in the assembly archive Key: MASSEMBLY-116 URL: http://jira.codehaus.org/browse/MASSEMBLY-116 Project: Maven 2.x Assembly Plugin Type: Improvement Versions: 2.0.1 Reporter: Prasad Kashyap http://www.mail-archive.com/dev@maven.apache.org/msg56911.html The following would be nice improvements to the plugin 1) Ability to extract certain files (like the patternset in ant) when unpacking jars using dependencySet. 2) The current workaround to #1 above is to unpack them in a temp junk directory and then use fileset to selectively include/exclude files to the correct dir. This kinda works but it also zips up the temp junk dir too. It would be nice if the dependencySet had a temp flag. Setting this boolean would copy/unpack the jars to some temp dir of the plugin's choosing. The plugin would never include this temp dir into the final zip. 3) fileset should also support the unpack feature. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2261) Profiles ignored when working with non-projects (such as archetype:create)
[ http://jira.codehaus.org/browse/MNG-2261?page=all ] John Casey closed MNG-2261: --- Resolution: Fixed Unit test applied to trunk that will verify that repositories and properties injected into the standalone superPOM via profile are available in the project instance. Also, merged the changes to implementation and unit test into the 2.0.x branch, and verified that all ITs which are active still run. Profiles ignored when working with non-projects (such as archetype:create) -- Key: MNG-2261 URL: http://jira.codehaus.org/browse/MNG-2261 Project: Maven 2 Type: Bug Components: General Versions: 2.0.4 Reporter: Joakim Erdfelt Assignee: John Casey Priority: Blocker Fix For: 2.0.5 Attachments: MNG-2261-2.patch, MNG-2261.patch Several conditions have to be met to show this bug. 1) Be in an environment that does not have access to repo1.maven.org, (such as a corporate environment) 2) Have no content in your local repository (a fresh install of maven 2.0.4) 3) Attempt to use a plugin that has no project requirement (such as archetype:create) The plugin fails because access to repo1.maven.org cannot be accessed. Recommended solution: Create a settings.xml profile that changes the location of the 'central' repository to point to an internal resource (such as a maven-proxy installation). settings profiles profile iduse_internal/id repositories repository idcentral/id nameInternal Central Repository/name urlhttp://repo.internal.com/maven2/url releases enabledtrue/enabled /releases snapshots enabledtrue/enabled /snapshots /repository /repositories pluginRepositories pluginRepository idcentral/id nameInternal Central Repository/name urlhttp://repo.internal.com/maven2/url releases enabledtrue/enabled /releases snapshots enabledtrue/enabled /snapshots /pluginRepository /pluginRepositories /profile /profiles activeProfiles activeProfileuse_internal/activeProfile /activeProfiles /settings Try again. Still fails. The reason is that the default behaviour for non-project execution is to use the maven super pom, however there is a bug with that flow that does not allow for the merging of the settings.xml profiles. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-182) git provider
[ http://jira.codehaus.org/browse/SCM-182?page=all ]
Dominik Winter updated SCM-182:
---
Attachment: SCM-182.patch
git provider
Key: SCM-182
URL: http://jira.codehaus.org/browse/SCM-182
Project: Maven SCM
Type: New Feature
Components: maven-scm-site
Environment: Developed on Mac OS X 10.3.9 with git 1.2.4
Reporter: Dominik Winter
Attachments: SCM-182.patch, git.patch
Please find the git provider as attachment.
Usefulness:
I used the git provider together with
[http://maven.apache.org/plugins/maven-release-plugin|maven-release-plugin],
it works fine for that use case.
Open issues:
- the JUnit tests are proprietary, not yet TCK. I'll fix that.
If you want to run the tests, you must have git installed and it must be in
your {{PATH}}.
To run git:
- on *Windows*: use [Cygwin|http://www.cygwin.com] and install the binutils,
openssh, openssl, rsync, curl
than you are able to compile and install git
- on Linux: there are packages somewhere
- on Mac OS X: use the [DarwinPorts|http://www.darwinports.org/]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (SCM-182) git provider
[ http://jira.codehaus.org/browse/SCM-182?page=all ]
Dominik Winter updated SCM-182:
---
Attachment: git.tar.bz2
git provider
Key: SCM-182
URL: http://jira.codehaus.org/browse/SCM-182
Project: Maven SCM
Type: New Feature
Components: maven-scm-site
Environment: Developed on Mac OS X 10.3.9 with git 1.2.4
Reporter: Dominik Winter
Attachments: SCM-182.patch, git.patch, git.tar.bz2
Please find the git provider as attachment.
Usefulness:
I used the git provider together with
[http://maven.apache.org/plugins/maven-release-plugin|maven-release-plugin],
it works fine for that use case.
Open issues:
- the JUnit tests are proprietary, not yet TCK. I'll fix that.
If you want to run the tests, you must have git installed and it must be in
your {{PATH}}.
To run git:
- on *Windows*: use [Cygwin|http://www.cygwin.com] and install the binutils,
openssh, openssl, rsync, curl
than you are able to compile and install git
- on Linux: there are packages somewhere
- on Mac OS X: use the [DarwinPorts|http://www.darwinports.org/]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2103) Inheritance of plugin overrides that of execution
[ http://jira.codehaus.org/browse/MNG-2103?page=all ] John Casey updated MNG-2103: Fix Version: (was: 2.0.5) 2.1 Sorry, just reading over this one more closely, and if we're going to pursue adding a new element to the POM, it should wait for 2.1. In the meantime, you can override a single execution within a plugin config by making sure it has a matching id/. Inheritance of plugin overrides that of execution - Key: MNG-2103 URL: http://jira.codehaus.org/browse/MNG-2103 Project: Maven 2 Type: Bug Reporter: Prasad Kashyap Fix For: 2.1 Attachments: test-inheritance-true.zip, test-inheritance.zip The inherited settings of plugin overrides that of it's execution By convention, all top level configuration settings are usually overridden by the settings in the lower levels. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-127) filesfile... fileMode processing is busted
filesfile... fileMode processing is busted
Key: MASSEMBLY-127
URL: http://jira.codehaus.org/browse/MASSEMBLY-127
Project: Maven 2.x Assembly Plugin
Type: Bug
Versions: 2.2
Reporter: Jason Dillon
Attachments: MASSEMBLY-127.diff
The processing of fileMode for filesfile is busted.
For example, this will not set the right perms:
{code:xml}
files
file
source${basedir}/src/var/config/config.xml/source
outputDirectoryvar/config/outputDirectory
filteredtrue/filtered
fileMode0644/fileMode
/file
/files
{code}
The problem is a missing {{, 8}} in the Integer.parseInt() code when calling
archiver.addFile().
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MASSEMBLY-127) filesfile... fileMode processing is busted
[ http://jira.codehaus.org/browse/MASSEMBLY-127?page=all ]
Jason Dillon updated MASSEMBLY-127:
---
Attachment: MASSEMBLY-127.diff
filesfile... fileMode processing is busted
Key: MASSEMBLY-127
URL: http://jira.codehaus.org/browse/MASSEMBLY-127
Project: Maven 2.x Assembly Plugin
Type: Bug
Versions: 2.2
Reporter: Jason Dillon
Attachments: MASSEMBLY-127.diff
The processing of fileMode for filesfile is busted.
For example, this will not set the right perms:
{code:xml}
files
file
source${basedir}/src/var/config/config.xml/source
outputDirectoryvar/config/outputDirectory
filteredtrue/filtered
fileMode0644/fileMode
/file
/files
{code}
The problem is a missing {{, 8}} in the Integer.parseInt() code when calling
archiver.addFile().
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-985) jsontools-core-1.2
jsontools-core-1.2 -- Key: MAVENUPLOAD-985 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-985 Project: maven-upload-requests Type: Task Reporter: Bruno Ranschaert JSON Tools is a collection of java tools to manipulate JSON formatted text streams. The package structure com.sdicons is also a domain name registered by me. This is a new release of the jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-986) jsontools-log4j-1.2
jsontools-log4j-1.2 --- Key: MAVENUPLOAD-986 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-986 Project: maven-upload-requests Type: Task Reporter: Bruno Ranschaert JSON Tools is a collection of java tools to manipulate JSON formatted text streams. This library contains the log4j dependent part of the tools. The package structure com.sdicons is also a domain name registered by me. This is the first release of the log4j library. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-67) assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}
[ http://jira.codehaus.org/browse/MASSEMBLY-67?page=comments#action_69650 ]
Baerrach bonDierne commented on MASSEMBLY-67:
-
I've reposted my request for help as it has been a week and no response from
the dev list.
assembling dependent jars or snapshots uses timestamp formatted version
instead of ${version}
-
Key: MASSEMBLY-67
URL: http://jira.codehaus.org/browse/MASSEMBLY-67
Project: Maven 2.x Assembly Plugin
Type: Bug
Reporter: Mark J. Titorenko
Attachments: MJAR-28-Notes.txt, MJAR-28-TestCases-Patch.txt
I'm using the jar plugin to add my dependencies to the manifest. I'm also
using the assembly plugin to package all dependencies into one archive. The
problem is that the jar manifest adds my dependencies as foo-SNAPHOT and
the archiver adds them as foo-20041113.jar.
This causes my snapshot classes to not be found at runtime.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MVERIFIER-2) review plugin documentation
[ http://jira.codehaus.org/browse/MVERIFIER-2?page=all ] Marvin King updated MVERIFIER-2: Priority: Minor (was: Major) review plugin documentation --- Key: MVERIFIER-2 URL: http://jira.codehaus.org/browse/MVERIFIER-2 Project: Maven 2.x Verifier Plugin Type: Task Reporter: Marvin King Assignee: Marvin King Priority: Minor Original Estimate: 17 hours Remaining: 17 hours -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-67) assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}
[ http://jira.codehaus.org/browse/MASSEMBLY-67?page=comments#action_69654 ]
Baerrach bonDierne commented on MASSEMBLY-67:
-
(Well it's not quite a week... but) Anyway I've found a web enabled IRC client
and asked on the maven irc channel.
#maven channel on the codehaus IRC server: irc.codehaus.org:6667
The latest code base (I was struggling to find) is at
http://svn.apache.org/repos/asf/maven/shared/trunk/maven-archiver
Also the correct place for archiver defects is in
http://jira.codehaus.org/browse/MNG using the maven-archiver component.
assembling dependent jars or snapshots uses timestamp formatted version
instead of ${version}
-
Key: MASSEMBLY-67
URL: http://jira.codehaus.org/browse/MASSEMBLY-67
Project: Maven 2.x Assembly Plugin
Type: Bug
Reporter: Mark J. Titorenko
Attachments: MJAR-28-Notes.txt, MJAR-28-TestCases-Patch.txt
I'm using the jar plugin to add my dependencies to the manifest. I'm also
using the assembly plugin to package all dependencies into one archive. The
problem is that the jar manifest adds my dependencies as foo-SNAPHOT and
the archiver adds them as foo-20041113.jar.
This causes my snapshot classes to not be found at runtime.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-2438) search for metadata in legacy repositories causes wrong repository source to be used for artifact resolution
search for metadata in legacy repositories causes wrong repository source to be used for artifact resolution Key: MNG-2438 URL: http://jira.codehaus.org/browse/MNG-2438 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0.4 Reporter: John Casey legacy repositories store all version metadata in a single file under the /poms/ subdirectory of the artifactId dir. This means that snapshot resolution will result in the legacy repository being marked as the source for the artifact, regardless of whether that metadata file contains the snapshot is actually in that repository's metadata file or not. This is because the metadata manager (and metadata class itself, possibly) assumes that all metadata files resolved for a particular artifact/snapshot are relevant to that snapshot...when the legacy repo's metadata is merged into the rest of the in-progress metadata, changes are detected, and the legacy repo is adopted as the source for the latest artifact information, regardless of whether it actually contains information about that snapshot or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2438) search for metadata in legacy repositories causes wrong repository source to be used for artifact resolution
[ http://jira.codehaus.org/browse/MNG-2438?page=all ] John Casey updated MNG-2438: Fix Version: 2.0.5 we should probably get some resolution for this for 2.0.5, since it's a real mess to debug. My order of preference for the solution is: 1. figure out how to be smarter about determining whether a metadata file contains relevant info before merging it. 2. suppress metadata resolution from legacy repositories search for metadata in legacy repositories causes wrong repository source to be used for artifact resolution Key: MNG-2438 URL: http://jira.codehaus.org/browse/MNG-2438 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0.4 Reporter: John Casey Fix For: 2.0.5 legacy repositories store all version metadata in a single file under the /poms/ subdirectory of the artifactId dir. This means that snapshot resolution will result in the legacy repository being marked as the source for the artifact, regardless of whether that metadata file contains the snapshot is actually in that repository's metadata file or not. This is because the metadata manager (and metadata class itself, possibly) assumes that all metadata files resolved for a particular artifact/snapshot are relevant to that snapshot...when the legacy repo's metadata is merged into the rest of the in-progress metadata, changes are detected, and the legacy repo is adopted as the source for the latest artifact information, regardless of whether it actually contains information about that snapshot or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-45) Support for mappers in assembly desriptors
[ http://jira.codehaus.org/browse/MASSEMBLY-45?page=comments#action_69656 ] John Casey commented on MASSEMBLY-45: - I've got the patch applied, and some of the tests fixed...but I'm stuck in unit test hell right now. I can't seem to figure out what these tests are intended to do...so it's going to take awhile longer to get this sorted out. Support for mappers in assembly desriptors -- Key: MASSEMBLY-45 URL: http://jira.codehaus.org/browse/MASSEMBLY-45 Project: Maven 2.x Assembly Plugin Type: Bug Reporter: Anuerin Diaz Assignee: John Casey Attachments: maven-assembly-plugin.patch I would like to forward a wish to have the assembly plugin support the notion of file mappers similar to the ones in Ant[1]. To illustrate, assuming a multi-module project with the following layout: Root |-Module1 |-Module2 |-Container | |-Module3 | |-Module4 |-Module5 |- pom.xml and an assembly desriptor entry for the contained modules like this fileSets fileSets directoryContainer/directory outputDirectory/outputDirectory includes include**/target/*.jar/include /includes /fileSets /fileSets The assembly plugin will be able to get all jar files produced by Module3 and Module4 but the Container/ModuleName/target structure will still be included. One workaround is to enumerate each ModuleName artifact but problematic if the number of contained sub-modules is numerous. Support for filemappers which look like this: fileSets fileSets directoryContainer/directory outputDirectory/outputDirectory includes include**/target/*.jar/include /includes mapper type=flatten /fileSets /fileSets will cause all contained jar files to be copied without their original structure. This feature would be useful for globbing artifact names as well as for physically organizing project structures according to type. [1] http://ant.apache.org/manual/CoreTypes/mapper.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] Closed: (MNG-2424) Classpath in reactor builds differ from dependency resolution
[ http://jira.codehaus.org/browse/MNG-2424?page=all ] Joerg Schaible closed MNG-2424: --- Resolution: Duplicate Fix Version: 2.0.5 Classpath in reactor builds differ from dependency resolution - Key: MNG-2424 URL: http://jira.codehaus.org/browse/MNG-2424 Project: Maven 2 Type: Bug Components: Reactor and workspace Versions: 2.0.4 Reporter: Joerg Schaible Priority: Blocker Fix For: 2.0.5 Attachments: MNG-2424.zip The classpath used to compile and test a module is wrong, if the module uses a released version of another module in the reactor build. If the module is build locally, the correct depednencies are on the classpath. This currently breaks our complete development and results makes e.g. EJBs useless (MEJB-18). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MEJB-18) Manifest classpath contains wrong entries in multi-module build
[ http://jira.codehaus.org/browse/MEJB-18?page=all ] Joerg Schaible closed MEJB-18: -- Resolution: Duplicate Fix Version: 2.0 Manifest classpath contains wrong entries in multi-module build --- Key: MEJB-18 URL: http://jira.codehaus.org/browse/MEJB-18 Project: Maven 2.x Ejb Plugin Type: Bug Versions: 2.0 Reporter: Joerg Schaible Priority: Blocker Fix For: 2.0 Attachments: MEJB-18.zip We had to detect, that in multi-module builds the entries in the Manifest for the classpath for those artifacts can be wrong that are also part of the build. The incident occurs, if an artifact is build in a SNAPSHOT version, but the EJB refers this artifact in a released version. The manifest contains nevertheless an entry for the SNAPSHOT. Additional observations: * the target/effective-pom.xml contains the dependency with the right version * the manifest contains the correct entry classpath when the artifact is build locally This is a real blocker, since building the EAR. Maven will copy the *correct* released version of the artifact, but the EJB is broken, because of the wrong (and missing) dependency. It seems the component creating the manifest uses a wrong dependency resolution for multi module builds ... might be the maven-archiver ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
