[jira] Updated: (MRELEASE-388) @requiresDependencyResolution on prepare mojo causes build to look for its own dependencies
[ http://jira.codehaus.org/browse/MRELEASE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MRELEASE-388: -- Fix Version/s: 2.0-beta-9 @requiresDependencyResolution on prepare mojo causes build to look for its own dependencies --- Key: MRELEASE-388 URL: http://jira.codehaus.org/browse/MRELEASE-388 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-8 Reporter: James William Dumay Priority: Critical Fix For: 2.0-beta-9 Attachments: release-fail.txt, release-fail.txt, removed-doclet.patch @requiresDependencyResolution on prepare mojo causes build to look for its own dependencies. Depending on the amount of modules you have this can take a very long time. I recommend the removal of this doclet as I don't think it really adds any value to resolve all dependencies before a release prepare can go ahead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-388) @requiresDependencyResolution on prepare mojo causes build to look for its own dependencies
[ http://jira.codehaus.org/browse/MRELEASE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154563#action_154563 ] Dan Tran commented on MRELEASE-388: --- MRELEASE-3 related? @requiresDependencyResolution on prepare mojo causes build to look for its own dependencies --- Key: MRELEASE-388 URL: http://jira.codehaus.org/browse/MRELEASE-388 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-8 Reporter: James William Dumay Priority: Critical Fix For: 2.0-beta-9 Attachments: release-fail.txt, release-fail.txt, removed-doclet.patch @requiresDependencyResolution on prepare mojo causes build to look for its own dependencies. Depending on the amount of modules you have this can take a very long time. I recommend the removal of this doclet as I don't think it really adds any value to resolve all dependencies before a release prepare can go ahead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-3) release:prepare should not require multimodule artifacts to be in the local repository
[ http://jira.codehaus.org/browse/MRELEASE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154565#action_154565 ] Dan Tran commented on MRELEASE-3: - setting preparationGoals=clean install will work, but for a large project with daily release, the build time is double. release:prepare should not require multimodule artifacts to be in the local repository -- Key: MRELEASE-3 URL: http://jira.codehaus.org/browse/MRELEASE-3 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: John Casey Assignee: Emmanuel Venisse Fix For: 2.0-beta-9 Currently, if you try to run release:prepare on a multimodule project after removing any of that build's artifacts from the local repository, it will fail. Investigate why release:prepare needs the multimodule artifacts installed in the local repository before it can succeed. To reproduce, comment the following line in it2002/test.sh: mvn clean install NOTE: This may have to do with the version resolution code, which is used to resolve SNAPSHOT versions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPIR-135) NPE if license URL is not defined
[ http://jira.codehaus.org/browse/MPIR-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154572#action_154572 ] Benno Markiewicz commented on MPIR-135: --- The reason is the comparison using a null string. Line 156: Actual: if ( urlValidator.isValid( url ) || url.startsWith( file:// ) ) Fix if ( urlValidator.isValid( url ) || StringUtils.defaultString(url).startsWith( file:// ) ) NPE if license URL is not defined - Key: MPIR-135 URL: http://jira.codehaus.org/browse/MPIR-135 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: license Affects Versions: 2.1 Environment: maven 2.0.9 java 1.5 Reporter: Andreas Höhmann [INFO] [site:site] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.report.projectinfo.LicenseReport.getLicenseURL(LicenseReport.java:156) at org.apache.maven.report.projectinfo.LicenseReport.canGenerateReport(LicenseReport.java:114) at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.filterReports(AbstractSiteRenderingMojo.java:177) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:81) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:49 9) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav a:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) $ at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-60) Source Excludes are being applied to WAR file
[
http://jira.codehaus.org/browse/MWAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154605#action_154605
]
Paul Benedict commented on MWAR-60:
---
For posterity, here is the solution. It turns out the trick is not specifying
the ${basedir} at all in the excludes:
warSourceExcludesWEB-INF/classes/**,WEB-INF/lib/**/warSourceExcludes
Source Excludes are being applied to WAR file
-
Key: MWAR-60
URL: http://jira.codehaus.org/browse/MWAR-60
Project: Maven 2.x War Plugin
Issue Type: Bug
Affects Versions: 2.0.2
Environment: WinXP, jdk1.5.0_07, mvn 2.0.4
Reporter: Chuck Deal
Assignee: Stephane Nicoll
Fix For: 2.1-alpha-2
My scenario:
I use Eclipse 3.1.1 to develop the web app. I run Tomcat 5.5.17 with it's
docbase pointed at the source tree (/src/main/webapp). As a result, I have
files that are required by Tomcat to run, but not to be included in the WAR.
Specifically, I have a WEB-INF folder with a classes directory that includes
classes that will actually be included in the WAR as a JAR (as well as a few
other things).
As you can see in the following plugin snippet, I specifically exclude the
WEB-INF folder from the source tree because all of its contents will be
gathered by the various stages of the build process (process-resources, etc)
and included in the WAR when it is exploded
I had been using the following plugin snippet for generating my War (war
plugin 2.0)
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.0/version
configuration
webXmltarget/jspweb.xml/webXml
warNameaims/warName
excludes**/*.jsp*, **/JasperReports/*.*, **/WEB-INF/**/*.*/excludes
/configuration
/plugin
If you change the version from 2.0 to 2.0.1, you will no longer generate the
same WAR file! Instead, v2.0.1 uses the source excludes and applies them to
the WAR construction as well. This means that the exploded WEB-INF (the
correct one) is also removed from the WAR file.
I don't think that the source excludes should be applied to the WAR
construction, only to the stage where the source files are exploded (as in
v2.0)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MWAR-60) Source Excludes are being applied to WAR file
[
http://jira.codehaus.org/browse/MWAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154605#action_154605
]
paul4christ79 edited comment on MWAR-60 at 11/18/08 10:49 AM:
--
For posterity, here is the solution. It turns out the trick is not specifying
the ${basedir} at all in the excludes:
{noformat}warSourceExcludesWEB-INF/classes/**,WEB-INF/lib/**/warSourceExcludes{noformat}
was (Author: paul4christ79):
For posterity, here is the solution. It turns out the trick is not
specifying the ${basedir} at all in the excludes:
warSourceExcludesWEB-INF/classes/**,WEB-INF/lib/**/warSourceExcludes
Source Excludes are being applied to WAR file
-
Key: MWAR-60
URL: http://jira.codehaus.org/browse/MWAR-60
Project: Maven 2.x War Plugin
Issue Type: Bug
Affects Versions: 2.0.2
Environment: WinXP, jdk1.5.0_07, mvn 2.0.4
Reporter: Chuck Deal
Assignee: Stephane Nicoll
Fix For: 2.1-alpha-2
My scenario:
I use Eclipse 3.1.1 to develop the web app. I run Tomcat 5.5.17 with it's
docbase pointed at the source tree (/src/main/webapp). As a result, I have
files that are required by Tomcat to run, but not to be included in the WAR.
Specifically, I have a WEB-INF folder with a classes directory that includes
classes that will actually be included in the WAR as a JAR (as well as a few
other things).
As you can see in the following plugin snippet, I specifically exclude the
WEB-INF folder from the source tree because all of its contents will be
gathered by the various stages of the build process (process-resources, etc)
and included in the WAR when it is exploded
I had been using the following plugin snippet for generating my War (war
plugin 2.0)
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.0/version
configuration
webXmltarget/jspweb.xml/webXml
warNameaims/warName
excludes**/*.jsp*, **/JasperReports/*.*, **/WEB-INF/**/*.*/excludes
/configuration
/plugin
If you change the version from 2.0 to 2.0.1, you will no longer generate the
same WAR file! Instead, v2.0.1 uses the source excludes and applies them to
the WAR construction as well. This means that the exploded WEB-INF (the
correct one) is also removed from the WAR file.
I don't think that the source excludes should be applied to the WAR
construction, only to the stage where the source files are exploded (as in
v2.0)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-140) Tests fail during release:perform but work elsewhere
[
http://jira.codehaus.org/browse/MRELEASE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154606#action_154606
]
Lammert Westerhoff commented on MRELEASE-140:
-
I have the same problem with my project. Currently this block my company from
using this plugin, which would make life a lot easier if we could use it.
During the execution of my test I get a ClassNotFoundException so it's
definitely the same problem and I think it has to do with jars with
classifiers. My project has to dependencies to the same project but with a
different classifier.
E.g.
a-1.0.jar
a-1.0-tests.jar
The class that could not be found is in the normal a-1.0.jar, which is not in
the classpath of the tests. The jar a-1.0-tests.jar with the tests classifier
however is in the classpath. I at some point of execution the jar with the
classifier overwrites the normal jar.
Also just like described above, running the tests normal without the release
plugin with mvn test or any other normal lifecycle phase works fine.
Since this case happens in a complex project with many dependencies its hard to
find out if this is really the problem but I will try to create a simple
reproduction and submit it here.
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
Issue Type: Bug
Affects Versions: 2.0-beta-4
Environment: Maven 2.0.4. Linux
Reporter: Adrian
Priority: Blocker
Attachments: com.dolby.pics.core.ejb.bean.CountryBeanTestCase.txt,
perform-output, TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml,
WORKING-TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml
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
[jira] Commented: (MRELEASE-140) Tests fail during release:perform but work elsewhere
[
http://jira.codehaus.org/browse/MRELEASE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154613#action_154613
]
Lammert Westerhoff commented on MRELEASE-140:
-
The stacktrace:
[INFO] java.lang.NoClassDefFoundError: com/.../AdoService
[INFO] at java.lang.Class.getDeclaredMethods0(Native Method)
[INFO] at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
[INFO] at java.lang.Class.getMethod0(Class.java:2670)
[INFO] at java.lang.Class.getMethod(Class.java:1603)
[INFO] at
org.easymock.internal.ObjectMethodsFilter.init(ObjectMethodsFilter.java:32)
[INFO] at org.easymock.internal.MocksControl.createMock(MocksControl.java:48)
[INFO] at org.easymock.classextension.EasyMock.createMock(EasyMock.java:50)
[INFO] at
com.ac.util.test.easymock.MockedTest.createMethodMocks(MockedTest.java:93)
[INFO] at
com.ac.util.test.easymock.MockedTest.createMethodMocks(MockedTest.java:72)
[INFO] at
com.ac.util.test.easymock.runner.MockedClassMethodsRunner.createMethodRunner(MockedClassMethodsRunner.java:52)
[INFO] at
org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:71)
[INFO] at
com.ac.util.test.easymock.runner.MockedClassMethodsRunner.invokeTestMethod(MockedClassMethodsRunner.java:68)
[INFO] at
org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
[INFO] at
org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
[INFO] at
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
[INFO] at
org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
[INFO] at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
[INFO] at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
[INFO] at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
[INFO] at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
[INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[INFO] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[INFO] at java.lang.reflect.Method.invoke(Method.java:597)
[INFO] at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
[INFO] at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
[INFO] Caused by: java.lang.ClassNotFoundException:
com.ac.dms.datamodel.essentials.AdoService
[INFO] at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
[INFO] at java.security.AccessController.doPrivileged(Native Method)
[INFO] at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
[INFO] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
[INFO] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
[INFO] at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
[INFO] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
[INFO] ... 26 more
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
Issue Type: Bug
Affects Versions: 2.0-beta-4
Environment: Maven 2.0.4. Linux
Reporter: Adrian
Priority: Blocker
Attachments: com.dolby.pics.core.ejb.bean.CountryBeanTestCase.txt,
perform-output, TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml,
WORKING-TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml
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
[jira] Commented: (MRELEASE-140) Tests fail during release:perform but work elsewhere
[
http://jira.codehaus.org/browse/MRELEASE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154614#action_154614
]
Lammert Westerhoff commented on MRELEASE-140:
-
And after the previous stacktrace, the build fail with the following stacktrace:
{noformat}
[ERROR] BUILD ERROR
[INFO]
[INFO] Maven execution failed, exit code: '1'
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Maven execution failed,
exit code: '1'
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:227)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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: Maven execution
failed, exit code: '1'
at
org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:133)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
... 16 more
Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Maven
execution failed, exit code: '1'
at
org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:89)
at
org.apache.maven.shared.release.phase.RunPerformGoalsPhase.execute(RunPerformGoalsPhase.java:67)
at
org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:334)
at
org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:282)
at
org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:262)
at
org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:129)
... 18 more
Caused by: org.apache.maven.shared.release.exec.MavenExecutorException: Maven
execution failed, exit code: '1'
at
org.apache.maven.shared.release.exec.InvokerMavenExecutor.executeGoals(InvokerMavenExecutor.java:375)
at
org.apache.maven.shared.release.exec.InvokerMavenExecutor.executeGoals(InvokerMavenExecutor.java:393)
at
org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:81)
... 23 more
{noformat}
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
Issue Type: Bug
Affects Versions: 2.0-beta-4
Environment: Maven 2.0.4. Linux
Reporter: Adrian
Priority: Blocker
Attachments: com.dolby.pics.core.ejb.bean.CountryBeanTestCase.txt,
perform-output, TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml,
WORKING-TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml
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
[jira] Updated: (MNG-3850) Integrate new Profile Activators
[ http://jira.codehaus.org/browse/MNG-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane Isbell updated MNG-3850: -- Description: This is a complete replacement for the old profile activators. The new framework uses maven-shared-model component, with model containers, model data source and model properties for determining active profiles. Integrate new Profile Activators Key: MNG-3850 URL: http://jira.codehaus.org/browse/MNG-3850 Project: Maven 2 Issue Type: Task Components: Profiles Affects Versions: 3.0-alpha-2 Reporter: Brian Fox Assignee: Shane Isbell Fix For: 3.0-alpha-2 This is a complete replacement for the old profile activators. The new framework uses maven-shared-model component, with model containers, model data source and model properties for determining active 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] Commented: (MNG-3850) Integrate new Profile Activators
[ http://jira.codehaus.org/browse/MNG-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154615#action_154615 ] Shane Isbell commented on MNG-3850: --- Prototype of what this will look like: http://svn.apache.org/repos/asf/maven/components/branches/sisbell-maven-3.0-mercury/maven-project-builder/src/main/java/org/apache/maven/project/builder/profile/ Integrate new Profile Activators Key: MNG-3850 URL: http://jira.codehaus.org/browse/MNG-3850 Project: Maven 2 Issue Type: Task Components: Profiles Affects Versions: 3.0-alpha-2 Reporter: Brian Fox Assignee: Shane Isbell Fix For: 3.0-alpha-2 This is a complete replacement for the old profile activators. The new framework uses maven-shared-model component, with model containers, model data source and model properties for determining active 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] Created: (MNG-3853) Distribution Management injected by profile is not reflected by MavenProject
Distribution Management injected by profile is not reflected by MavenProject
Key: MNG-3853
URL: http://jira.codehaus.org/browse/MNG-3853
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories, Profiles
Affects Versions: 3.0-alpha-1
Reporter: Benjamin Bentmann
The cause of the user reported issue [Tycho: problem with
distributionManagement in
profile|http://www.nabble.com/Tycho%3A-problem-with-distributionManagement-in-profile-to20490017.html]
is that the aritfact repos are created in the constructor of {{MavenProject}}
but the the profiles are injected in a later step.
There is other setup code in the constructor which most likely is also affected.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2272) upload
upload --- Key: MAVENUPLOAD-2272 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2272 Project: Maven Upload Requests Issue Type: Wish Reporter: Francois Fernandes another version of the svnkit 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] Updated: (MNG-3854) switch dependency plugin to use Mercury
[ http://jira.codehaus.org/browse/MNG-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MNG-3854: -- Fix Version/s: 3.0-alpha-2 switch dependency plugin to use Mercury Key: MNG-3854 URL: http://jira.codehaus.org/browse/MNG-3854 Project: Maven 2 Issue Type: Task Components: Dependencies Affects Versions: 3.0-alpha-1 Environment: all Reporter: Oleg Gusakov Fix For: 3.0-alpha-2 As a step towards integrating Mercury into Maven - replace dependency resolution layer in dep. plugin with Mercury APIs -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-3854) switch dependency plugin to use Mercury
switch dependency plugin to use Mercury Key: MNG-3854 URL: http://jira.codehaus.org/browse/MNG-3854 Project: Maven 2 Issue Type: Task Components: Dependencies Affects Versions: 3.0-alpha-1 Environment: all Reporter: Oleg Gusakov Fix For: 3.0-alpha-2 As a step towards integrating Mercury into Maven - replace dependency resolution layer in dep. plugin with Mercury APIs -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-3855) release mercury 1.0.0-alpha-2
release mercury 1.0.0-alpha-2 - Key: MNG-3855 URL: http://jira.codehaus.org/browse/MNG-3855 Project: Maven 2 Issue Type: Sub-task Components: Artifacts and Repositories, Dependencies Reporter: Oleg Gusakov -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-188) switch to Mercury 1.0.0-alpha-2
switch to Mercury 1.0.0-alpha-2 --- Key: MDEP-188 URL: http://jira.codehaus.org/browse/MDEP-188 Project: Maven 2.x Dependency Plugin Issue Type: Task Reporter: Oleg Gusakov Assignee: Brian Fox -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2261) Automatic upload of mockito versions.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154646#action_154646 ] Szczepan Faber commented on MAVENUPLOAD-2261: - Is there something missing in this request that makes executing it so slow? It seems upload request via rsync is not really faster Automatic upload of mockito versions. - Key: MAVENUPLOAD-2261 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2261 Project: Maven Upload Requests Issue Type: Wish Reporter: Erik Brakkee Authenticity = Please contact Szczepan Faber for information about the authenticity of this request. He is the owner of the mockito.org domain. Also, my name will appear shortly on the mockito wiki at http://code.google.com/p/mockito/. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-3856) Fix interpolation to correctly treat all profile variables
Fix interpolation to correctly treat all profile variables
--
Key: MNG-3856
URL: http://jira.codehaus.org/browse/MNG-3856
Project: Maven 2
Issue Type: Bug
Reporter: Oleg Gusakov
There are several dependencies that have non-replaced variables, coming from
maven-mercury implementation:
== org.apache.maven.plugins:maven-changelog-plugin:2.1::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for
org.apache.maven.scm:maven-scm-api:${maven-scm.version}::jar ==
org.apache.maven.plugins:maven-changelog-plugin:2.1::jar
== org.apache.maven.plugins:maven-dependency-plugin:2.0::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for org.apache.maven:maven-artifact:${maven.version}::jar
== org.apache.maven.plugins:maven-dependency-plugin:2.0::jar
== org.apache.maven.plugins:maven-deploy-plugin:2.4::jar
== org.apache.maven.plugins:maven-ear-plugin:2.3.1::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for ${pom.groupId}:wagon-http-shared:1.0-beta-2::jar ==
org.apache.maven.wagon:wagon-http-lightweight:1.0-beta-2::jar ==
org.apache.maven:maven-core:2.0.6::jar ==
org.apache.maven.plugins:maven-deploy-plugin:2.4::jar
== org.apache.maven.plugins:maven-javadoc-plugin:2.4::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for
org.apache.maven.doxia:doxia-sink-api:${doxiaVersion}::jar ==
org.apache.maven.plugins:maven-javadoc-plugin:2.4::jar
== org.apache.maven.plugins:maven-plugin-plugin:2.4.3::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for
org.apache.maven.doxia:doxia-sink-api:${doxiaVersion}::jar ==
org.apache.maven.plugins:maven-plugin-plugin:2.4.3::jar
== org.apache.maven.plugins:maven-remote-resources-plugin:1.0::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for ${pom.groupId}:wagon-http-shared:1.0-beta-2::jar ==
org.apache.maven.wagon:wagon-http-lightweight:1.0-beta-2::jar ==
org.apache.maven:maven-core:2.0.5::jar ==
org.apache.maven.plugins:maven-remote-resources-plugin:1.0::jar
== org.apache.maven.plugins:maven-surefire-plugin:2.4.3::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for ${pom.groupId}:wagon-http-shared:1.0-beta-2::jar ==
org.apache.maven.wagon:wagon-http-lightweight:1.0-beta-2::jar ==
org.apache.maven:maven-core:2.0.6::jar ==
org.apache.maven.plugins:maven-surefire-plugin:2.4.3::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] Updated: (MNG-3856) Fix interpolation to correctly treat all interpolated variables
[
http://jira.codehaus.org/browse/MNG-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Gusakov updated MNG-3856:
--
Description:
There are several dependencies that have non-replaced variables, coming from
maven-mercury implementation:
{code}
== org.apache.maven.plugins:maven-changelog-plugin:2.1::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for
org.apache.maven.scm:maven-scm-api:${maven-scm.version}::jar ==
org.apache.maven.plugins:maven-changelog-plugin:2.1::jar
== org.apache.maven.plugins:maven-dependency-plugin:2.0::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for org.apache.maven:maven-artifact:${maven.version}::jar
== org.apache.maven.plugins:maven-dependency-plugin:2.0::jar
== org.apache.maven.plugins:maven-deploy-plugin:2.4::jar
== org.apache.maven.plugins:maven-ear-plugin:2.3.1::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for ${pom.groupId}:wagon-http-shared:1.0-beta-2::jar ==
org.apache.maven.wagon:wagon-http-lightweight:1.0-beta-2::jar ==
org.apache.maven:maven-core:2.0.6::jar ==
org.apache.maven.plugins:maven-deploy-plugin:2.4::jar
== org.apache.maven.plugins:maven-javadoc-plugin:2.4::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for
org.apache.maven.doxia:doxia-sink-api:${doxiaVersion}::jar ==
org.apache.maven.plugins:maven-javadoc-plugin:2.4::jar
== org.apache.maven.plugins:maven-plugin-plugin:2.4.3::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for
org.apache.maven.doxia:doxia-sink-api:${doxiaVersion}::jar ==
org.apache.maven.plugins:maven-plugin-plugin:2.4.3::jar
== org.apache.maven.plugins:maven-remote-resources-plugin:1.0::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for ${pom.groupId}:wagon-http-shared:1.0-beta-2::jar ==
org.apache.maven.wagon:wagon-http-lightweight:1.0-beta-2::jar ==
org.apache.maven:maven-core:2.0.5::jar ==
org.apache.maven.plugins:maven-remote-resources-plugin:1.0::jar
== org.apache.maven.plugins:maven-surefire-plugin:2.4.3::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for ${pom.groupId}:wagon-http-shared:1.0-beta-2::jar ==
org.apache.maven.wagon:wagon-http-lightweight:1.0-beta-2::jar ==
org.apache.maven:maven-core:2.0.6::jar ==
org.apache.maven.plugins:maven-surefire-plugin:2.4.3::jar
{code}
was:
There are several dependencies that have non-replaced variables, coming from
maven-mercury implementation:
== org.apache.maven.plugins:maven-changelog-plugin:2.1::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for
org.apache.maven.scm:maven-scm-api:${maven-scm.version}::jar ==
org.apache.maven.plugins:maven-changelog-plugin:2.1::jar
== org.apache.maven.plugins:maven-dependency-plugin:2.0::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for org.apache.maven:maven-artifact:${maven.version}::jar
== org.apache.maven.plugins:maven-dependency-plugin:2.0::jar
== org.apache.maven.plugins:maven-deploy-plugin:2.4::jar
== org.apache.maven.plugins:maven-ear-plugin:2.3.1::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for ${pom.groupId}:wagon-http-shared:1.0-beta-2::jar ==
org.apache.maven.wagon:wagon-http-lightweight:1.0-beta-2::jar ==
org.apache.maven:maven-core:2.0.6::jar ==
org.apache.maven.plugins:maven-deploy-plugin:2.4::jar
== org.apache.maven.plugins:maven-javadoc-plugin:2.4::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for
org.apache.maven.doxia:doxia-sink-api:${doxiaVersion}::jar ==
org.apache.maven.plugins:maven-javadoc-plugin:2.4::jar
== org.apache.maven.plugins:maven-plugin-plugin:2.4.3::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for
org.apache.maven.doxia:doxia-sink-api:${doxiaVersion}::jar ==
org.apache.maven.plugins:maven-plugin-plugin:2.4.3::jar
== org.apache.maven.plugins:maven-remote-resources-plugin:1.0::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for ${pom.groupId}:wagon-http-shared:1.0-beta-2::jar ==
org.apache.maven.wagon:wagon-http-lightweight:1.0-beta-2::jar ==
org.apache.maven:maven-core:2.0.5::jar ==
org.apache.maven.plugins:maven-remote-resources-plugin:1.0::jar
== org.apache.maven.plugins:maven-surefire-plugin:2.4.3::jar
org.apache.maven.mercury.metadata.MetadataTreeException: did not find
non-optional artifact for ${pom.groupId}:wagon-http-shared:1.0-beta-2::jar ==
[jira] Created: (MEV-609) The following POMs do not even parse
The following POMs do not even parse
Key: MEV-609
URL: http://jira.codehaus.org/browse/MEV-609
Project: Maven Evangelism
Issue Type: Bug
Components: Invalid POM
Reporter: Torsten Curdt
{code}
repository/acegisecurity/acegi-security/0.7.0/acegi-security-0.7.0.pom failed
Invalid byte 2 of 3-byte UTF-8 sequence.
repository/activemq/activemq-itest-ejb/1.1-G1M3/activemq-itest-ejb-1.1-G1M3.pom
failed locator.ent (No such file or directory)
repository/activemq/activemq-itest-ejb/1.2/activemq-itest-ejb-1.2.pom failed
locator.ent (No such file or directory)
repository/ant/ant/1.6.5/ant-1.6.5.pom failed The prefix xsi for attribute
xsi:schemaLocation associated with an element type project is not bound.
repository/com/javaexchangeconnector/jec/1.52_01/jec-1.52_01.pom failed The
element type artifactId must be terminated by the matching end-tag
/artifactId.
repository/com/novell/ldap/jldap/2006-09-28/jldap-2006-09-28.pom failed The
reference to entity cvsroot must end with the ';' delimiter.
repository/com/pragmaticautomation/pragautox10/1.0/pragautox10-1.0.pom failed
Invalid byte 1 of 1-byte UTF-8 sequence.
repository/easyconf/easyconf/0.9.0/easyconf-0.9.0.pom failed Invalid byte 2 of
2-byte UTF-8 sequence.
repository/generama/generama/1.2.3/generama-1.2.3.pom failed Invalid byte 1 of
1-byte UTF-8 sequence.
repository/jhunlang/jmorph/0.2/jmorph-0.2.pom failed Invalid byte 2 of 2-byte
UTF-8 sequence.
repository/net/sourceforge/jsdp/jsdp/1.0/jsdp-1.0.pom failed The prefix xsi
for attribute xsi:schemaLocation associated with an element type project is
not bound.
repository/net/sourceforge/stripes/stripes/1.3.1/stripes-1.3.1.pom failed The
string -- is not permitted within comments.
repository/org/apache/maven/continuum/continuum-parent/1.0/continuum-parent-1.0-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/maven/2.0/maven-2.0-javadoc.pom failed Content is
not allowed in prolog.
repository/org/apache/maven/maven-plugin-tools/2.0/maven-plugin-tools-2.0-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/maven-script/2.0/maven-script-2.0-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/reporting/maven-reporting/2.0/maven-reporting-2.0-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/scm/maven-scm/1.0-alpha-4/maven-scm-1.0-alpha-4-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/scm/maven-scm-managers/1.0-alpha-4/maven-scm-managers-1.0-alpha-4-javadoc.pom
failed Content is not allowed in prolog.
repository/org/apache/maven/scm/maven-scm-providers/1.0-alpha-4/maven-scm-providers-1.0-alpha-4-javadoc.pom
failed Content is not allowed in prolog.
repository/org/codehaus/gant/gant/1.0.0/gant-1.0.0.pom failed The entity copy
was referenced, but not declared.
repository/org/codehaus/gant/gant/1.0.1/gant-1.0.1.pom failed The entity copy
was referenced, but not declared.
repository/org/codehaus/gant/gant/1.0.2/gant-1.0.2.pom failed The entity copy
was referenced, but not declared.
repository/org/codehaus/gant/gant/1.1.0/gant-1.1.0.pom failed The entity copy
was referenced, but not declared.
repository/org/codehaus/gant/gant/1.1.1/gant-1.1.1.pom failed The entity copy
was referenced, but not declared.
repository/org/codehaus/gant/gant/1.1.2/gant-1.1.2.pom failed The entity copy
was referenced, but not declared.
repository/org/codehaus/gant/gant/1.2.0/gant-1.2.0.pom failed The entity copy
was referenced, but not declared.
repository/org/codehaus/gant/gant/1.3.0/gant-1.3.0.pom failed The entity copy
was referenced, but not declared.
repository/org/codehaus/jackson/jackson-lgpl/0.9.3/jackson-lgpl-0.9.3.pom
failed The element type description must be terminated by the matching
end-tag /description.
repository/org/codehaus/modello/modello/1.0-alpha-17/modello-1.0-alpha-17.pom
failed Invalid byte 1 of 1-byte UTF-8 sequence.
repository/org/codehaus/mojo/clirr-maven-plugin/2.1/clirr-maven-plugin-2.1.pom
failed Invalid byte 2 of 4-byte UTF-8 sequence.
repository/org/codehaus/mojo/clirr-maven-plugin/2.1.1/clirr-maven-plugin-2.1.1.pom
failed Invalid byte 2 of 4-byte UTF-8 sequence.
repository/org/codehaus/mojo/osxappbundle-maven-plugin/1.0-alpha-1/osxappbundle-maven-plugin-1.0-alpha-1.pom
failed Invalid byte 1 of 1-byte UTF-8 sequence.
repository/org/codehaus/mojo/solaris-maven-plugin/1.0-alpha-1/solaris-maven-plugin-1.0-alpha-1.pom
failed Invalid byte 1 of 1-byte UTF-8 sequence.
repository/org/codehaus/mvel/1.2.22-java1.4/mvel-1.2.22-java1.4.pom failed The
element type packaging must be terminated by the matching end-tag
/packaging.
repository/org/codehaus/plexus/plexus/1.0.4/plexus-1.0.4.pom failed The entity
oslash was referenced, but not declared.
repository/org/codehaus/plexus/plexus/1.0.5/plexus-1.0.5.pom failed The entity
[jira] Commented: (MDEP-188) switch to Mercury 1.0.0-alpha-2
[ http://jira.codehaus.org/browse/MDEP-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154652#action_154652 ] Brett Porter commented on MDEP-188: --- I think this would be great to experiment with on a branch, but I'm -1 to introducing an alpha dependency into any plugins, no matter how stable the code behind it might be. We have to break that habit - if Mercury is ready to be used in this context, take the extra steps to produce a 1.0.0 release first. switch to Mercury 1.0.0-alpha-2 --- Key: MDEP-188 URL: http://jira.codehaus.org/browse/MDEP-188 Project: Maven 2.x Dependency Plugin Issue Type: Task Reporter: Oleg Gusakov Assignee: Brian Fox -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-3854) switch dependency plugin to use Mercury
[ http://jira.codehaus.org/browse/MNG-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154653#action_154653 ] Brett Porter commented on MNG-3854: --- I don't think this needs an MNG issue - the MDEP one is sufficient :) switch dependency plugin to use Mercury Key: MNG-3854 URL: http://jira.codehaus.org/browse/MNG-3854 Project: Maven 2 Issue Type: Task Components: Dependencies Affects Versions: 3.0-alpha-1 Environment: all Reporter: Oleg Gusakov Fix For: 3.0-alpha-2 As a step towards integrating Mercury into Maven - replace dependency resolution layer in dep. plugin with Mercury APIs -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (ARCHETYPE-110) Maven archetype overwrites parent information
[
http://jira.codehaus.org/browse/ARCHETYPE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154659#action_154659
]
Jason Voegele commented on ARCHETYPE-110:
-
I too vote for Peter's first proposed alternative solution. This issue is
preventing me from creating a usable multi-module archetype that doesn't
require end-users to modify the pom.xml of the submodule.
Maven archetype overwrites parent information
-
Key: ARCHETYPE-110
URL: http://jira.codehaus.org/browse/ARCHETYPE-110
Project: Maven Archetype
Issue Type: Bug
Reporter: Peter Liljenberg
Priority: Critical
Fix For: 2.0-alpha-5
When creating a new archetype that I want to use for my projects I ran into
some trouble with the created/copied pom.xml.
The archetype pom.xml (\src\main\resources\archetype-resources\pom.xml) looks
like this:
project
parent
groupIdgroup/groupId
artifactIdmasterpom/artifactId
version1.0/version
/parent
modelVersion4.0.0/modelVersion
groupIdgroup/groupId
artifactId${artifactId}/artifactId
version1.0/version
/project
When I run my archetype it creates a pom.xml that looks like:
project
parent
artifactIdintegration/artifactId
groupIdgroup/groupId
version1.0/version
/parent
modelVersion4.0.0/modelVersion
groupIdgroup/groupId
artifactIdtest/artifactId
version1.0/version
/project
Where integration is the name of the pom in the folder that I'm running mvn
archetype:create from.
Digging into the source we find in DefaultArchetype.java that processTemplate
is indeed reading the parent pom and overwriting whatever was found in the
original pom.xml.
Is this really what we want to achieve? It should be possible to keep the
parent-pom from the pom.xml in the archetype since it reduces the need for
all developers to change their newly created pom.xml.
code
processTemplates
if ( parentModel != null )
{
Parent parent = new Parent();
parent.setGroupId( parentModel.getGroupId() );
if ( parent.getGroupId() == null )
{
parent.setGroupId( parentModel.getParent().getGroupId() );
}
parent.setArtifactId( parentModel.getArtifactId() );
parent.setVersion( parentModel.getVersion() );
if ( parent.getVersion() == null )
{
parent.setVersion( parentModel.getParent().getVersion() );
}
generatedModel.setParent( parent );
/code
Two alternative solutions:
* If the parent-pom is specified in the archetype-pom, don't replace it
* A parameter that we can supply that will leave the archetype-pom parent
setting untouched.
I vote for solution number 1
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-221) Enable format conversion of properties
Enable format conversion of properties -- Key: ARCHETYPE-221 URL: http://jira.codehaus.org/browse/ARCHETYPE-221 Project: Maven Archetype Issue Type: Improvement Reporter: Benjamin Papez I have a use case, where I would need to reformat an existing property and use it as default value for another property. If for instance the artifactId is my-templates, I would like to automatically suggest creating a file called MyTemplates.properties. Using _artifactId_.properties now creates my-templates.properties which does not match the Java standard naming conventions. So would it somehow be possible to define a format conversion of the arifactId property and create another property using this Camel Case convention? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (ARCHETYPE-110) Maven archetype overwrites parent information
[
http://jira.codehaus.org/browse/ARCHETYPE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Voegele updated ARCHETYPE-110:
Attachment: ARCHETYPE-110.patch
I've attached a very simple patch that implements the suggested alternative
approach.
Maven archetype overwrites parent information
-
Key: ARCHETYPE-110
URL: http://jira.codehaus.org/browse/ARCHETYPE-110
Project: Maven Archetype
Issue Type: Bug
Reporter: Peter Liljenberg
Priority: Critical
Fix For: 2.0-alpha-5
Attachments: ARCHETYPE-110.patch
When creating a new archetype that I want to use for my projects I ran into
some trouble with the created/copied pom.xml.
The archetype pom.xml (\src\main\resources\archetype-resources\pom.xml) looks
like this:
project
parent
groupIdgroup/groupId
artifactIdmasterpom/artifactId
version1.0/version
/parent
modelVersion4.0.0/modelVersion
groupIdgroup/groupId
artifactId${artifactId}/artifactId
version1.0/version
/project
When I run my archetype it creates a pom.xml that looks like:
project
parent
artifactIdintegration/artifactId
groupIdgroup/groupId
version1.0/version
/parent
modelVersion4.0.0/modelVersion
groupIdgroup/groupId
artifactIdtest/artifactId
version1.0/version
/project
Where integration is the name of the pom in the folder that I'm running mvn
archetype:create from.
Digging into the source we find in DefaultArchetype.java that processTemplate
is indeed reading the parent pom and overwriting whatever was found in the
original pom.xml.
Is this really what we want to achieve? It should be possible to keep the
parent-pom from the pom.xml in the archetype since it reduces the need for
all developers to change their newly created pom.xml.
code
processTemplates
if ( parentModel != null )
{
Parent parent = new Parent();
parent.setGroupId( parentModel.getGroupId() );
if ( parent.getGroupId() == null )
{
parent.setGroupId( parentModel.getParent().getGroupId() );
}
parent.setArtifactId( parentModel.getArtifactId() );
parent.setVersion( parentModel.getVersion() );
if ( parent.getVersion() == null )
{
parent.setVersion( parentModel.getParent().getVersion() );
}
generatedModel.setParent( parent );
/code
Two alternative solutions:
* If the parent-pom is specified in the archetype-pom, don't replace it
* A parameter that we can supply that will leave the archetype-pom parent
setting untouched.
I vote for solution number 1
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPIR-144) Dependency report introduces corruption in classpaths for other plugins
[ http://jira.codehaus.org/browse/MPIR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154685#action_154685 ] Carlos Sanchez commented on MPIR-144: - experienced here too, with my own project Dependency report introduces corruption in classpaths for other plugins --- Key: MPIR-144 URL: http://jira.codehaus.org/browse/MPIR-144 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: dependencies Affects Versions: 2.1 Environment: Maven version: 2.0.8 Java version: 1.5.0_11 OS name: linux version: 2.6.9-42.elsmp arch: i386 Family: unix (RHEL 4) Reporter: Robert Golkosky Priority: Critical Attachments: failure-run.log, maven-project-info-report-defect.tar.gz, MPIR-144-example2.zip, successful-run.log When enabling the dependency report of the project info reports plugin and generating the site for a multi-module project, it appears that the classpaths being constructed for the compile and surefire plugins are being altered. This only occurs when the dependency report is enabled, i.e. the build succeeds and the site can be generated without the dependency report enabled. I've attached a simple maven project which demonstrates the failure. You can observe the successful build by running mvn clean install site:site, and the failure scenario by enabling the profile projectReports: mvn clean install site:site -P projectReports. You can also find debug logs attached for both a successful build and a failed build. The build failure is caused by improperly adding the test jar artifact for project-a to the testCompile classpath of project-c. In the successful build scenario, project-c will receive the primary project-a jar artifact transitively through interface-b. Even more interesting is the fact that if project-c includes a direct dependency on project-a, the test jar artifact will still be added to the classpath. One final note about the sample project, removing the dependency from project-c to project-b has no impact on the build failure, but removing project-b from the reactor (i.e. comment out the project-b module from the main pom.xml) will cause the failure to go away. This problem does not occur with version 2.0.1 of the project info reports plugin. I also tried Maven 2.1-M1 to see if the problem might be resolved there, but the classpath corruption still occurs. The root cause of this problem may actually lie in a shared component like maven-dependency-tree, but I found it originally through the use of the project info reports plugin so I figured this would be a good place to start tracking it 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] Commented: (SUREFIRE-443) Provide option to merge test classpath into one directory
[
http://jira.codehaus.org/browse/SUREFIRE-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154697#action_154697
]
Anthony Whitford commented on SUREFIRE-443:
---
For those of us using JPA, EJB3, and the [Seam
Framework|http://www.seamframework.org/], this is a pretty *BIG* deal. It
would be great to have this feature so that we can easily use _SeamTest_, gain
accurate coverage analysis, and overall promote the right thing: write tests!
Provide option to merge test classpath into one directory
-
Key: SUREFIRE-443
URL: http://jira.codehaus.org/browse/SUREFIRE-443
Project: Maven Surefire
Issue Type: New Feature
Components: classloading
Affects Versions: 2.4
Environment: Maven 2.0.8
Reporter: Cory Prowse
Priority: Minor
Fix For: Future
Please provide an option for the test classpath to be merged into one
directory.
Maven sets up the class files as follows:
{noformat}
|-- target/test-classes
| `-- Unit Test classes
|-- target/classes
`-- Classes to be tested
{noformat}
When running unit tests, the desired outcome is for any file in the
target/test-classes tree to override those in the target/classes.
Specifically that any file in classes is ignored and overridden by the file
in test-classes for the tests to work as expected.
(In a sense a union on these two file trees in the order specified)
The problem arises when using a container such as Embedded JBoss to test
which treats each directory as a separate scope for classloading.
Reading the ejb-3_0-fr-spec-persistence.pdf section 6.2.2 Persistence Unit
Scope spells it out quite clearly (a very short one page read) that if the
target/test-classes and target/classes are each treated as a separate
ejb-jar, then the runtime environment is not going to work due to these
scoping rules.
I have an ugly hack in place as follows which has the desired effect, but it
would be more preferable if instead Maven Surefire provided an option to
merge the directories together and have just one directory in the test
classpath.
{noformat}
build
plugins
...
plugin
!-- This correctly merges the test-classes and classes
directories for an EE container --
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idsetupTestClasspath/id
phasetest-compile/phase
configuration
tasks
echo message=Setting up a single merged
test classpath directory /
!-- move the originals --
mkdir dir=${basedir}/target/tmp /
move file=${basedir}/target/classes
todir=${basedir}/target/tmp /
move file=${basedir}/target/test-classes
todir=${basedir}/target/tmp /
!-- Merge into new directory --
copy todir=${basedir}/target/test-classes
overwrite=true
fileset
dir=${basedir}/target/tmp/test-classes /
/copy
copy todir=${basedir}/target/test-classes
overwrite=false
fileset
dir=${basedir}/target/tmp/classes /
/copy
mkdir dir=${basedir}/target/classes /
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
execution
idrestoreTestClasspath/id
phasetest/phase
configuration
tasks
echo message=Restoring original classes
directories /
delete dir=${basedir}/target/classes /
move file=${basedir}/target/test-classes
tofile=${basedir}/target/test-classes-MERGED /
move file=${basedir}/target/tmp/classes
todir=${basedir}/target /
move
file=${basedir}/target/tmp/test-classes todir=${basedir}/target /
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
/plugin
...
{noformat}
--
This message is
