[jira] Commented: (SUREFIRE-339) Surefire plugin error message does not indicate the source of the error.
[ http://jira.codehaus.org/browse/SUREFIRE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105895 ] Brett Porter commented on SUREFIRE-339: --- that seems to be a different problem - perhaps there is already an open surefire bug for that? The fix I put in pace for this is simply to say that the test failures can be found in "target/surefire-reports" (or other directory if that is configured) > Surefire plugin error message does not indicate the source of the error. > > > Key: SUREFIRE-339 > URL: http://jira.codehaus.org/browse/SUREFIRE-339 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.3 > Environment: maven 2.0.6 > jdk 1.5.0_08 > Windows 2003 >Reporter: md >Assignee: Brett Porter > Fix For: 2.3.1 > > > I have been getting test failures. But maven provides no hints as to the root > cause of the failures. I have tried using the -X and the -e options, but all > I get is this. I don't konw if this is a maven issue or a surefire plugin > issue. But, the exceptions should have enough data on what tests failed. This > has made it impossible for us to track down the issue. This doesn't happend > on developer machines. It only happens on teh build machine that we are > trying to setup. > The command we ran was: > mvn -e clean test > [ERROR] BUILD FAILURE > INFO] > INFO] There are test failures. > INFO] > INFO] Trace > rg.apache.maven.BuildFailureException: There are test failures. >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor. >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) >at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) >at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >at java.lang.reflect.Method.invoke(Method.java:585) >at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) >at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) >at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) >at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > aused by: org.apache.maven.plugin.MojoFailureException: There are test > failures. >at > org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:425) >at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) >... 16 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-339) Surefire plugin error message does not indicate the source of the error.
[ http://jira.codehaus.org/browse/SUREFIRE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105894 ] md commented on SUREFIRE-339: - I would like this re-opened. I have tested using the 2.4-SNAPSHOT version of the plugin and i still get the same build failure exception. I have the command line from the debug output of maven: D:\projects\had\main>C:\Java\jdk1.5.0_08\jre\bin\java -classpath D:\java\maven\.m2\repository\org\codehaus\plexus\plexus-archiver\ 1.0-alpha-7\plexus-archiver-1.0-alpha-7.jar;D:\java\maven\.m2\repository\org\codehaus\plexus\plexus-utils\1.4.5\plexus-utils-1.4.5.jar;D:\ja va\maven\.m2\repository\junit\junit\3.8.1\junit-3.8.1.jar;D:\java\maven\.m2\repository\org\codehaus\plexus\plexus-container-default\1.0-alph a-8\plexus-container-default-1.0-alpha-8.jar;D:\java\maven\.m2\repository\org\apache\maven\surefire\surefire-booter\2.4-SNAPSHOT\surefire-bo oter-2.4-SNAPSHOT.jar;D:\java\maven\.m2\repository\classworlds\classworlds\1.1-alpha-2\classworlds-1.1-alpha-2.jar;D:\java\maven\.m2\reposit ory\org\apache\maven\surefire\surefire-api\2.4-SNAPSHOT\surefire-api-2.4-SNAPSHOT.jar;D:\java\maven\.m2\repository\commons-lang\commons-lang \2.1\commons-lang-2.1.jar org.apache.maven.surefire.booter.SurefireBooter C:\temp\surefire10121tmp C:\temp\surefire10122tmp org.apache.maven.surefire.booter.SurefireExecutionException: Unable to instantiate and execute Surefire; nested exception is java.lang.Class NotFoundException: org.apache.maven.surefire.Surefire java.lang.ClassNotFoundException: org.apache.maven.surefire.Surefire at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.maven.surefire.booter.IsolatedClassLoader.loadClass(IsolatedClassLoader.java:103) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:304) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:907) > Surefire plugin error message does not indicate the source of the error. > > > Key: SUREFIRE-339 > URL: http://jira.codehaus.org/browse/SUREFIRE-339 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.3 > Environment: maven 2.0.6 > jdk 1.5.0_08 > Windows 2003 >Reporter: md >Assignee: Brett Porter > Fix For: 2.3.1 > > > I have been getting test failures. But maven provides no hints as to the root > cause of the failures. I have tried using the -X and the -e options, but all > I get is this. I don't konw if this is a maven issue or a surefire plugin > issue. But, the exceptions should have enough data on what tests failed. This > has made it impossible for us to track down the issue. This doesn't happend > on developer machines. It only happens on teh build machine that we are > trying to setup. > The command we ran was: > mvn -e clean test > [ERROR] BUILD FAILURE > INFO] > INFO] There are test failures. > INFO] > INFO] Trace > rg.apache.maven.BuildFailureException: There are test failures. >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor. >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) >at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) >at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >at java.lang.reflect.Method.invoke(Method.java:585) >at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) >at org.codehaus.classworlds.Launcher.launch(Launcher.ja
[jira] Created: (MAVENUPLOAD-1694) Please sync with maven-sar repo
Please sync with maven-sar repo --- Key: MAVENUPLOAD-1694 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1694 Project: maven-upload-requests Issue Type: Task Reporter: Tom Cort Please sync with maven-sar's repo. The shell can be found at http://maven-sar.sourceforge.net/net.sf.maven-sar.sh The repo contains jars for binary, source and javadoc, release 0.9. I'm already subscribed to the [EMAIL PROTECTED] list -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-298) Problem using -javaagent
[
http://jira.codehaus.org/browse/SUREFIRE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105885
]
Julian Wood commented on SUREFIRE-298:
--
It works with 2.4-SNAPSHOT, fwiw.
maven-surefire-plugin
-javaagent:${user.home}/.m2/repository/mockit/jmockit/0.8.5/jmockit-0.8.5.jar
true
> Problem using -javaagent
>
>
> Key: SUREFIRE-298
> URL: http://jira.codehaus.org/browse/SUREFIRE-298
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.0 (2.2 plugin)
> Environment: Windows XP
>Reporter: Bård Dybwad Kristensen
> Fix For: 2.4
>
>
> I try to run the JMockit framework in my tests to do some mocking of static
> classes.
> I supply the argLine arguments as follows (some spaces added to avoid
> smileys):
>
> -javaagent:D : \
> .m2\repository\jmockit\jmockit\0.83\jmockit-0.83.jar
> once
>
> This does not work. The problem is that the Mockit class is not able to find
> neither the class it is suppose to mock nor the class to use as a mock. I
> have made two small classes, Math and MockMath each with one similar method
> and one static String constant. My setup-method in the testclass is as
> follows:
> protected void setUp() throws Exception {
> super.setUp();
> System.out.println(Math.TEST);
> System.out.println(MockMath.TEST);
> Mockit.redefineMethods(Math.class, MockMath.class);
> }
> When I run this, the two System.out.printlns runs Ok, and prints what it
> should, but the Mockit class returns the following error:
> java.lang.RuntimeException: Failed to read class file for
> no.ergo.ec.vaktplan.MockMath
> at mockit.Mockit.readClassFile(Mockit.java:228)
> at mockit.Mockit.collectMockMethods(Mockit.java:191)
> at mockit.Mockit.redefineMethods(Mockit.java:176)
> at mockit.Mockit.redefineMethods(Mockit.java:162)
> at no.ergo.ec.vaktplan.TestMain.setUp(TestMain.java:12)
> at junit.framework.TestCase.runBare(TestCase.java:125)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
> 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
> Caused by: java.io.IOException: Class not found
> at org.objectweb.asm2.ClassReader.readClass(ClassReader.java:259)
> at org.objectweb.asm2.ClassReader.(ClassReader.java:236)
> at org.objectweb.asm2.ClassReader.(ClassReader.java:246)
> at mockit.Mockit.readClassFile(Mockit.java:225)
> It is not able to find the class, which was ok in the System.out run just
> before.
> If I do a mvn eclipse:eclipse and create an eclipse project, I can run the
> test class without any problems in Eclipse (with exactly tha same VM
> arguments as I use in the pom.xml)
> So I guess it is some issue with which classloader that loads the Mockit
> class when it is supplied as the instrumentation class via the -javaagent
> switch.
> Anybody experience any problems like this using the -javaagent switch?
> Any feedback would be greatly appreciated.
> regards,
> bdk
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.
[jira] Commented: (SUREFIRE-298) Problem using -javaagent
[
http://jira.codehaus.org/browse/SUREFIRE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105884
]
Julian Wood commented on SUREFIRE-298:
--
I tried Peter's suggestion with surefire version 2.2 and 2.3 (did you mean from
the repo?) and I get this error (the same error as without
useSystemClassLoader):
FATAL ERROR in native method: processing of -javaagent failed
Exception in thread "main" java.lang.NoClassDefFoundError:
org/objectweb/asm2/ClassVisitor
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2365)
at java.lang.Class.getMethod0(Class.java:2611)
at java.lang.Class.getMethod(Class.java:1579)
at
sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:135)
[INFO]
[ERROR] BUILD FAILURE
Yes, the mocks work if I run the unit tests with jmockit and jmockit-asm2 on
the classpath (ie using ant , ant-run or in IJ Idea).
> Problem using -javaagent
>
>
> Key: SUREFIRE-298
> URL: http://jira.codehaus.org/browse/SUREFIRE-298
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.0 (2.2 plugin)
> Environment: Windows XP
>Reporter: Bård Dybwad Kristensen
> Fix For: 2.4
>
>
> I try to run the JMockit framework in my tests to do some mocking of static
> classes.
> I supply the argLine arguments as follows (some spaces added to avoid
> smileys):
>
> -javaagent:D : \
> .m2\repository\jmockit\jmockit\0.83\jmockit-0.83.jar
> once
>
> This does not work. The problem is that the Mockit class is not able to find
> neither the class it is suppose to mock nor the class to use as a mock. I
> have made two small classes, Math and MockMath each with one similar method
> and one static String constant. My setup-method in the testclass is as
> follows:
> protected void setUp() throws Exception {
> super.setUp();
> System.out.println(Math.TEST);
> System.out.println(MockMath.TEST);
> Mockit.redefineMethods(Math.class, MockMath.class);
> }
> When I run this, the two System.out.printlns runs Ok, and prints what it
> should, but the Mockit class returns the following error:
> java.lang.RuntimeException: Failed to read class file for
> no.ergo.ec.vaktplan.MockMath
> at mockit.Mockit.readClassFile(Mockit.java:228)
> at mockit.Mockit.collectMockMethods(Mockit.java:191)
> at mockit.Mockit.redefineMethods(Mockit.java:176)
> at mockit.Mockit.redefineMethods(Mockit.java:162)
> at no.ergo.ec.vaktplan.TestMain.setUp(TestMain.java:12)
> at junit.framework.TestCase.runBare(TestCase.java:125)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
> 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
> Caused by: java.io.IOException: Class not found
> at org.objectweb.asm2.ClassReader.readClass(ClassReader.java:259)
> at org.objectweb.asm2.ClassReader.(ClassReader.java:236)
> at org.objectweb.asm2.ClassReader.(ClassReader.java:246)
> at mockit.Mockit.readClassFile(Mockit.java:225)
> I
[jira] Created: (MANT-31) test dependencies are not included
test dependencies are not included -- Key: MANT-31 URL: http://jira.codehaus.org/browse/MANT-31 Project: Maven 2.x Ant Plugin Issue Type: Bug Affects Versions: 2.0-beta-1 Reporter: Robert Egglestone The generated build file should include any dependencies from the pom with a scope of test on the test classpath, and download them in get-deps. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MANT-8) The generated "get-deps" target uses the "get" target - would be better to use Maven Ant Tasks
[ http://jira.codehaus.org/browse/MANT-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105882 ] Robert Egglestone commented on MANT-8: -- I use the Ant plugin to provide an alternative for users that won't install Maven. It's likely that these users will not have Maven's Ant Tasks installed. > The generated "get-deps" target uses the "get" target - would be better to > use Maven Ant Tasks > -- > > Key: MANT-8 > URL: http://jira.codehaus.org/browse/MANT-8 > Project: Maven 2.x Ant Plugin > Issue Type: Improvement >Reporter: Matt Raible > > It seems like it would be much better (and cleaner) to use Maven's own Ant > Tasks rather than the task. The task takes a lot longer to run > and often spits out useless logging to the end user. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1333) show in project group summary per project also the status counters (as they are shown on the project groups pages)
[ http://jira.codehaus.org/browse/CONTINUUM-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105881 ] Emmanuel Venisse commented on CONTINUUM-1333: - simple patch applied. We need a discussion on the dev list about the big patch. Olivier can you start it? > show in project group summary per project also the status counters (as they > are shown on the project groups pages) > --- > > Key: CONTINUUM-1333 > URL: http://jira.codehaus.org/browse/CONTINUUM-1333 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.1-alpha-2 >Reporter: tony nys >Assignee: Olivier Lamy >Priority: Minor > Fix For: 1.1-beta-3 > > Attachments: CONTINUUM-1333, CONTINUUM-1333, screenshot-1.jpg > > > show in project group summary per project also the status counters (as they > are shown on the project groups pages) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1396) Continuum should have a separate permission to administer schedules
[ http://jira.codehaus.org/browse/CONTINUUM-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1396. --- Resolution: Fixed applied. > Continuum should have a separate permission to administer schedules > --- > > Key: CONTINUUM-1396 > URL: http://jira.codehaus.org/browse/CONTINUUM-1396 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.1-beta-2 >Reporter: Brett Porter >Assignee: Olivier Lamy > Fix For: 1.1-beta-3 > > Attachments: CONTINUUM-1396 > > > like we have for profiles and installations 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] Closed: (CONTINUUM-1366) surefire report shown is always latest, even with a different build number
[ http://jira.codehaus.org/browse/CONTINUUM-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1366. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.1-beta-3 Fixed by CONTINUUM-1411 > surefire report shown is always latest, even with a different build number > -- > > Key: CONTINUUM-1366 > URL: http://jira.codehaus.org/browse/CONTINUUM-1366 > Project: Continuum > Issue Type: Improvement > Components: Web - UI >Affects Versions: 1.1-beta-1 >Reporter: Brett Porter >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-3 > > > I think this is because it is generated from the target/surefire-reports XML > files - if that's the case, we should remove the link in the old reports and > only show it if the build is the latest one -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1411) Link to display build surefire report doesn't work (in fact displaying surefire report per build is false)
[ http://jira.codehaus.org/browse/CONTINUUM-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1411. --- Resolution: Fixed Applied > Link to display build surefire report doesn't work (in fact displaying > surefire report per build is false) > -- > > Key: CONTINUUM-1411 > URL: http://jira.codehaus.org/browse/CONTINUUM-1411 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.1-beta-2 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Critical > Fix For: 1.1-beta-3 > > Attachments: CONTINUUM-1411 > > > Since 1.1-beta-2, the surefire report link in a build result page is not > displayed anymore. > But in fact, It has never worked or it's confusing. Because the link is in > the BuildResult and in fact the surefire -report is the last surefire report > (because we don't save all surefire reports for all builds). > Try the Surefire Report in this two build result : > http://maven.zones.apache.org/continuum/buildResult.action?buildId=7072&projectId=44 > http://maven.zones.apache.org/continuum/buildResult.action?buildId=16143&projectId=44 > My proposal is to move this link to the buildResults page and call the link > Last Surefire Report. > Or we can backup all surefire reports (probably too huge) > Thoughs ? > -- > Olivier -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MJAVADOC-108) proxy support for plugin not complete enough
[
http://jira.codehaus.org/browse/MJAVADOC-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105877
]
Alexander Shvets commented on MJAVADOC-108:
---
I also have problem with latest javadoc plugin (2.3) and maven 2.0.7, when I'm
not behind the firewall. It cannot convert proxy port number ("") to int. This
fragment fix the problem:
org.apache.maven.plugins
maven-javadoc-plugin
0
But it should be fixed programmatically.
> proxy support for plugin not complete enough
>
>
> Key: MJAVADOC-108
> URL: http://jira.codehaus.org/browse/MJAVADOC-108
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Barrie Treloar
>
> AbstractJavadocMojo.java supports
> * @parameter expression="${proxyHost}"
> default-value="${settings.activeProxy.host}"
> * @parameter expression="${proxyPort}"
> default-value="${settings.activeProxy.port}"
> but does not include the full capabilities of settings.xml
> This needs extending.
> line 981:
> {code:language=java}
> if ( StringUtils.isNotEmpty( proxyHost ) && proxyPort > 0 )
> {
> cmd.createArgument().setValue( "-J-DproxyHost=" + proxyHost );
> cmd.createArgument().setValue( "-J-DproxyPort=" + proxyPort );
> }
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1412) File Inclusion Vulnerability
[ http://jira.codehaus.org/browse/CONTINUUM-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1412. --- Assignee: Emmanuel Venisse Resolution: Fixed Applied, thanks. > File Inclusion Vulnerability > > > Key: CONTINUUM-1412 > URL: http://jira.codehaus.org/browse/CONTINUUM-1412 > Project: Continuum > Issue Type: Bug > Components: Security >Affects Versions: 1.1-beta-2 > Environment: Java version: 1.5.0_10 > OS name: "linux" version: "2.6.16.49-xen-osl4-ipsec-domu" arch: "i386" >Reporter: Tom Cort >Assignee: Emmanuel Venisse >Priority: Critical > Fix For: 1.1-beta-3 > > Attachments: CONTINUUM-1412.patch, continuum.JPG > > > The value of the userDirectory variable used when calling workingCopy.action > is not filtered properly. This gives anyone who can access workingCopy.action > the ability to read any file on the file system with the permissions that > jetty is running as. > For example, let's say we have continuum installed in /usr/local/continuum. > Say we have a project named build-tools with a projectId of 10. Using the > following URL, I can display the contents of /proc/version (see attached > screenshot). > http://some-server.domain.com:8080/continuum/workingCopy.action?projectId=10&projectName=build-tools&userDirectory=../../../../../../../../../proc/&file=version > This is really bad if the user is running continuum as root because it gives > the attacker access to every file on the file system. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1393) change sets are duplicated on multiple failed builds
[ http://jira.codehaus.org/browse/CONTINUUM-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1393. --- Assignee: Emmanuel Venisse Resolution: Fixed > change sets are duplicated on multiple failed builds > > > Key: CONTINUUM-1393 > URL: http://jira.codehaus.org/browse/CONTINUUM-1393 > Project: Continuum > Issue Type: Bug > Components: Database >Affects Versions: 1.1-beta-2 >Reporter: Brett Porter >Assignee: Emmanuel Venisse >Priority: Critical > Fix For: 1.1-beta-3 > > Attachments: files.txt.bz2 > > > This is being seen on Tuscany SCA. Because every build fails, the change set > is attached to each - and it was the first checkout so every file is listed > as "added". > See the attached file for the result: some 87 copies of most files are in > there, and almost 364000 lines long. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1394) continuum should not record change sets when it is a new checkout
[ http://jira.codehaus.org/browse/CONTINUUM-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1394. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.1-beta-3 > continuum should not record change sets when it is a new checkout > - > > Key: CONTINUUM-1394 > URL: http://jira.codehaus.org/browse/CONTINUUM-1394 > Project: Continuum > Issue Type: Improvement > Components: Database >Affects Versions: 1.1-beta-2 >Reporter: Brett Porter >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-3 > > > it might be nice to report "new checkout from revision X", if that makes > sense, but other than that I think we should not add all the files when it is > a new checkout to the build result. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-352) Get rid of hardcoded TestNG dependency name.
Get rid of hardcoded TestNG dependency name.
Key: SUREFIRE-352
URL: http://jira.codehaus.org/browse/SUREFIRE-352
Project: Maven Surefire
Issue Type: Improvement
Components: TestNG support
Affects Versions: 2.4
Reporter: jdoe
Attachments: custom_testng_dep_name.diff
The name of the TestNG dependency is hardcoded ('org.testng:testng'). Some ppl
are using internal repositories where artifacts are published under different
names. It would be nice to able to specify the name of dependency, e.g.:
{code:title=build.pom|borderStyle=solid}
org.apache.maven.plugins
maven-surefire-plugin
2.4-SNAPSHOT
testng:testng
testng.xml
{code}
Proposed patch attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3168) Correct error message when project descriptor not found
Correct error message when project descriptor not found --- Key: MNG-3168 URL: http://jira.codehaus.org/browse/MNG-3168 Project: Maven 2 Issue Type: Improvement Components: Bootstrap & Build Reporter: Chris Eldredge When using the "-f" switch and passing the name of a file which does not exist, Maven complains about pom.xml, not the alternate file name. For example, the command: mvn -f foo.xml install produces this error message: Cannot execute mojo: resources. It requires a project with an existing pom.xml, but the build is not using one. This error message is confusing and incorrect. Maven should instead report that the file "foo.xml" could not be loaded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1693) Upload truezip
Upload truezip -- Key: MAVENUPLOAD-1693 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1693 Project: maven-upload-requests Issue Type: Bug Reporter: Asankha Perera http://people.apache.org/~asankha/temp/truezip-upload.jar https://truezip.dev.java.net/ TrueZIP is a Java based Virtual File System (VFS) which enables client applications to access ZIP, TAR and derivative archive types transparently as if they were just directories in a file's path name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSITE-171) Site plugin uses plain dependencies for reactor projects instead of results of earlier modules
[ http://jira.codehaus.org/browse/MSITE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105851 ] Sebastian Davids commented on MSITE-171: This happens to me even w/ -Dmaven.test.failure.ignore=true not set. > Site plugin uses plain dependencies for reactor projects instead of results > of earlier modules > -- > > Key: MSITE-171 > URL: http://jira.codehaus.org/browse/MSITE-171 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: Win XP, Linux >Reporter: Alex Rau > > When creating a multi-module site the site plugin uses dependencies from > related modules from the repository instead of using artifacts from the same > execution. > That causes inconsistent reports on the sites. An example: > Project A has modules B and C defined. B is build first and a site for > project B is created. Then project C is build using a dependency either from > the local or remote repository. Therefore the site contains results which > rely on a build with an "out-dated" artifact used as dependency. This leads > to plainly wrong results when examining surefire-reports as Project C should > have been build with the (current) artifact of project B (taken from the same > execution of the site plugin). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-135) Error parsing javadoc version when used with IBM jdk 1.4.2
[ http://jira.codehaus.org/browse/MJAVADOC-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105848 ] Oddmar Sandvik commented on MJAVADOC-135: - The same problem exists for IBM JRE 1.5: J2RE 1.5.0 IBM Windows 32 build pwi32devifx-20070323 (ifix 117674: SR4 + 116644 + 114941 + 116110 + 114881) > Error parsing javadoc version when used with IBM jdk 1.4.2 > -- > > Key: MJAVADOC-135 > URL: http://jira.codehaus.org/browse/MJAVADOC-135 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: IBM JDK 1.4.2 >Reporter: Manuel Santillán > > Error parsing javadocVersion in plugin 2.3 when using IBM JDK. Plugin works > fine in version 2.2. > java.lang.NumberFormatException: For input string: "J2R" > at > java.lang.NumberFormatException.forInputString(NumberFormatException.java:63) > at > java.lang.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1230) > at java.lang.Float.parseFloat(Float.java:246) > at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.getJavadocVersion(AbstractJavadocMojo.java:2966) > at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1085) > at > org.apache.maven.plugin.javadoc.JavadocJar.execute(JavadocJar.java:108) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) > at java.lang.reflect.Method.invoke(Method.java:391) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > > [INFO] Total time: 18 seconds > [INFO] Finished at: Mon Jul 23 10:57:16 CEST 2007 > [INFO] Final Memory: 12M/512M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1692) java exchange connector (jec-1.53_11.jar) dependency correction
java exchange connector (jec-1.53_11.jar) dependency correction --- Key: MAVENUPLOAD-1692 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1692 Project: maven-upload-requests Issue Type: Wish Reporter: eli hasson this is a correction to the last post (jec-1.53_11.jar). jdom dependency was not correct in the pom.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2061) DistributionManagement properties don't get copied in cloned executionProject while lifecycle fork
[ http://jira.codehaus.org/browse/MNG-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jan ancajas updated MNG-2061: - Attachment: MNG-2061-maven-project.patch attached patch and unit test. releaseArtifactRepository and snapshotArtifactRepository fields are not copied to the cloned MavenProject object when the project lifecycle is forked. (thanks brett. :) > DistributionManagement properties don't get copied in cloned executionProject > while lifecycle fork > -- > > Key: MNG-2061 > URL: http://jira.codehaus.org/browse/MNG-2061 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.2 >Reporter: Max Feldman > Fix For: 2.0.x > > Attachments: MNG-2061-maven-project.patch > > > Define a new Maven plugin with the goal described like this: > /** > * @execute phase="deploy" > * @goal deploy-custom > */ > When running 'mvn deploy-custom', deploy phase execution fails with 'Class > 'org.apache.maven.artifact.repository.ArtifactRepository' cannot be > instantiated'. > It seems the problem raises from the fact that > releaseArtifactRepository/snapshotArtifactRepository don't get copied in the > cloned executionProject while lifecycle fork. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-321) aborts build when pom.xml in version 3 is hit
aborts build when pom.xml in version 3 is hit - Key: MECLIPSE-321 URL: http://jira.codehaus.org/browse/MECLIPSE-321 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Environment: m2eclipse snapshot 0.0.11.20070603-1200 Reporter: manuel aldana when building a warning is given that resolved pom is of version 3. after that build crashes with message: "Unable to read model from /Bla/pom.xml " it should behave like command client mvn. provide warning message but proceed with the build. pom example, which reproduces failure (-> streambuffer references org.jvnet.staxex:stax-ex:1.0 , which is of pom version 3): http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 Bla Bla 0.0.1 javax.xml.stream streambuffer 0.3 true -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105832 ] Mikko Koponen commented on MNG-1323: Ugliest workaround yet: Since we are mostly running into this when using the maven-antrun-plugin, I redeployed the version we are using into our company-wide maven repo with a different groupId/artifactId, and am now issueing such groupIds/artifactIds to developers that require differing dependencies in their antruns. When this bug gets fixed, I'll relocate all those plugins back to the real version. > Plugin extensions (dependencies) not resolved in reactor build > -- > > Key: MNG-1323 > URL: http://jira.codehaus.org/browse/MNG-1323 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Kenney Westerhof > Fix For: 2.0.x > > Attachments: MNG-1323-core-integration-tests.diff > > > I've added a dependency on an Ant Task in > project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ > and run that anttask using the antrun plugin. > When run from the project dir itself it runs fine. > When running from the root of the project tree (reactor build, project one > level below root), > antrun bails out because the taskdef can't be found (not on classpath). > It looks like the dependency isn't resolved, or not added to the plugins' > classrealm. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-2234) activeProfile in ~/.m2/settings.xml is ignored when profiles section is missing or empty
[ http://jira.codehaus.org/browse/MNG-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105829 ] Mathias Arens commented on MNG-2234: I have the same problem with 2.0.7 and it would be great if this problem would be fixed in 2.0.8. > activeProfile in ~/.m2/settings.xml is ignored when profiles section is > missing or empty > > > Key: MNG-2234 > URL: http://jira.codehaus.org/browse/MNG-2234 > Project: Maven 2 > Issue Type: Bug > Components: Profiles, Settings >Affects Versions: 2.0.4 >Reporter: Manfred Geiler > Fix For: 2.0.x > > > When i have this settings.xml file in my user home dir, the activeProfile > setting is simply ignored by Maven: > > > env-test > > > Adding an empty profiles section does not help: > > > > > env-test > > > Well, adding a dummy profile makes it work: > > > > dummy > > > > env-test > > > Funny, isn't it? > Regards, > Manfred -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105828 ] Mikko Koponen commented on MNG-1323: Sounds to me like plugin dependencies should be execution-specific? > Plugin extensions (dependencies) not resolved in reactor build > -- > > Key: MNG-1323 > URL: http://jira.codehaus.org/browse/MNG-1323 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Kenney Westerhof > Fix For: 2.0.x > > Attachments: MNG-1323-core-integration-tests.diff > > > I've added a dependency on an Ant Task in > project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ > and run that anttask using the antrun plugin. > When run from the project dir itself it runs fine. > When running from the root of the project tree (reactor build, project one > level below root), > antrun bails out because the taskdef can't be found (not on classpath). > It looks like the dependency isn't resolved, or not added to the plugins' > classrealm. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-3166) Multi-module with 'ear' submodule, lifecycle 'process-resources' fails
[ http://jira.codehaus.org/browse/MNG-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105823 ] Stephane Nicoll commented on MNG-3166: -- Sorry, I think we're not talking about the same problem :) The problem being it does not find the EAR if it has not ever been built before? But if we do mvn install then mvn process-resources it runs ok. Is that right? > Multi-module with 'ear' submodule, lifecycle 'process-resources' fails > -- > > Key: MNG-3166 > URL: http://jira.codehaus.org/browse/MNG-3166 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.7 >Reporter: Zarick Lau > Attachments: example.tar.gz > > > Consider the following project structure: > parent/ > parent/sub-module-a > parent/sub-module-b > The packaging for 'sub-module-a' is 'jar'. > The packaging for 'sub-module-b' is 'ear'. > And 'sub-module-b' depends on 'jar'. > Running "mvn package" at parent doesn't have any error, > but running "mvn process-resources" at parent will failed with following > message. > The attachement demostrate the problem, extract it and run mvn > process-resources > can reproduce the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
