[jira] Commented: (MNG-2709) Maven 2 doesn't resolve parent test dependencies when using JDK 6
[ http://jira.codehaus.org/browse/MNG-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85852 ] Reinhard Poetz commented on MNG-2709: - It seems that maven builds a different compilation classpath under 1.6 and 1.5: http://article.gmane.org/gmane.text.xml.cocoon.devel/69786 > Maven 2 doesn't resolve parent test dependencies when using JDK 6 > - > > Key: MNG-2709 > URL: http://jira.codehaus.org/browse/MNG-2709 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 >Reporter: Matt Raible > > http://www.nabble.com/Maven-2-and-JDK-6-tf2841587s177.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1145) Change Password At Next Login should be forced to the login user
Change Password At Next Login should be forced to the login user Key: CONTINUUM-1145 URL: http://jira.codehaus.org/browse/CONTINUUM-1145 Project: Continuum Issue Type: Improvement Components: Web - Security Affects Versions: 1.0.3 Reporter: Edwin Punzalan Currently, after logging in and when prompted to change your current password, you can just click on cancel or click on any other link, and the prompt will not disturb you again until your next logon. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-170) Failed to load test: java.security.AccessControlException:
[ http://jira.codehaus.org/browse/SUREFIRE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed SUREFIRE-170. - Assignee: Brett Porter Resolution: Duplicate Fix Version/s: (was: 2.3) > Failed to load test: java.security.AccessControlException: > -- > > Key: SUREFIRE-170 > URL: http://jira.codehaus.org/browse/SUREFIRE-170 > Project: Maven Surefire > Issue Type: Bug > Components: classloading >Affects Versions: 2.0 (2.2 plugin) > Environment: windows XP SP1 and linux AS 4 > maven 2.0.4 > jdk 1.5.0_06/09 >Reporter: Christophe Lallement > Assigned To: Brett Porter > > We try to load a testsuite with a test case wich start a RMI server and we > have this error: > > mvn test > Running deai.tt.rhino.cache.mgr.CommonCacheManagerTest > INFO: Created RMIRegistry on port: 10098 > org.apache.maven.surefire.booter.SurefireExecutionException: > deai.tt.rhino.cache.mgr.CommonCacheManagerTest; nested exception is > java.security.AccessControlException: access denied > (java.lang.RuntimePermission setIO); nested exception is > org.apache.maven.surefire.testset.TestSetFailedException: > deai.tt.rhino.cache.mgr.CommonCacheManagerTest; nested exception is > java.security.AccessControlException: access denied > (java.lang.RuntimePermission setIO) > org.apache.maven.surefire.testset.TestSetFailedException: > deai.tt.rhino.cache.mgr.CommonCacheManagerTest; nested exception is > java.security.AccessControlException: access denied > (java.lang.RuntimePermission setIO) > java.security.AccessControlException: access denied > (java.lang.RuntimePermission setIO) > at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) > at > java.security.AccessController.checkPermission(AccessController.java:427) > at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) > at java.lang.System.checkIO(System.java:208) > at java.lang.System.setOut(System.java:148) > at > org.apache.maven.surefire.report.ReporterManager.resetStreams(ReporterManager.java:313) > at > org.apache.maven.surefire.report.ReporterManager.testFailed(ReporterManager.java:291) > at > org.apache.maven.surefire.report.ReporterManager.testError(ReporterManager.java:276) > at > org.apache.maven.surefire.junit.TestListenerInvocationHandler.handleAddError(TestListenerInvocationHandler.java:163) > at > org.apache.maven.surefire.junit.TestListenerInvocationHandler.invoke(TestListenerInvocationHandler.java:134) > at $Proxy0.addError(Unknown Source) > at junit.framework.TestResult.addError(TestResult.java:36) > at junit.framework.TestResult.runProtected(TestResult.java:133) > 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:160) > at org.apache.maven.surefire.Surefire.run(Surefire.java:81) > 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:182) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:743) > [INFO] > > I suppose it's a pb of java policy ? > Any idea > Thx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-127) Wrong issue-site URL on website
[ http://jira.codehaus.org/browse/SUREFIRE-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed SUREFIRE-127. - Assignee: Brett Porter Resolution: Fixed > Wrong issue-site URL on website > --- > > Key: SUREFIRE-127 > URL: http://jira.codehaus.org/browse/SUREFIRE-127 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 1.5.1 (2.1.1 plugin), 1.5.2 (2.1.2 plugin), 1.5.3 (2.1.3 > plugin), 2.0 (2.2 plugin) > Environment: N/A >Reporter: David J. M. Karlsen > Assigned To: Brett Porter > Fix For: 2.3 > > > Issue tracking (from > http://maven.apache.org/plugins/maven-surefire-plugin/issue-tracking.html) on > site defined as "http://jira.codehaus.org/browse/MPA";, should be > "http://jira.codehaus.org/browse/MSUREFIRE";. > Probably a POM inheritance error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-263) Source repository information on the web site is out of date
[ http://jira.codehaus.org/browse/SUREFIRE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed SUREFIRE-263. - Assignee: Brett Porter Resolution: Fixed > Source repository information on the web site is out of date > > > Key: SUREFIRE-263 > URL: http://jira.codehaus.org/browse/SUREFIRE-263 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Reporter: Ryan Hoegg > Assigned To: Brett Porter > Fix For: 2.3 > > > The source repository information on the web site refers to the old location > in the repository under maven/plugins, but this plugin was moved under > surefire. > http://maven.apache.org/plugins/maven-surefire-report-plugin/source-repository.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-181) allow 'test' argument to take fully qualified class names as well as the current short format, and document the current behaviour better
[ http://jira.codehaus.org/browse/SUREFIRE-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-181: -- Fix Version/s: 2.3 > allow 'test' argument to take fully qualified class names as well as the > current short format, and document the current behaviour better > > > Key: SUREFIRE-181 > URL: http://jira.codehaus.org/browse/SUREFIRE-181 > Project: Maven Surefire > Issue Type: Improvement > Components: documentation >Reporter: Brett Porter > Fix For: 2.3 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-60) systemProperties not correctly evaluated
[
http://jira.codehaus.org/browse/SUREFIRE-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-60:
-
Fix Version/s: 2.3
> systemProperties not correctly evaluated
>
>
> Key: SUREFIRE-60
> URL: http://jira.codehaus.org/browse/SUREFIRE-60
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: Maven 2.04 and 2.0.x
>Reporter: Emmanuel Hugonnet
> Fix For: 2.3
>
>
> I have a MOJO that sets a property for the project:
> project.getProperties().put(propertyName, value);
> When I reference this property in the element of my
> surfire configuration it is not correctly evaluated even if it is a String.
> But if I use a direct project property (like basedir) ${basedir}/target is
> correctly evaluated.
> In another MOJO, used as a parameter this property is correctly evaluated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (SUREFIRE-168) TestNG @BeforeMethod annotations not being processed
[ http://jira.codehaus.org/browse/SUREFIRE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-168: -- Fix Version/s: 2.3 > TestNG @BeforeMethod annotations not being processed > > > Key: SUREFIRE-168 > URL: http://jira.codehaus.org/browse/SUREFIRE-168 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.0 (2.2 plugin) >Reporter: Zach Legein > Fix For: 2.3 > > > The latest annotation from testng 5.4 do not work with surefire 2.2 > @testng.before-method --- this works > @BeforeMethod -- this doesn't work -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-265) Use lowercase html anchor names, else these links will not work
[ http://jira.codehaus.org/browse/SUREFIRE-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-265: -- Fix Version/s: 2.3 > Use lowercase html anchor names, else these links will not work > --- > > Key: SUREFIRE-265 > URL: http://jira.codehaus.org/browse/SUREFIRE-265 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Affects Versions: 2.0 Report Plugin > Environment: WinXp, Java5 >Reporter: Martin Zeltner > Fix For: 2.3 > > Attachments: > patch_maven-surefire-report-plugin_html-anchor-ids-must-be-lowercase.patch > > Original Estimate: 5 minutes > Remaining Estimate: 5 minutes > > The class *org.apache.maven.plugins.surefire.report.SurefireReportGenerator* > does generate html anchors with upper cases. With the newest version of the > XhtmlSink of doxia created uppercase anchor ids will be automatically made > lowercase. In Mozilla browsers links with upper cases in anchors and lower > cases in anchor ids will not work. The Internet Explorer doesn't care about > cases. In appended patch I've corrected this issue by lowercasing every link > anchor. > Cheers, > Martin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-176) Classes can't find their JNI on Windows inside surefire
[ http://jira.codehaus.org/browse/SUREFIRE-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-176: -- Fix Version/s: 2.3 > Classes can't find their JNI on Windows inside surefire > --- > > Key: SUREFIRE-176 > URL: http://jira.codehaus.org/browse/SUREFIRE-176 > Project: Maven Surefire > Issue Type: Bug > Components: classloading >Affects Versions: 2.0 (2.2 plugin) > Environment: WIndows XP, JDK 1.5, ia32 >Reporter: benson margulies > Fix For: 2.3 > > > When run inside of surefire, my unit tests can't find their JNI. When run > outside of surefire, all is well. I have the necessary settings arranged via > the configuration, but no joy. > The debug trace shows the right settings for classpath, java.library.path, > and PATH. Indeed, I created a shell script that just runs > junit.textui.TestRunner with the same parameters (but none of surefire) and > it works just fine. > [DEBUG] Setting system property > [java.library.path]=[c:/x/rlp53/rlp/bin_g/ia32-w32-msvc71] > [DEBUG] Setting system property [bt.rlp.root]=[c:/x/rlp53/rlp/] > [DEBUG] Setting system property > [localRepository]=[c:/x/rlp53/rnm/source/index_ws/m2] > [DEBUG] Setting system property [basedir]=[c:\x\rlp53\rnm\source\index_ws] > [DEBUG] Setting environment variable > [PATH]=[c:\x\rlp53\rlp\bin_g\ia32-w32-msvc71;c:\vs2003\Common7\IDE;c:\vs2003\VC7\BIN;c:\vs2003\Common7\Tools;c:\vs2003\Common7\Tools\bin;c:\vs2003\SDK\v1.1\bin;c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;c:\vs2003\Common7\IDE;c:\vs2003\VC7\BIN;c:\vs2003\Common7\Tools;c:\vs2003\Common7\Tools\bin;c:\vs2003\SDK\v1.1\bin;c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;C:\cygwin\usr\local\bin;C:\cygwin\bin;C:\cygwin\bin;C:\cygwin\usr\X11R6\bin;c:\jdk1.5.0_09\bin;c:\Perl\bin\;c:\Python24\;c:\WINDOWS\system32;c:\WINDOWS;c:\WINDOWS\System32\Wbem;c:\Program > Files\Common Files\Roxio Shared\DLLShared\;c:\Program Files\Microsoft SQL > Server\80\Tools\Binn\;c:\Program Files\Perforce;c:\Program > Files\cvsnt;C:\cygwin\usr\X11R6\bin;C:\cygwin\usr\X11R6\bin;C:\cygwin\lib\lapack] > I have not built an isolated test case, but I could if that would help > someone understand this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-262) Surefire report plugins fails with OutOfMemoryError, doesn't scale
[
http://jira.codehaus.org/browse/SUREFIRE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-262:
--
Fix Version/s: 2.3
> Surefire report plugins fails with OutOfMemoryError, doesn't scale
> --
>
> Key: SUREFIRE-262
> URL: http://jira.codehaus.org/browse/SUREFIRE-262
> Project: Maven Surefire
> Issue Type: Bug
> Components: report plugin
>Affects Versions: 2.0 Report Plugin
> Environment: MacOS X; java version "1.5.0_06"
>Reporter: Martin Probst
> Fix For: 2.3
>
>
> The surefire report plugin fails to create a test report with an
> OutOfMemoryError.
> I've set MAVEN_OPTS to -Xmx512m and to -Xmx1024m. With 512m the report fails
> after about 3 minutes, with 1GB it taks significantly longer. Both report
> generation tasks fail.
> {pre}
> [INFO] [surefire-report:report]
> [WARNING] Unable to locate Test Source XRef to link to - DISABLED
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] Java heap space
> [INFO]
>
> [INFO] Trace
> java.lang.OutOfMemoryError: Java heap space
> [INFO]
>
> [INFO] Total time: 2 minutes 21 seconds
> [INFO] Finished at: Sat Jan 20 12:59:13 CET 2007
> [INFO] Final Memory: 69M/1016M
> [INFO]
>
> {/pre}
> This happens regardless of the actual JUnit tests - I ran this with
> -Dmaven.test.skip=true.
> The target/surefire-reports directory contains over 700 MB of XML reports,
> mainly due to long stack traces in the mostly failing 2000+ tests. However
> the JUnit reports plugin in ANT which we used to use had no problems handling
> this kind of data.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (SUREFIRE-267) Add a window and a document title plus a document description (like made in javadoc and jxr plugin)
[ http://jira.codehaus.org/browse/SUREFIRE-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-267: -- Fix Version/s: 2.3 > Add a window and a document title plus a document description (like made in > javadoc and jxr plugin) > --- > > Key: SUREFIRE-267 > URL: http://jira.codehaus.org/browse/SUREFIRE-267 > Project: Maven Surefire > Issue Type: New Feature > Components: report plugin >Affects Versions: 2.0 Report Plugin > Environment: WinXp, Java5 >Reporter: Martin Zeltner > Fix For: 2.3 > > Attachments: > patch_maven-surefire-report-plugin_add-window-and-doc-title-plus-doc-description.patch > > Original Estimate: 10 minutes > Remaining Estimate: 10 minutes > > Add a window and a document title plus a document description (like made in > javadoc and jxr plugin). By default the windowTitle, docTitle and > docDescription are taken from the resource bundle but if one likes to use a > specific (like made in javadoc and jxr plugin) these three parameters can be > personalized. See appended patch. > Cheers, > Martin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-57) Invalid characters in XML reports
[
http://jira.codehaus.org/browse/SUREFIRE-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-57:
-
Fix Version/s: 2.3
> Invalid characters in XML reports
> -
>
> Key: SUREFIRE-57
> URL: http://jira.codehaus.org/browse/SUREFIRE-57
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 3.x support
>Reporter: Klaus Brunner
>Priority: Critical
> Fix For: 2.3
>
>
> Surefire (or possibly Xpp3Dom?) should check for invalid characters in JUnit
> output and escape or mask them to ensure valid XML reports. This applies to
> all characters outside the allowed range defined in the XML spec
> (http://www.w3.org/TR/REC-xml/#NT-Char).
> I have a JUnit test case that uses assertEquals on strings. In some
> situations, the string to compare against the reference may be completely
> garbled and contain things such as null characters, which then show up in the
> assertion failure message ("expected X but was Y") and consequently in the
> XML reports.
> Here's a simple test case to trigger the problem:
> public class InvalidCharactersTest extends TestCase {
> public void testStrings() {
> String expected = "abc";
> String actual = "abc" + '\u';
> assertEquals(expected, actual);
> }
> }
> The resulting Surefire XML report contains the null character as is and is
> therefore not valid XML. Running the Surefire Reports plugin then fails with
> a parsing error.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-178) add the equivalent of maven.junit.jvmargs in maven 1.x plugin
[ http://jira.codehaus.org/browse/SUREFIRE-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-178: -- Fix Version/s: 2.3 > add the equivalent of maven.junit.jvmargs in maven 1.x plugin > - > > Key: SUREFIRE-178 > URL: http://jira.codehaus.org/browse/SUREFIRE-178 > Project: Maven Surefire > Issue Type: New Feature >Reporter: Brett Porter > Fix For: 2.3 > > > for forking tests with VM args (eg, debugging) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-157) Surefire Plugin fails to handle exception thrown from TestNG @BeforeTest method
[
http://jira.codehaus.org/browse/SUREFIRE-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-157:
--
Fix Version/s: 2.3
> Surefire Plugin fails to handle exception thrown from TestNG @BeforeTest
> method
> ---
>
> Key: SUREFIRE-157
> URL: http://jira.codehaus.org/browse/SUREFIRE-157
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.0 (2.2 plugin), 2.3
> Environment: Windows XP, JDK 1.5, Maven 2.0.4, TestNG 5.1
>Reporter: Manish Shah
> Fix For: 2.3
>
>
> Create a TestNG test with a method as follows:
> @BeforeTest
> public void beforeTest() {
> throw new RuntimeException("Simulate an exception from a beforeTest
> method");
> }
> When surefire attempts to run this test, the plugin fails with the following
> stack trace:
> org.apache.maven.surefire.booter.SurefireExecutionException: null; nested
> exception is java.lang.NullPointerException: n
> ull
> java.lang.NullPointerException
> at
> org.apache.maven.surefire.report.AbstractTextReporter.testFailed(AbstractTextReporter.java:106)
> at
> org.apache.maven.surefire.report.ReporterManager.testFailed(ReporterManager.java:299)
> at
> org.apache.maven.surefire.report.ReporterManager.testFailed(ReporterManager.java:281)
> at
> org.apache.maven.surefire.testng.TestNGReporter.onTestFailure(TestNGReporter.java:97)
> at org.testng.internal.Invoker.runTestListeners(Invoker.java:1164)
> at org.testng.internal.Invoker.runTestListeners(Invoker.java:1149)
> at
> org.testng.internal.Invoker.handleConfigurationFailure(Invoker.java:191)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:170)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:236)
> at org.testng.SuiteRunner.run(SuiteRunner.java:145)
> at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:901)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:863)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.executeTestNG(TestNGExecutor.java:64)
> at
> org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:75)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (SUREFIRE-174) Various information is written to stdout instead of log which is not embedder-friendly
[ http://jira.codehaus.org/browse/SUREFIRE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-174: -- Fix Version/s: 2.3 > Various information is written to stdout instead of log which is not > embedder-friendly > -- > > Key: SUREFIRE-174 > URL: http://jira.codehaus.org/browse/SUREFIRE-174 > Project: Maven Surefire > Issue Type: Bug >Reporter: Stepan Roh > Fix For: 2.3 > > > The information (known to me) written to stdout in maven-surefire-plugin-2.2 > and surefire-booter-2.0 is: > - SurefireBooter writes "Forking command line..." if debug is enabled > - SurefireBooter redirects stdout and stderr of forked process to stdout > (this one is most serious, I think) > - SurefirePlugin outputs summary and/or text report to console (I know it can > be switched off and/or written to file, but I would like to have it written > to log) > It is important to have all this information written to log instead of > stdout, because information is "lost" if written to console and embedder is > used (two or more embedders may run and confuse their output) and it is also > important to be able to align such information with information already > logged. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-163) Surefire ClassLoader Breaks RIFE's ClassLoader
[ http://jira.codehaus.org/browse/SUREFIRE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-163: -- Fix Version/s: 2.3 > Surefire ClassLoader Breaks RIFE's ClassLoader > -- > > Key: SUREFIRE-163 > URL: http://jira.codehaus.org/browse/SUREFIRE-163 > Project: Maven Surefire > Issue Type: Bug > Components: classloading >Affects Versions: 2.0 (2.2 plugin) > Environment: Any operating system > RIFE 1.5.1 > Maven 2.0.4 > Java 1.5.x (1.4.x was not tested) >Reporter: Jeremy Whitlock > Fix For: 2.3 > > Attachments: rife-maven-example.tar.gz > > > Hi All, > I am developing a RIFE application with Maven. Initially, there were no > issues due to my unit tests not needing access to RIFE managed objects. Once > I wanted to start testing that the RIFE portions of my application were > functioning properly, I began running into NullPointerExceptions (NPE) when > RIFE was trying to instantiate objects. I did some verification of my > application's target directory and it appeared proper. I messed around with > the forkMode and childDelegation configurations but nothing made RIFE work > properly. This being said, I have created a sample RIFE application that I > will attach to this JIRA. There are two outcomes of this JIRA: > 1. Updated documentation in the event that this is a non-issue. > 2. This is an issue and should be fixed. > There is a README file in the attachment that will explain how to configure > the environment so that you can run my RIFE application properly, and without > error, using the jetty plugin and then how to reproduce this problem with the > surefire portion of Maven. Using the "-X" flag during the "mvn test" call > proves that the classes resulting in the NPE are in fact on the classpath. > Take care, > Jeremy -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-172) maven.test.skip.exec is ignored
[ http://jira.codehaus.org/browse/SUREFIRE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-172: -- Fix Version/s: 2.3 > maven.test.skip.exec is ignored > --- > > Key: SUREFIRE-172 > URL: http://jira.codehaus.org/browse/SUREFIRE-172 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support >Affects Versions: 2.0 (2.2 plugin) > Environment: Windows XP >Reporter: J-C Walmetz >Priority: Minor > Fix For: 2.3 > > > Option maven.test.skip.exec describes in the documentation is ignored. It > should compile the tests but not execute them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-161) Result message of Surefire TestNG run with invalid not logical.
[
http://jira.codehaus.org/browse/SUREFIRE-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-161:
--
Fix Version/s: 2.3
> Result message of Surefire TestNG run with invalid not logical.
> --
>
> Key: SUREFIRE-161
> URL: http://jira.codehaus.org/browse/SUREFIRE-161
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.0 (2.2 plugin)
> Environment: - WinXP
> - Maven 2.0.4 (with maven-surefire-plugin 2.2)
>Reporter: Davy Toch
> Fix For: 2.3
>
> Attachments: m2-testng-example-jdk15.zip
>
>
> When performing a Surefire TestNG run on Java 1.5 annotated test classes with
> pom.xml
> containing an incorrect testng suite configuration (e.g. pointing to
> inexisting file blieblie.xml),
> the run won't fail but instead will generate the following result:
> ---
> T E S T S
> ---
> There are no tests to run.
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> The problem lies in:
> plugins\maven-surefire-plugin\src\main\java\org\apache\maven\plugin\surefire\SurefirePlugin.java
> (lines around line 500)
> if ( suiteXmlFiles != null && suiteXmlFiles.length > 0 )
> {
> if ( testNgArtifact == null )
> {
> throw new MojoExecutionException( "suiteXmlFiles is
> configured, but there is no TestNG dependency" );
> }
> for ( int i = 0; i < suiteXmlFiles.length; i++ )
> {
> File file = suiteXmlFiles[i];
> if ( file.exists() )
> {
> surefireBooter.addTestSuite(
> "org.apache.maven.surefire.testng.TestNGXmlTestSuite",
> new Object[]{file,
> testSourceDirectory.getAbsolutePath()} );
> }
> }
> If file.exists() returns false, then an Exception should be thrown.
> Remark that with JDK1.4 JavaDoc annotated classes, the same problem arises,
> as well as another problem
> indicated in http://jira.codehaus.org/browse/MSUREFIRE-173 .
> An example is included to illustrate the problem (just run 'maven test').
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-175) NoClassDefFoundError for UrlUtils
[ http://jira.codehaus.org/browse/SUREFIRE-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-175: -- Fix Version/s: 2.3 > NoClassDefFoundError for UrlUtils > - > > Key: SUREFIRE-175 > URL: http://jira.codehaus.org/browse/SUREFIRE-175 > Project: Maven Surefire > Issue Type: Bug > Components: classloading > Environment: Win XP/Cygwin >Reporter: Rory Winston > Fix For: 2.3 > > > Surefire starting playing up today - I believe it may be due to some > classloader changes that were committed earlier today. The symptoms were > java.lang.NoClassDefFoundError: org/apache/maven/surefire/util/UrlUtils > at > org.apache.maven.surefire.booter.SurefireBooter.createClassLoader(SurefireBoote > r.java:599) > at > org.apache.maven.surefire.booter.SurefireBooter.getTestClassLoader(SurefireBoot > er.java:569) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBoot > er.java:250) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:807) > When trying to run tests. To fix it, I edited the tag for Surefire > in my pom.xml and changed it to 2.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-182) console output of tests should be catched in text files like in Maven 1
[ http://jira.codehaus.org/browse/SUREFIRE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-182: -- Fix Version/s: 2.3 > console output of tests should be catched in text files like in Maven 1 > --- > > Key: SUREFIRE-182 > URL: http://jira.codehaus.org/browse/SUREFIRE-182 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.0 (2.2 plugin) >Reporter: Wim Deblauwe > Fix For: 2.3 > > > we are currently converting from M1 to M2, and we see that the output of our > tests is not redirected to a file anymore. > I found several questions for this on the mailinglist[1], but no answers so > far. > [1] > http://www.nabble.com/-M2-Surefire%3A-add-Console-output-to-the-reports--tf1937138s177.html#a5307553 > http://www.nabble.com/maven-surefire-plugin-not-redirecting-test-output-tf2271529s177.html#a6305553 > http://www.nabble.com/M1-test-plugin-vs-M2-surefire-plugin-tf1712068s177.html#a4648726 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-58) Not compatible with TestNG 5.4: InstantiationException: org.testng.internal.annotations.JDK15AnnotationFinder
[ http://jira.codehaus.org/browse/SUREFIRE-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-58: - Fix Version/s: 2.3 > Not compatible with TestNG 5.4: InstantiationException: > org.testng.internal.annotations.JDK15AnnotationFinder > - > > Key: SUREFIRE-58 > URL: http://jira.codehaus.org/browse/SUREFIRE-58 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.4 > Environment: JDK 1.5.0_09 > mvn 2.0.4 > surefire-api:jar:2.0 > surefire-testng:jar:2.0 > > maven-surefire-plugin > 2.2 > > > org.testng > testng > 5.4 > jdk15 > test > >Reporter: Damian Golda >Priority: Minor > Fix For: 2.3 > > > While running test using mvn and TestNG 5.4 there surefire reports exception: > org.apache.maven.surefire.booter.SurefireExecutionException: > org.testng.internal.annotations.JDK15AnnotationFinder; nes > ed exception is java.lang.InstantiationException: > org.testng.internal.annotations.JDK15AnnotationFinder; nested excepti > n is org.apache.maven.surefire.testset.TestSetFailedException: > org.testng.internal.annotations.JDK15AnnotationFinder; n > sted exception is java.lang.InstantiationException: > org.testng.internal.annotations.JDK15AnnotationFinder > org.apache.maven.surefire.testset.TestSetFailedException: > org.testng.internal.annotations.JDK15AnnotationFinder; nested > exception is java.lang.InstantiationException: > org.testng.internal.annotations.JDK15AnnotationFinder > java.lang.InstantiationException: > org.testng.internal.annotations.JDK15AnnotationFinder > at java.lang.Class.newInstance0(Class.java:335) > at java.lang.Class.newInstance(Class.java:303) > at > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.(TestNGDirectoryTestSuite.java:86) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:494) > at > org.apache.maven.surefire.Surefire.instantiateObject(Surefire.java:216) > at > org.apache.maven.surefire.Surefire.instantiateSuite(Surefire.java:243) > at > org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:145) > at org.apache.maven.surefire.Surefire.run(Surefire.java:108) > 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) > I suppose that the reason is that in TestNG 5.4 (and 5.3) constructor for > JDK15AnnotationFinder has an argument: > public JDK15AnnotationFinder(IAnnotationTransformer transformer) > and there is no default constructor. > I found that there is only one implementation of IAnnotationTransformer - > DefaultAnnotationTransformer which fortunatly has default constructor. > So I it can be changed from > new JDK15AnnotationFinder() > to > new JDK15AnnotationFinder(new DefaultAnnotationTransformer()) > So instead of class.newInstance should be used: > Constructor c = Class.getConstructor(IAnnotationTransformer.class); > DefaultAnnotationTransformer daf = new DefaultAnnotationTransformer() > c.newInstance(daf); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-263) Source repository information on the web site is out of date
[ http://jira.codehaus.org/browse/SUREFIRE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-263: -- Fix Version/s: 2.3 > Source repository information on the web site is out of date > > > Key: SUREFIRE-263 > URL: http://jira.codehaus.org/browse/SUREFIRE-263 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Reporter: Ryan Hoegg > Fix For: 2.3 > > > The source repository information on the web site refers to the old location > in the repository under maven/plugins, but this plugin was moved under > surefire. > http://maven.apache.org/plugins/maven-surefire-report-plugin/source-repository.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-184) [PATCH] make the basedir system property optional
[ http://jira.codehaus.org/browse/SUREFIRE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-184: -- Fix Version/s: 2.3 > [PATCH] make the basedir system property optional > - > > Key: SUREFIRE-184 > URL: http://jira.codehaus.org/browse/SUREFIRE-184 > Project: Maven Surefire > Issue Type: Improvement > Environment: tested on Win2K with cygwin and JDK1.5, but this is > indifferent. >Reporter: Antoine Levy-Lambert > Fix For: 2.3 > > Attachments: patch.txt > > > I wanted to run the ant testcases using the maven-surefire-plugin (I actually > built all the ant jars using maven). > The problem is that the plugin sets a system property basedir that ant cannot > override. Since the BuildFileTest s are heavily dependent upon this property > that ant normally sets to be the directory of the build file, most tests fail > ... > Here a patch adding the possibility not to set the basedir by setting a > configuration attribute omitbasedir to true. > The pom.xml of maven-surefile-plugin was also missing a dependency to > surefire-api (or at least I needed to add this to build properly). > Regards, > Antoine -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-171) tests failed under surefire plugin 2.2 and not with older version
[ http://jira.codehaus.org/browse/SUREFIRE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-171: -- Fix Version/s: 2.3 > tests failed under surefire plugin 2.2 and not with older version > - > > Key: SUREFIRE-171 > URL: http://jira.codehaus.org/browse/SUREFIRE-171 > Project: Maven Surefire > Issue Type: Bug > Environment: Maven 2.0.4, Windows 2000 >Reporter: David vicente >Priority: Critical > Fix For: 2.3 > > Attachments: tests Cobertura-Surefire.zip > > > I have made many tests for compatibility between Cobertura plugin 2.0 and > Surefire which all failed. > But in 2.2, i have 23 errors on my tests and all succeded with older versions > of surefire plugin. > See the log in the attached zip file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-166) trimStackTrace=true trims "caused by:" sections complelely away
[ http://jira.codehaus.org/browse/SUREFIRE-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-166: -- Fix Version/s: 2.3 > trimStackTrace=true trims "caused by:" sections complelely away > --- > > Key: SUREFIRE-166 > URL: http://jira.codehaus.org/browse/SUREFIRE-166 > Project: Maven Surefire > Issue Type: Bug >Reporter: Tuomas Kiviaho >Priority: Minor > Fix For: 2.3 > > > Description of the parameter 'trimStackTrace' states "trim the stack trace in > the reports to just the lines within the test" which it does nicely on the > stacktrace, but there may be additional information in the initial cause that > doesn't fall to the category "not within the test". Without trimming these > "caused by:" lines of course show up, but so does the overly long test > framework part of the stacktrace. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-258) Report plugin adds xmlapi jar to projectArtifacts
[
http://jira.codehaus.org/browse/SUREFIRE-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-258:
--
Fix Version/s: 2.3
> Report plugin adds xmlapi jar to projectArtifacts
> -
>
> Key: SUREFIRE-258
> URL: http://jira.codehaus.org/browse/SUREFIRE-258
> Project: Maven Surefire
> Issue Type: Bug
> Components: report plugin
>Affects Versions: 2.0 Report Plugin
> Environment: Windows XP
>Reporter: Wim Deblauwe
>Priority: Blocker
> Fix For: 2.3
>
>
> The surefire-report plugin seems to add the
> "xml-apis:xml-apis=xml-apis:xml-apis:jar:1.0.b2:compile" to the
> projectArtifactMap. Running mvn -X surefire-report:report gives this:
> (f) projectArtifactMap = {abbot:abbot=abbot:abbot:jar: 1.0.0rc2:test,
> log4j:log4j=log4j:log4j:jar:1.2.8:compile, jdom:jdom=jdom:jdom:jar:1.0:test,
> commons-betwixt:commons-betwixt=commons-betwixt:commons-betwixt:jar:0.6.ba2:compile,
> commons-beanutils:commons-beanutils=commons-beanutils:commons-beanutils:jar:
> 1.6:compile, junit:junit=junit:junit:jar:3.8.1:test,
> xml-apis:xml-apis=xml-apis:xml-apis:jar:1.0.b2:compile,
> commons-logging:commons-logging=commons-logging:commons-logging:jar:1.0.4:compile,
> commons-digester:commons-digester=commons-digester:commons-digester:jar:
> 1.6:compile,
> commons-beanutils:commons-beanutils-core=commons-beanutils:commons-beanutils-core:jar:1.7.0:compile,
> commons-lang:commons-lang=commons-lang:commons-lang:jar:2.0:compile,
> commons-collections:commons-collections=commons-collections:commons-collections:jar:
> 3.1:compile}
> If I run "mvn -X surefire:report", then this dependency is not present in the
> projectArtifactMap.
> This additional dependency makes my unit tests fail. Is this a known bug? Any
> workarounds?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (SUREFIRE-256) Incoherent data between 'Package List ' and 'Test Cases' items in report
[ http://jira.codehaus.org/browse/SUREFIRE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-256: -- Fix Version/s: 2.3 > Incoherent data between 'Package List ' and 'Test Cases' items in report > > > Key: SUREFIRE-256 > URL: http://jira.codehaus.org/browse/SUREFIRE-256 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Affects Versions: 2.0 Report Plugin >Reporter: Damien Lecan > Fix For: 2.3 > > Attachments: MSUREFIREREP-26-maven-surefire-plugin.patch, > MSUREFIREREP-26-maven-surefire-plugin.patch, surefire-report.html > > > As it can be seen of the attached file, the ConfigTest has incoherent data > between items 'Package List ' and 'Test Cases' . > In 'Package List ' : > Class Tests Errors FailuresSuccess RateTime > ConfigTest3 0 0100% > 0.585 > ConfigTest has just 3 tests. > But, in 'Test Cases', there are much more than 3 tests (they are duplicated > from the other tested class ManagerTest !) > ConfigTest > testCBEM1 0.039 > testCBEM2 0.001 > testCBEM3 0.001 > testCBEM4 0.001 > testCBEM5 0 > testCBEM6 0 > testCBEM7 0 > testCBEM8 0 > testCBEM9 0 > testCBEM10 0.001 > testCBEM11 0 > testCBEM12 0.001 > testGetBooleanProperty 0.528 > testGetFloatProperty0.029 > testGetIntProperty 0.012 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-259) Calculation of relative path to xref is wrong
[ http://jira.codehaus.org/browse/SUREFIRE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-259: -- Fix Version/s: 2.3 > Calculation of relative path to xref is wrong > - > > Key: SUREFIRE-259 > URL: http://jira.codehaus.org/browse/SUREFIRE-259 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Affects Versions: 2.0 Report Plugin > Environment: WinXp, Java5 >Reporter: Martin Zeltner > Fix For: 2.3 > > Attachments: > patch_maven-surefire-report-plugin_relative-path-to-xref.patch, > patch_maven-surefire-report-plugin_relative-path-to-xref_2.patch > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > The calculation of the relative path to xref is wrong! I.e. it fails with the > current config: > > org.apache.maven.plugins > maven-surefire-report-plugin > 2.1-SNAPSHOT > > true > target/site/framework-tests/xref > target/site > > > In appended patch I've changed the following: >* Parameter outputDirectory is now a java.io.File so there is even a > chance to find out the relavtive path for the config above. >* I've replaced the code where the relative path is calculated with the > static method invocation of my new util class (tests for util class included). > Cheers, > Martin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-266) Exception if a test case is in the default package
[ http://jira.codehaus.org/browse/SUREFIRE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-266: -- Fix Version/s: 2.3 > Exception if a test case is in the default package > -- > > Key: SUREFIRE-266 > URL: http://jira.codehaus.org/browse/SUREFIRE-266 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Affects Versions: 2.0 Report Plugin > Environment: maven 2.0.4 > jdk 1.6 >Reporter: David DIDIER >Priority: Minor > Fix For: 2.3 > > > If a test case is in the default package (bad practice, yeah ^^) this > exception is printed out on the console : > java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > at java.lang.String.substring(String.java:1938) > at > org.codehaus.mojo.surefire.ReportTestSuite.startElement(ReportTestSuite.java:85) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:501) > at > com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:767) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentSc > annerImpl.java:1357) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$ContentDriver.scanRootElementHook(XMLDocumentS > cannerImpl.java:1289) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocument > FragmentScannerImpl.java:3084) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java: > 912) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:645) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScanne > rImpl.java:508) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) > at > com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:395) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:331) > at > org.codehaus.mojo.surefire.ReportTestSuite.(ReportTestSuite.java:59) > at > org.codehaus.mojo.surefire.SurefireReportParser.parseXMLReportFiles(SurefireReportParser.java:42) > at > org.codehaus.mojo.surefire.SurefireReportGenerator.doGenerateReport(SurefireReportGenerator.java:44) > at > org.codehaus.mojo.surefire.SurefireReportMojo.executeReport(SurefireReportMojo.java:77) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:67) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:115) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:124) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.refle
[jira] Updated: (SUREFIRE-170) Failed to load test: java.security.AccessControlException:
[ http://jira.codehaus.org/browse/SUREFIRE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-170: -- Fix Version/s: 2.3 > Failed to load test: java.security.AccessControlException: > -- > > Key: SUREFIRE-170 > URL: http://jira.codehaus.org/browse/SUREFIRE-170 > Project: Maven Surefire > Issue Type: Bug > Components: classloading >Affects Versions: 2.0 (2.2 plugin) > Environment: windows XP SP1 and linux AS 4 > maven 2.0.4 > jdk 1.5.0_06/09 >Reporter: Christophe Lallement > Fix For: 2.3 > > > We try to load a testsuite with a test case wich start a RMI server and we > have this error: > > mvn test > Running deai.tt.rhino.cache.mgr.CommonCacheManagerTest > INFO: Created RMIRegistry on port: 10098 > org.apache.maven.surefire.booter.SurefireExecutionException: > deai.tt.rhino.cache.mgr.CommonCacheManagerTest; nested exception is > java.security.AccessControlException: access denied > (java.lang.RuntimePermission setIO); nested exception is > org.apache.maven.surefire.testset.TestSetFailedException: > deai.tt.rhino.cache.mgr.CommonCacheManagerTest; nested exception is > java.security.AccessControlException: access denied > (java.lang.RuntimePermission setIO) > org.apache.maven.surefire.testset.TestSetFailedException: > deai.tt.rhino.cache.mgr.CommonCacheManagerTest; nested exception is > java.security.AccessControlException: access denied > (java.lang.RuntimePermission setIO) > java.security.AccessControlException: access denied > (java.lang.RuntimePermission setIO) > at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) > at > java.security.AccessController.checkPermission(AccessController.java:427) > at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) > at java.lang.System.checkIO(System.java:208) > at java.lang.System.setOut(System.java:148) > at > org.apache.maven.surefire.report.ReporterManager.resetStreams(ReporterManager.java:313) > at > org.apache.maven.surefire.report.ReporterManager.testFailed(ReporterManager.java:291) > at > org.apache.maven.surefire.report.ReporterManager.testError(ReporterManager.java:276) > at > org.apache.maven.surefire.junit.TestListenerInvocationHandler.handleAddError(TestListenerInvocationHandler.java:163) > at > org.apache.maven.surefire.junit.TestListenerInvocationHandler.invoke(TestListenerInvocationHandler.java:134) > at $Proxy0.addError(Unknown Source) > at junit.framework.TestResult.addError(TestResult.java:36) > at junit.framework.TestResult.runProtected(TestResult.java:133) > 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:160) > at org.apache.maven.surefire.Surefire.run(Surefire.java:81) > 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:182) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:743) > [INFO] > > I suppose it's a pb of java policy ? > Any idea > Thx -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-164) Classpath in XML report is wrong
[ http://jira.codehaus.org/browse/SUREFIRE-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-164: -- Fix Version/s: 2.3 > Classpath in XML report is wrong > > > Key: SUREFIRE-164 > URL: http://jira.codehaus.org/browse/SUREFIRE-164 > Project: Maven Surefire > Issue Type: Bug > Components: xml generation >Reporter: Joerg Schaible >Priority: Minor > Fix For: 2.3 > > Attachments: patch.patch > > > The XML report contains in the property java.class.path Maven's classpath, > but not the class path used to execute the tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-159) DBUnit not working from inside Maven2
[ http://jira.codehaus.org/browse/SUREFIRE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-159: -- Fix Version/s: 2.3 > DBUnit not working from inside Maven2 > - > > Key: SUREFIRE-159 > URL: http://jira.codehaus.org/browse/SUREFIRE-159 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.0 (2.2 plugin) > Environment: I'm using maven 2.0.4 with the Surefire plugin 2.2 to > test a couple of > DAOs set up with Hibernate. > At all tests i get the following exception, and I'm not able to find > the cause, which I suspect lies within DBUnit 2.1... >Reporter: Bengt-Erik Fröberg > Fix For: 2.3 > > > When running from Maven2 I get the following exception: > Tests run: 6, Failures: 0, Errors: 6, Skipped: 0, Time elapsed: 11.593 sec > <<< FAILURE! > testCreateEvent(ks.rah.avik2.dao.TestEventDao) Time elapsed: 11.437 sec <<< > ERROR! > org.dbunit.dataset.DataSetException: org.xml.sax.SAXNotSupportedException: > not supported setting property http://xml.org/sax/properties/lexical-handler > at > org.dbunit.dataset.xml.FlatXmlProducer.produce(FlatXmlProducer.java:165) > at org.dbunit.dataset.CachedDataSet.(CachedDataSet.java:71) > at org.dbunit.dataset.xml.FlatXmlDataSet.(FlatXmlDataSet.java:200) > at org.dbunit.dataset.xml.FlatXmlDataSet.(FlatXmlDataSet.java:187) > at > ks.rah.avik2.dao.DBUnitOperationWrapper.getDataSet(DBUnitOperationWrapper.java:74) > at > ks.rah.avik2.dao.DBUnitOperationWrapper.cleanInsert(DBUnitOperationWrapper.java:85) > at > ks.rah.avik2.dao.AbstractDaoTestBase.onSetUp(AbstractDaoTestBase.java:65) > at ks.rah.avik2.dao.TestEventDao.onSetUp(TestEventDao.java:38) > at > org.springframework.test.AbstractDependencyInjectionSpringContextTests.setUp(AbstractDependencyInjectionSpringContextTests.java:192) > 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(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > 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(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747) > org.xml.sax.SAXNotSupportedException: not supported setting property > http://xml.org/sax/properties/lexical-handler > at org.gjt.xpp.sax2.Driver.setProperty(Driver.java:204) > at > org.dbunit.dataset.xml.FlatDtdProducer.setLexicalHandler(FlatDtdProducer.java:87) > at > org.dbunit.dataset.xml.FlatXmlProducer.produce(FlatXmlProducer.java:138) > at org.dbunit.dataset.CachedDataSet.(CachedDataSet.java:71) > at org.dbunit.dataset.xml.FlatXmlDataSet.(FlatXmlDataSet.java:200) > at org.dbunit.dataset.xml.FlatXmlDataSet.(FlatXmlDataSet.java:187) > at > ks.rah.avik2.dao.DBUnitOperationWrapper.getDataSet(DBUnitOperationWrapper.java:74) > at > ks.rah.avik2.dao.DBUnitOperationWrapper.cleanInsert(DBUnitOperationWrapper.java:85) > at > ks.rah.avik2.dao.AbstractDaoTestBase.onSetUp(AbstractDaoTestBase.java:65) > at ks.rah.avik2.dao.TestEventDao.onSetUp(TestEventDao.java:38) > at > org.springframework.test.AbstractDependencyInjectionSpringContextTests.setUp(AbstractDependencyInjectionSpringContextTests.java:192) > 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) >
[jira] Updated: (SUREFIRE-167) Non-Abstract TestCase not executed if name starts with Abstract
[ http://jira.codehaus.org/browse/SUREFIRE-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-167: -- Fix Version/s: 2.3 > Non-Abstract TestCase not executed if name starts with Abstract > --- > > Key: SUREFIRE-167 > URL: http://jira.codehaus.org/browse/SUREFIRE-167 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Reporter: Jörg Hohwiller > Fix For: 2.3 > > > As a convention for src/main/java/foo/Bar.java I put the related test-case > under src/test/java/foo/BarTest.java > Now I discovered that for an abstract class (AbstractResourceBundle) in > main/java the according NON ABSTRACT JUnit TestCase > ((AbstractResourceBundleTest) was NOT executed. This changed as soon as I > renamed it to AAbstractResourceBundleTest. > Seems like a bug to me. > My fist guess was that the fix for SUREFIRE-18 was made so naive but this > seems to be not the case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-165) TestNG JDK1.4 JavaDoc annotated classes never run ... and now I know why.
[
http://jira.codehaus.org/browse/SUREFIRE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-165:
--
Fix Version/s: 2.3
> TestNG JDK1.4 JavaDoc annotated classes never run ... and now I know why.
> -
>
> Key: SUREFIRE-165
> URL: http://jira.codehaus.org/browse/SUREFIRE-165
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.0 (2.2 plugin)
> Environment: - WinXP
> - Maven 2.0.4 (with maven-surefire-plugin 2.2)
>Reporter: Davy Toch
> Fix For: 2.3
>
> Attachments: m2-testng-example-jdk14.zip
>
>
> After a day of trying to find out why JDK1.4 JavaDoc annotated test classes
> were never run, I finally found out why:
> In
> maven-surefire\surefire-providers\surefire-testng\src\main\java\org\apache\maven\surefire\testng\TestNGExecutor.java,
> the method testng.runSuitesLocally() is called:
> static void executeTestNG( SurefireTestSuite surefireSuite, String
> testSourceDirectory, XmlSuite suite,
>ReporterManager reporterManager )
> {
> ...
> // TODO: Doesn't find testng.xml based suites when these are un-commented
> // TestNG ~also~ looks for the currentThread context classloader
> // ClassLoader oldClassLoader =
> Thread.currentThread().getContextClassLoader();
> // Thread.currentThread().setContextClassLoader(
> suite.getClass().getClassLoader() );
> testNG.runSuitesLocally();
> //Thread.currentThread().setContextClassLoader( oldClassLoader );
> ...
> }
> However, in the TestNG 5.1 source file org\testng\TestNG.java, only the
> method run() correctly loads the JDK1.4 annotations. So the above class
> should call testng.run() and not testng.runSuitesLocally().
> org\testng\TestNG.java:
> /**
>* Run TestNG.
>*/
> public void run() {
> // lazy scan sourcedirs if needed
> if(isJdk14() || JAVADOC_ANNOTATION_TYPE.equals(m_target)) {
>
> AnnotationConfiguration.getInstance().getAnnotationFinder().addSourceDirs(m_sourceDirs);
> }
> ...
> }
> The problem is also still present in the latest 2.3-SNAPSHOT version of the
> maven-surefire-plugin.
> Included a small example project to illustrate the problem (just run "maven
> test").
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-261) Unable to generate the surefire report if the project is not a java project, but tests are written in JAVA
[ http://jira.codehaus.org/browse/SUREFIRE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-261: -- Fix Version/s: 2.3 > Unable to generate the surefire report if the project is not a java project, > but tests are written in JAVA > -- > > Key: SUREFIRE-261 > URL: http://jira.codehaus.org/browse/SUREFIRE-261 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin >Affects Versions: 2.0 Report Plugin >Reporter: Christophe DENEUX > Fix For: 2.3 > > Attachments: MSUREFIREREP-28.patch > > > I have a maven project with a POM packaging in which I run test with the > maven-surefire-plugin. All works fine, but I am not able to generate the > surefire report. > After investigations in the source code of the maven-surefire-report-plugin, > it seems to me that the implementation of the method > SurefireReportMojo.canGenerateReport is not correct. The condition is too > restrictive. It seems to me that the condition should be something like "Does > a surefire execution report exist?". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-160) Bug into xml report generation
[ http://jira.codehaus.org/browse/SUREFIRE-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-160: -- Fix Version/s: 2.3 > Bug into xml report generation > -- > > Key: SUREFIRE-160 > URL: http://jira.codehaus.org/browse/SUREFIRE-160 > Project: Maven Surefire > Issue Type: Bug > Components: xml generation > Environment: release 2.0 of maven-surfire-plugin > mvn 2.0.4 >Reporter: Christophe Lallement > Fix For: 2.3 > > Attachments: nick.zip, > TEST-deai.ft.archi.common.debug.ThreadWarningSystemTest.xml, > ThreadWarningSystem.java, ThreadWarningSystemTest.java > > > since 2-3 weeks i have wrong information into my junit test tun (mvn test for > example) > In fact, the *.txt are right, but the corresponding xml file have wrong > entry. i means additionnal testcase are present ninto the testcase section. > you can find exmple in attachement (ThreadWarningSystemTest for example). You > can see that the error number are good (because read into the attribute of > the first xml tag) but in several TestSuite, we have testcase form other > testsuite. > I don't know if this errors comes from maven dependancies update. > What i am sure is: > 1/ a little bit of source modification into my project since this error > appears. > 2/ no new maven dependancies into my project > 3/ i use only ibilio/maven2 as repository. > This errors can'be shown on other projet and other not ... > I have a workaround to solve this issue but with low performance: > I use the option "fork per test" and the reports is right. > Maybe a way to be investigate can be the temporaly file created by the > command line: > Forking command line: java -classpath > > C:\HOMEWARE\maven-2_local\org\apache\maven\surefire\surefire-api\2.0\surefire-api-2.0.jar;C:\HOMEWARE\maven-2_local\o > > rg\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar;C:\HOMEWARE\maven-2_local\org\apache\maven\surefire\surefire-booter\2.0\surefire-booter-2.0.jar > > or > > g.apache.maven.surefire.booter.SurefireBooter C:\temp\surefire40840tmp > > C:\temp\surefire40841tmp > Any Idea ? > Thx > Christophe -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-169) No tests detected when both TestNG and JUnit in classpath
[ http://jira.codehaus.org/browse/SUREFIRE-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-169: -- Fix Version/s: 2.3 > No tests detected when both TestNG and JUnit in classpath > - > > Key: SUREFIRE-169 > URL: http://jira.codehaus.org/browse/SUREFIRE-169 > Project: Maven Surefire > Issue Type: Bug > Components: classloading, JUnit 3.x support, TestNG support >Affects Versions: 2.0 (2.2 plugin) > Environment: Linux, JDK1.5 >Reporter: Jim Crossley > Fix For: 2.3 > > > I have a multi-module project where testng is declared as a dep in the parent > and a subproject declares junit as a dep. When I invoke 'mvn test' in the > subproject, surefire doesn't detect any tests to run. If I simply remove the > testng dep from the parent, the tests run fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-59) Not compatible with TestNG 5.2: java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V
[ http://jira.codehaus.org/browse/SUREFIRE-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-59: - Fix Version/s: 2.3 > Not compatible with TestNG 5.2: java.lang.NoSuchMethodError: > org.testng.xml.XmlSuite.setParallel(Z)V > - > > Key: SUREFIRE-59 > URL: http://jira.codehaus.org/browse/SUREFIRE-59 > Project: Maven Surefire > Issue Type: Improvement > Components: TestNG support > Environment: > maven-surefire-plugin > 2.2 > > > org.testng > testng > 5.2 > jdk15 > test > >Reporter: Damian Golda > Fix For: 2.3 > > > I have project with dependency to testng and surefire plugin as in > Environment. > I run tests and get exception: > org.apache.maven.surefire.booter.SurefireExecutionException: > org.testng.xml.XmlSuite.setParallel(Z)V; nested exception i > s java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V > java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V > at > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:135) > 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) > Please, correct surefire to be compatible with new testng. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-158) Web site has incorrect source repository information
[ http://jira.codehaus.org/browse/SUREFIRE-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-158: -- Fix Version/s: 2.3 > Web site has incorrect source repository information > > > Key: SUREFIRE-158 > URL: http://jira.codehaus.org/browse/SUREFIRE-158 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Ryan Hoegg >Priority: Minor > Fix For: 2.3 > > > It was frustrating to have to hunt for the plugin in subversion. I found it > here: > http://svn.apache.org/repos/asf/maven/surefire/trunk/ > It still says this on > http://maven.apache.org/plugins/maven-surefire-plugin/source-repository.html: > http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-surefire-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] Updated: (SUREFIRE-177) Groups stipulated in the pom file get ignored when using a suiteXMLFile
[
http://jira.codehaus.org/browse/SUREFIRE-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-177:
--
Fix Version/s: 2.3
> Groups stipulated in the pom file get ignored when using a suiteXMLFile
> ---
>
> Key: SUREFIRE-177
> URL: http://jira.codehaus.org/browse/SUREFIRE-177
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
> Environment: JDK 1.5
>Reporter: Muhammad Alsebaey
> Fix For: 2.3
>
>
> When using suiteXMLFile, the code that instantiates the tests is:
> surefireBooter.addTestSuite(
> "org.apache.maven.surefire.testng.TestNGXmlTestSuite",
> new Object[]{file,
> testSourceDirectory.getAbsolutePath()} );
> In contrast with when running without it, we have
> surefireBooter.addTestSuite(
> "org.apache.maven.surefire.testng.TestNGDirectoryTestSuite", new Object[]{
> testClassesDirectory, includes, excludes, groups,
> excludedGroups, Boolean.valueOf( parallel ),
> new Integer( threadCount ),
> testSourceDirectory.getAbsolutePath()} );
> I know that I can stipulate in testng.xml the groups to run, but what If I
> didnt and I did that in pom.xml, shouldn't the plugin be aware of that?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (SUREFIRE-183) enhance maven.surefire.debug property to allow a full debug string (and take the current default if none given for backwards compat)
[ http://jira.codehaus.org/browse/SUREFIRE-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-183: -- Fix Version/s: 2.3 > enhance maven.surefire.debug property to allow a full debug string (and take > the current default if none given for backwards compat) > > > Key: SUREFIRE-183 > URL: http://jira.codehaus.org/browse/SUREFIRE-183 > Project: Maven Surefire > Issue Type: Improvement > Components: documentation >Reporter: Brett Porter > Fix For: 2.3 > > > it should also be documented -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-55) Incorrect splitting of command line arguments in ForkConfiguration
[ http://jira.codehaus.org/browse/SUREFIRE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SUREFIRE-55: - Fix Version/s: 2.3 > Incorrect splitting of command line arguments in ForkConfiguration > -- > > Key: SUREFIRE-55 > URL: http://jira.codehaus.org/browse/SUREFIRE-55 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.3, 2.4 > Environment: any >Reporter: Walco van Loon > Fix For: 2.3 > > Attachments: argline.patch > > > ForkConfiguration.createCommandLine splits argLine on spaces, where it should > use org.codehaus.plexus.util.cli.Commandline.setLine to create an argLine > which splits quoted arguments containing spaces correctly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (SUREFIRE-186) Make the use of 'test' env-var more Eclipse-friendly
[
http://jira.codehaus.org/browse/SUREFIRE-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated SUREFIRE-186:
--
Fix Version/s: 2.3
> Make the use of 'test' env-var more Eclipse-friendly
>
>
> Key: SUREFIRE-186
> URL: http://jira.codehaus.org/browse/SUREFIRE-186
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.0 (2.2 plugin)
>Reporter: raif
>Priority: Minor
> Fix For: 2.3
>
> Attachments: surefire-20061116.patch.txt
>
>
> when using Maven2 in Eclipse, running one test can be made easier with the
> attached external-tool launcher:
>
> type="org.maven.ide.eclipse.Maven2LaunchConfigurationType">
>
>
>
>
> value="${project}"/>
>
>
>
> value="${workspace_loc:/xxx"/>
>
> this allows the developer to select a test, and then run the above external
> tool. Eclipse resolves this variable to the name of the selected test class;
> e.g. "TestFoo.java". the problem with the current code of the plugin is that
> the value of the 'test' env-var is blindly used with a ".java" suffix thus
> causing the ultimate regular expression used for selecting the test file
> invalid; e.g. with the example value above that expression ends up being:
> "**/TestFoo.java.java".
> the attached patch only adds the ".java" suffix if the value of the 'test'
> env-var does not end with the same.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (SUREFIRE-113) surefire-providers-2.0.pom contains strange dependencies which generate error
[
http://jira.codehaus.org/browse/SUREFIRE-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed SUREFIRE-113.
-
Assignee: Brett Porter
Resolution: Fixed
this needs to be fixed in Maven itself.
We've already changed the POM to avoid the problem
> surefire-providers-2.0.pom contains strange dependencies which generate error
> -
>
> Key: SUREFIRE-113
> URL: http://jira.codehaus.org/browse/SUREFIRE-113
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Olivier Lamy
> Assigned To: Brett Porter
> Fix For: 2.3
>
> Attachments: log.txt, poms.zip
>
>
> This pom contains :
>
> ${project.groupId}
> surefire-api
> ${project.version}
>
> This generate strange error in certain case.
> I have replaced with :
>
> org.apache.maven.surefire
> surefire-api
> 2.0
> And works fine.
> The stack trace says
> WARNING] Unable to get resource from repository central
> (http://repo1.maven.org/maven2)
> [DEBUG] Unable to download the artifact from any repository
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.maven.surefire
> -DartifactId=surefire-api \
> -Dversion=2.4.1 -Dpackaging=jar -Dfile=/path/to/file
> Path to dependency:
> 1) dummy:dummy:jar:1.0
> 2) org.apache.maven.surefire:surefire-junit:jar:2.0
> 3) org.apache.maven.surefire:surefire-api:jar:2.4.1
> org.apache.maven.surefire:surefire-api:jar:2.4.1
> from the specified remote repositories:
> rec-ap2 (http://57.200.214.247/maven2),
> central (http://repo1.maven.org/maven2),
> continuum-repo-snapshots (http://57.200.214.247/continuum-repo/),
> apache.snapshots (http://svn.apache.org/maven-snapshot-repository),
> rec-ap2-snapshots (http://57.200.214.247/snapshots)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1304) org.springframework:beandoc:0.7.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1304. --- Assignee: Carlos Sanchez Resolution: Fixed synced from https://svn.sourceforge.net/svnroot/springframework/repos/repo/org/springframework/spring-beandoc/0.7.1/ note the new artifactId > org.springframework:beandoc:0.7.1 > - > > Key: MAVENUPLOAD-1304 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1304 > Project: maven-upload-requests > Issue Type: Task >Reporter: fabrizio giustina > Assigned To: Carlos Sanchez > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MPARTIFACT-74) artifact-install fails when maven-xdoc-plugin 1.10 is installed
[ http://jira.codehaus.org/browse/MPARTIFACT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85827 ] Arnaud Heritier commented on MPARTIFACT-74: --- I'm not sure but I think that this version of the xdoc plugin works only with maven 1.1 I'll have a look at it because I don't find this information in the documentation :-( > artifact-install fails when maven-xdoc-plugin 1.10 is installed > --- > > Key: MPARTIFACT-74 > URL: http://jira.codehaus.org/browse/MPARTIFACT-74 > Project: maven-artifact-plugin > Issue Type: Bug >Affects Versions: 1.5.2 > Environment: Linux, jdk 1.5, maven 1.0.2 >Reporter: Philippe Sevestre >Priority: Minor > > After upgrading maven-xdoc-plugin from 1.9 to 1.10, jar:install goals fail > with the following message: > /home/phil/.maven/cache/maven-artifact-plugin-1.5.2/plugin.jelly:62:9: > Error getting the project as a string > Going back to maven-xdoc-plugin 1.9 solves this problem... > Not sure if this belongs to here or xdoc, but I think it worths reporting. > Running with debug messages enabled shows another nested exception > complaining about a unknown "artifactDirectory" tag somewhere. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MEAR-57) Path to application.xml doesn't resolve properly in a multi-module build
Path to application.xml doesn't resolve properly in a multi-module build
Key: MEAR-57
URL: http://jira.codehaus.org/browse/MEAR-57
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Reporter: Jason Melnick
Priority: Minor
I have three poms - BasePOM <- MultiModulePOM <- EarPOM. My application.xml is
at the the root of the project in META-INF.
BasePOM declares plugin configuration as such:
org.apache.maven.plugins
maven-ear-plugin
false
META-INF/application.xml
META-INF/MANIFEST.MF
false
META-INF/MANIFEST.MF
When EarPOM is run separately the plugin does what it is supposed to do and
finds both the application.xml and MANIFEST.MF.
As soon as I attempt to run a multi-module build using the MultiModulePOM
(which runs the EarPOM as a module) the application.xml can not be found (but
oddly enought the MANIFEST.MF can be found).
If I change the META-INF/application.xml to:
${basedir}/META-INF/application.xml
it works fine in both solo and multi-module.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-1683) type zip for packaging ?
[ http://jira.codehaus.org/browse/MNG-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85816 ] Vincent Massol commented on MNG-1683: - I agree that we need a zip packaging and plugin. The assembly mojo is a hack is you just want to generate a zip of your project. The reason is that the packaging should represent what your project is and pom is certainly not right. Also the assembly plugin attaches a secondary artifact. In some cases I want my zip to be the primary artifact and not a secondary one. > type zip for packaging ? > > > Key: MNG-1683 > URL: http://jira.codehaus.org/browse/MNG-1683 > Project: Maven 2 > Issue Type: Improvement > Environment: not significant >Reporter: Olivier Lamy > Attachments: maven-war-plugin.tar.gz, maven-zip-plugin.tar.gz, > MNG-1683.tar.gz > > > Hi, > I don't know if the artifact type zip exists (I think not after few test). > But I want to separate the html content and the webapp content (classes, > configuration files and so on). > The use case is to separate this different works (html designer and java > developpement) and production installation (one is to an http server and the > other is on an app server) in two artifacts with separate versionning. > But the zip is not recognized. > Then I would like to use it as an artifact with maven's features (snapshot, > pom, version, goals : install, deploy release and all others). > Add it to the webapp dependencies (needed only for developpment or unit > tests). > With this type of dependency the zip content could be unpacked to a directory > in the exploded webapp. (certainly need hack on the maven-war-plugin). > I have certainly the workaround to declare this as jar and using the assembly > plugin to generate a zip. > But I can't use install release deploy or something else to manage the > generated zip which is not an artifact. > Thanks for help or workaround. > - 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: (SCM-275) Need to allow setting of the project directory, not just assume the artifactId
[
http://jira.codehaus.org/browse/SCM-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85815
]
Jason Melnick commented on SCM-275:
---
I looked for an existing against SCM, but didn't find one - although there may
be one for M2 in general.
Another observation:
An inherited SCM URL assumes the svn path is inheritance based as well - for
example:
SCM info in BasePOM as:
https://{removed}/trunk/m2_refapp/BasePOM
A child of BasePOM called ProjectPOM would then have it's scm url interpreted
as:
https://{removed}/trunk/m2_refapp/BasePOM/ProjectPOM
And likewise a child of ProjectPOM called ArtifactPOM would have an interpreted
url as such:
https://{removed}/trunk/m2_refapp/BasePOM/ProjectPOM/ArtifactPOM
I'm thinking that these issues could be resolved by adding the following
configuration options:
String defaultLocation - The location, relative to the scm base url, of this
project.
boolean autoResolve - If true it would locate the svn project based on the way
it currently works (but taking into account the new defaultLocation config
option. If false it would just use the base scm url and append either the
artifactId (by default) or the provided defaultLocation option.
I'm sure that it's not that simple under the covers, but I do think that this
would provide the flexibility that is necessary.
> Need to allow setting of the project directory, not just assume the artifactId
> --
>
> Key: SCM-275
> URL: http://jira.codehaus.org/browse/SCM-275
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-api
>Reporter: Jason Melnick
>
> The SCM plugin needs to provide a configuration option to set the project's
> name in the repository and not just assume the artifactId is that directory.
> For instance, my artifactId is dukesbankear. However, in SVN it is stored as
> DukesBankEAR. SCM fails when trying to attain any goal because it is looking
> for .../projectpath/dukesbankear instead of .../projectpath/DukesBankEAR...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-275) Need to allow setting of the project directory, not just assume the artifactId
[ http://jira.codehaus.org/browse/SCM-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85811 ] Dan Tran commented on SCM-275: -- This is an issue already already filed against maven, dont know where it is thou. What I proposed is a workaround solution. I will keep this issue open until i find the original one. > Need to allow setting of the project directory, not just assume the artifactId > -- > > Key: SCM-275 > URL: http://jira.codehaus.org/browse/SCM-275 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Reporter: Jason Melnick > > The SCM plugin needs to provide a configuration option to set the project's > name in the repository and not just assume the artifactId is that directory. > For instance, my artifactId is dukesbankear. However, in SVN it is stored as > DukesBankEAR. SCM fails when trying to attain any goal because it is looking > for .../projectpath/dukesbankear instead of .../projectpath/DukesBankEAR... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-230) mercurial plugin
[ http://jira.codehaus.org/browse/SCM-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85810 ] Ryan Daum commented on SCM-230: --- I've attached a patch to dependent issue SCM-244 which fixes the one remaining test that was failing maven-scm-provider-hg > mercurial plugin > > > Key: SCM-230 > URL: http://jira.codehaus.org/browse/SCM-230 > Project: Maven SCM > Issue Type: New Feature >Reporter: solo turn > Assigned To: Joakim Erdfelt > Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, > maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, > maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg.diff.gz, > maven-scm-provider-hg.tar.gz, maven-scm-provider-hg.tgz > > > it would be nice to have a mercurial source provider. and if not, it would be > nice to update the documentation on http://maven.apache.org/scm/ so that > anybody could just copy the bzr provider and make a mercurial provider out of > it. it should be nearly the same implementation. > mercurial is (currently) much faster than bzr and therefor really useable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-244) In maven-scm-test, ChangeLogCommandTckTest relies on unreliable timing and fails for some SCM systems
[ http://jira.codehaus.org/browse/SCM-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Daum updated SCM-244: -- Attachment: maven-scm-test-TickPatch.patch Here is a patch which adds a two second delay between changelog comparisons, for the case of faster SCMs. > In maven-scm-test, ChangeLogCommandTckTest relies on unreliable timing and > fails for some SCM systems > - > > Key: SCM-244 > URL: http://jira.codehaus.org/browse/SCM-244 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-api > Environment: Linux 2.6, JDK 1.5, Maven 2 >Reporter: Ryan Daum > Attachments: maven-scm-test-TickPatch.patch > > > I encountered this problem while fixing a new Mercurial SCM provider so that > all its unit tests pass. > A Mercurial repository which can reproduce the bug can be found at > http://darksleep.com/~ryan/maven-scm-provider-hg.cgi -- use the mercurial > client to clone this repository. The problem manifests itself in > HgChangeLogCommandTckTest. > ChangeLogCommandTckTestchecks in two revisions in sequence, and records the > time between them. It then tries, using date/time filtering to retrieve only > the later one. > This may work fine for slower network based revision control systems where > there is an appreciable pause between checkins, but for Mercurial, the > creation of the file and its checkin often happens within the same second and > so the log reports the same time for creation of both revisions. > Therefore during the date-time range query, nothing fits _between_ the date > filter range. > In _some_ cases, if the checkin happens of the second file happens to occur > after the second value of the date increments, the test passes, but this is > the exception to the rule. > The fix would be to modify ChangeLogCommandTckTest to perform a sleep of at > least 1 second between checkins. > To reproduce, checkout (as mentioned above) the Mercurial SCM provider and > run the unit tests. You will see HgChangeLogCommandTckTest fail in the > manner described above. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-275) Need to allow setting of the project directory, not just assume the artifactId
[ http://jira.codehaus.org/browse/SCM-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85808 ] Jason Melnick commented on SCM-275: --- That's the problem - the scm information isn't contained within the child project, and I don't want it to be. The scm information is only contained within the parent POM and is inherited by the child pom. The child pom takes the scm definitions from the parent and appends its artifactId to the end of the url. The child pom that was referenced above was actually output using help:effective-pom. > Need to allow setting of the project directory, not just assume the artifactId > -- > > Key: SCM-275 > URL: http://jira.codehaus.org/browse/SCM-275 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Reporter: Jason Melnick > > The SCM plugin needs to provide a configuration option to set the project's > name in the repository and not just assume the artifactId is that directory. > For instance, my artifactId is dukesbankear. However, in SVN it is stored as > DukesBankEAR. SCM fails when trying to attain any goal because it is looking > for .../projectpath/dukesbankear instead of .../projectpath/DukesBankEAR... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-230) mercurial plugin
[ http://jira.codehaus.org/browse/SCM-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85807 ] Emmanuel Venisse commented on SCM-230: -- it is in maven sandbox : http://svn.apache.org/repos/asf/maven/sandbox/scm/maven-scm-provider-hg/ I'll look at it if we can move it in maven-scm trunk > mercurial plugin > > > Key: SCM-230 > URL: http://jira.codehaus.org/browse/SCM-230 > Project: Maven SCM > Issue Type: New Feature >Reporter: solo turn > Assigned To: Joakim Erdfelt > Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, > maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, > maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg.diff.gz, > maven-scm-provider-hg.tar.gz, maven-scm-provider-hg.tgz > > > it would be nice to have a mercurial source provider. and if not, it would be > nice to update the documentation on http://maven.apache.org/scm/ so that > anybody could just copy the bzr provider and make a mercurial provider out of > it. it should be nearly the same implementation. > mercurial is (currently) much faster than bzr and therefor really useable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-230) mercurial plugin
[ http://jira.codehaus.org/browse/SCM-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85805 ] Ryan Daum commented on SCM-230: --- What happened to the above SVN repository? Where can I find the latest hg scm provider sources? Is there any chance that this will ever make it into the main Maven 2 build? > mercurial plugin > > > Key: SCM-230 > URL: http://jira.codehaus.org/browse/SCM-230 > Project: Maven SCM > Issue Type: New Feature >Reporter: solo turn > Assigned To: Joakim Erdfelt > Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, > maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, > maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg.diff.gz, > maven-scm-provider-hg.tar.gz, maven-scm-provider-hg.tgz > > > it would be nice to have a mercurial source provider. and if not, it would be > nice to update the documentation on http://maven.apache.org/scm/ so that > anybody could just copy the bzr provider and make a mercurial provider out of > it. it should be nearly the same implementation. > mercurial is (currently) much faster than bzr and therefor really useable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-275) Need to allow setting of the project directory, not just assume the artifactId
[ http://jira.codehaus.org/browse/SCM-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85804 ] Dan Tran commented on SCM-275: -- in your connection, change dukesbankear to DukesBankEAR, this way maven can locate your source correctly > Need to allow setting of the project directory, not just assume the artifactId > -- > > Key: SCM-275 > URL: http://jira.codehaus.org/browse/SCM-275 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Reporter: Jason Melnick > > The SCM plugin needs to provide a configuration option to set the project's > name in the repository and not just assume the artifactId is that directory. > For instance, my artifactId is dukesbankear. However, in SVN it is stored as > DukesBankEAR. SCM fails when trying to attain any goal because it is looking > for .../projectpath/dukesbankear instead of .../projectpath/DukesBankEAR... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-275) Need to allow setting of the project directory, not just assume the artifactId
[
http://jira.codehaus.org/browse/SCM-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85802
]
Jason Melnick commented on SCM-275:
---
They're all set... here's an example:
ParentPOM
scm:svn:https://{removed}/m2_refapp
scm:svn:https://{removed}/m2_refapp
https://{removed}/m2_refapp/
This resolves exactly like it should... However, the child that inherits from
it resolves like so (these are excerpts):
dukesbankear
scm:svn:https://{removed}/m2_refapp/dukesbankear
scm:svn:https://{removed}/m2_refapp/dukesbankear
https://{removed}/m2_refapp/dukesbankear
It automatically appends the artifactId to each of the URL's in the scm
section- regardless of whether you want it to or not.
> Need to allow setting of the project directory, not just assume the artifactId
> --
>
> Key: SCM-275
> URL: http://jira.codehaus.org/browse/SCM-275
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-api
>Reporter: Jason Melnick
>
> The SCM plugin needs to provide a configuration option to set the project's
> name in the repository and not just assume the artifactId is that directory.
> For instance, my artifactId is dukesbankear. However, in SVN it is stored as
> DukesBankEAR. SCM fails when trying to attain any goal because it is looking
> for .../projectpath/dukesbankear instead of .../projectpath/DukesBankEAR...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-275) Need to allow setting of the project directory, not just assume the artifactId
[ http://jira.codehaus.org/browse/SCM-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85792 ] Dan Tran commented on SCM-275: -- You need to set the connection and developerConnection as well. > Need to allow setting of the project directory, not just assume the artifactId > -- > > Key: SCM-275 > URL: http://jira.codehaus.org/browse/SCM-275 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Reporter: Jason Melnick > > The SCM plugin needs to provide a configuration option to set the project's > name in the repository and not just assume the artifactId is that directory. > For instance, my artifactId is dukesbankear. However, in SVN it is stored as > DukesBankEAR. SCM fails when trying to attain any goal because it is looking > for .../projectpath/dukesbankear instead of .../projectpath/DukesBankEAR... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-219) Allow file contents to be obtained from url
[ http://jira.codehaus.org/browse/MECLIPSE-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated MECLIPSE-219: - Attachment: eclipse-219-b.patch New patch (eclipse-219-b.patch) to fix a minor typo in the first patch. > Allow file contents to be obtained from url > --- > > Key: MECLIPSE-219 > URL: http://jira.codehaus.org/browse/MECLIPSE-219 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Mike Youngstrom > Fix For: 2.4 > > Attachments: eclipse-219-b.patch, eclipse-219.patch > > > Something like: > > .springBeans http://someurl"/> > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-219) Allow file contents to be obtained from url
[ http://jira.codehaus.org/browse/MECLIPSE-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated MECLIPSE-219: - Attachment: eclipse-219.patch This patch should solve this issue. It adds a and elements to (use instead of ) to specify a location. Examples: .checkstyle /cxf-eclipse-checkstyle Will grab the /cxf-eclipse-checkstyle file from the plugin dependencies (like the checkstyle plugin uses to grab the checkstyle configs). .checkstyle http://some.place.org/path/to/file will grab it based on the URL. > Allow file contents to be obtained from url > --- > > Key: MECLIPSE-219 > URL: http://jira.codehaus.org/browse/MECLIPSE-219 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Mike Youngstrom > Fix For: 2.4 > > Attachments: eclipse-219.patch > > > Something like: > > .springBeans http://someurl"/> > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-994) New indexes created during continuum startup when using postgresql
[ http://jira.codehaus.org/browse/CONTINUUM-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85784 ] Andy Jefferson commented on CONTINUUM-994: -- Was fixed in JPOX 1.1.6 > New indexes created during continuum startup when using postgresql > -- > > Key: CONTINUUM-994 > URL: http://jira.codehaus.org/browse/CONTINUUM-994 > Project: Continuum > Issue Type: Bug > Components: Database >Affects Versions: 1.0.3 >Reporter: Richard C. L. Li > Fix For: 1.1 > > > I used postgresql 8.1.4 with continuum and everytime when continuum startup, > it creates a set of indexes. I configured to restart continuum once a day > and after 2 months it generated tens of indexes in every table. > I guessed this maybe the problem of the the UPPER CASE of the table and > column names, this may make the detection of indexes fails and the JDO > recreate everytime it startup. > Workaround: after starting continuum for the first time and set the property > org.jpox.autoCreateSchema to false so that indexes will not recreated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MDEP-43) includeClassifiers configuration parameter
[
http://jira.codehaus.org/browse/MDEP-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85783
]
Stephane Nicoll commented on MDEP-43:
-
Does not seem to work
I have a project with 3 deps on modules and its sources (6 dependencies in
total). I configure the plugin to only include the "sources" classifier and it
expands the 6 dependencies
{noformat}
[INFO] [dependency:unpack-dependencies {execution: unpack-dependencies}]
[DEBUG] Excluding Transitive Dependencies.
[DEBUG] Added: com.foo.shared:foo-b:jar:sources:5.5.0-SNAPSHOT:compile
[DEBUG] Added: com.foo.shared:foo-a:jar:sources:5.5.0-SNAPSHOT:compile
[DEBUG] Added: com.foo.shared:foo-c:jar:sources:5.5.0-SNAPSHOT:compile
[DEBUG] Added: com.foo.shared:foo-c:jar:5.5.0-SNAPSHOT:compile
[DEBUG] Added: com.foo.shared:foo-a:jar:5.5.0-SNAPSHOT:compile
[DEBUG] Added: com.foo.shared:foo-b:jar:5.5.0-SNAPSHOT:compile
[DEBUG] Added 6
[DEBUG] Including only Classifiers: sources
{noformat}
The config is as follow:
{noformat}
org.apache.maven.plugins
maven-dependency-plugin
unpack-dependencies
generate-resources
unpack-dependencies
sources
true
${project.build.directory}/javadoc-src
{noformat}
> includeClassifiers configuration parameter
> --
>
> Key: MDEP-43
> URL: http://jira.codehaus.org/browse/MDEP-43
> Project: Maven 2.x Dependency Plugin
> Issue Type: New Feature
>Affects Versions: 2.0-alpha-1
>Reporter: Richard van der Hoff
>Priority: Minor
> Fix For: 2.0-alpha-1
>
> Attachments: patch
>
>
> Would it be possible to add an "includeClassifiers" parameter to
> AbstractDependencyFilterMojo?
> The attached patch implements this; I've factored the code which would be
> common to the TypeFilter and ClassifierFilter into a common base class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-1320) Javassist 3.1 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85782 ] Hugo Palma commented on MAVENUPLOAD-1320: - There are also other versions in group javassist. Should the jboss group be used now ? > Javassist 3.1 upload request > > > Key: MAVENUPLOAD-1320 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1320 > Project: maven-upload-requests > Issue Type: Task >Reporter: Hugo Palma > > Simple Java bytecode manipulation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1304) org.springframework:beandoc:0.7.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85781 ] Ben Hale commented on MAVENUPLOAD-1304: --- Beandoc 0.7.1 has been uploaded to the spring repo and will be synced with the main maven repo shortly. > org.springframework:beandoc:0.7.1 > - > > Key: MAVENUPLOAD-1304 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1304 > Project: maven-upload-requests > Issue Type: Task >Reporter: fabrizio giustina > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-275) Need to allow setting of the project directory, not just assume the artifactId
[ http://jira.codehaus.org/browse/SCM-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85780 ] Jason Melnick commented on SCM-275: --- lol - wrong element on my part :) The element (of the scm) does in fact work properly when the scm information is declared within that project. However, when declaring the scm info in a parent pom it takes the url specified in the parent and appends the artifactId of the child onto the end (when used on the child project). I'd like to have the ability to set the scm information in a parent and then configure it separately in a child pom if at all possible.. I apologize for setting this as a major issue as it's not... However, for ease of use I think it would be beneficial. > Need to allow setting of the project directory, not just assume the artifactId > -- > > Key: SCM-275 > URL: http://jira.codehaus.org/browse/SCM-275 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Reporter: Jason Melnick > > The SCM plugin needs to provide a configuration option to set the project's > name in the repository and not just assume the artifactId is that directory. > For instance, my artifactId is dukesbankear. However, in SVN it is stored as > DukesBankEAR. SCM fails when trying to attain any goal because it is looking > for .../projectpath/dukesbankear instead of .../projectpath/DukesBankEAR... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MEAR-56) DefaultLibBundleDir property and ejb client type artifact
[ http://jira.codehaus.org/browse/MEAR-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85779 ] Stephane Nicoll commented on MEAR-56: - sure :) > DefaultLibBundleDir property and ejb client type artifact > - > > Key: MEAR-56 > URL: http://jira.codehaus.org/browse/MEAR-56 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Petri Hakala > Assigned To: Stephane Nicoll >Priority: Minor > > When plugin copies ejb-client type artifact to ear it doesn't care about > defaultLibBundleDir property. If you take a look to sourcecode of class > EarModuleFactory you can see following line "return new EjbClientModule( > artifact, null );" Instead of null I think it should take defaultLibBundleDir > as parameter. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MEAR-56) DefaultLibBundleDir property and ejb client type artifact
[ http://jira.codehaus.org/browse/MEAR-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85777 ] Petri Hakala commented on MEAR-56: -- I ment I can use ejbClientModule and property bundleDir instead... > DefaultLibBundleDir property and ejb client type artifact > - > > Key: MEAR-56 > URL: http://jira.codehaus.org/browse/MEAR-56 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Petri Hakala > Assigned To: Stephane Nicoll >Priority: Minor > > When plugin copies ejb-client type artifact to ear it doesn't care about > defaultLibBundleDir property. If you take a look to sourcecode of class > EarModuleFactory you can see following line "return new EjbClientModule( > artifact, null );" Instead of null I think it should take defaultLibBundleDir > as parameter. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-275) Need to allow setting of the project directory, not just assume the artifactId
[ http://jira.codehaus.org/browse/SCM-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85775 ] Dan Tran commented on SCM-275: -- use the element. -D > Need to allow setting of the project directory, not just assume the artifactId > -- > > Key: SCM-275 > URL: http://jira.codehaus.org/browse/SCM-275 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Reporter: Jason Melnick > > The SCM plugin needs to provide a configuration option to set the project's > name in the repository and not just assume the artifactId is that directory. > For instance, my artifactId is dukesbankear. However, in SVN it is stored as > DukesBankEAR. SCM fails when trying to attain any goal because it is looking > for .../projectpath/dukesbankear instead of .../projectpath/DukesBankEAR... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MPARTIFACT-74) artifact-install fails when maven-xdoc-plugin 1.10 is installed
artifact-install fails when maven-xdoc-plugin 1.10 is installed --- Key: MPARTIFACT-74 URL: http://jira.codehaus.org/browse/MPARTIFACT-74 Project: maven-artifact-plugin Issue Type: Bug Affects Versions: 1.5.2 Environment: Linux, jdk 1.5, maven 1.0.2 Reporter: Philippe Sevestre Priority: Minor After upgrading maven-xdoc-plugin from 1.9 to 1.10, jar:install goals fail with the following message: /home/phil/.maven/cache/maven-artifact-plugin-1.5.2/plugin.jelly:62:9: Error getting the project as a string Going back to maven-xdoc-plugin 1.9 solves this problem... Not sure if this belongs to here or xdoc, but I think it worths reporting. Running with debug messages enabled shows another nested exception complaining about a unknown "artifactDirectory" tag somewhere. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1340) Upload hibernate-tools 3.2.0-beta9a
Upload hibernate-tools 3.2.0-beta9a --- Key: MAVENUPLOAD-1340 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1340 Project: maven-upload-requests Issue Type: Task Reporter: Johann Reyes http://hiberforum.org/hibernate-tools-3.2.0.beta9a-bundle.jar http://hiberforum.org/jtidy-r8-20060801-bundle.jar http://tools.hibernate.org Please upload new version of hibernate-tools + updated dependency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-275) Need to allow setting of the project directory, not just assume the artifactId
[ http://jira.codehaus.org/browse/SCM-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85774 ] Jason Melnick commented on SCM-275: --- I'm not sure I understand what you mean. Are you talking about the element? If so this will affect how the site is deployed and has a high probability of being different than the scm directory. > Need to allow setting of the project directory, not just assume the artifactId > -- > > Key: SCM-275 > URL: http://jira.codehaus.org/browse/SCM-275 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Reporter: Jason Melnick > > The SCM plugin needs to provide a configuration option to set the project's > name in the repository and not just assume the artifactId is that directory. > For instance, my artifactId is dukesbankear. However, in SVN it is stored as > DukesBankEAR. SCM fails when trying to attain any goal because it is looking > for .../projectpath/dukesbankear instead of .../projectpath/DukesBankEAR... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MEAR-56) DefaultLibBundleDir property and ejb client type artifact
[ http://jira.codehaus.org/browse/MEAR-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85773 ] Stephane Nicoll commented on MEAR-56: - Well, yes/no. An ejb client is not a library. Hence you cannot use this functionality. > DefaultLibBundleDir property and ejb client type artifact > - > > Key: MEAR-56 > URL: http://jira.codehaus.org/browse/MEAR-56 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Petri Hakala > Assigned To: Stephane Nicoll >Priority: Minor > > When plugin copies ejb-client type artifact to ear it doesn't care about > defaultLibBundleDir property. If you take a look to sourcecode of class > EarModuleFactory you can see following line "return new EjbClientModule( > artifact, null );" Instead of null I think it should take defaultLibBundleDir > as parameter. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (DOXIA-84) Update of Maven Generated Sites to use 'Built by Maven' logo
[ http://jira.codehaus.org/browse/DOXIA-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85766 ] Vincent Siveton commented on DOXIA-84: -- It seems that no guideline for the ASF feather exists. We could contact Apache Public Relations Committee at [EMAIL PROTECTED] FYI, Jukka Zitting, from Jackrabbit project, has already this key question http://jukkaz.wordpress.com/2006/08/05/asf-logo-guidelines I will ask on the dev list to hear the others. > Update of Maven Generated Sites to use 'Built by Maven' logo > > > Key: DOXIA-84 > URL: http://jira.codehaus.org/browse/DOXIA-84 > Project: doxia > Issue Type: Task >Reporter: Natalie Burdick > Assigned To: Vincent Siveton > Attachments: Built_by_Maven-90by30-Reverse.png, > Built_by_Maven-90by30.png, maven-feather.png, mavenlogo_builtby_b.gif, > mavenlogo_builtby_w.gif > > > Attached are some sample images, they would need to be resized to 90 by 30 > pixels to work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MEAR-56) DefaultLibBundleDir property and ejb client type artifact
[ http://jira.codehaus.org/browse/MEAR-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85765 ] Petri Hakala commented on MEAR-56: -- Ok, so i have to use ejbClientModule then. I didn't notice that there was one. > DefaultLibBundleDir property and ejb client type artifact > - > > Key: MEAR-56 > URL: http://jira.codehaus.org/browse/MEAR-56 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Petri Hakala > Assigned To: Stephane Nicoll >Priority: Minor > > When plugin copies ejb-client type artifact to ear it doesn't care about > defaultLibBundleDir property. If you take a look to sourcecode of class > EarModuleFactory you can see following line "return new EjbClientModule( > artifact, null );" Instead of null I think it should take defaultLibBundleDir > as parameter. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MEAR-56) DefaultLibBundleDir property and ejb client type artifact
[ http://jira.codehaus.org/browse/MEAR-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MEAR-56. --- Assignee: Stephane Nicoll Resolution: Won't Fix Fix Version/s: (was: 2.4) defalutLibBundleDir is for library and ejb-client is not a library right? > DefaultLibBundleDir property and ejb client type artifact > - > > Key: MEAR-56 > URL: http://jira.codehaus.org/browse/MEAR-56 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Petri Hakala > Assigned To: Stephane Nicoll >Priority: Minor > > When plugin copies ejb-client type artifact to ear it doesn't care about > defaultLibBundleDir property. If you take a look to sourcecode of class > EarModuleFactory you can see following line "return new EjbClientModule( > artifact, null );" Instead of null I think it should take defaultLibBundleDir > as parameter. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MDEPLOY-49) Gaol to copy artifact from one repo to another. deploy:deploy-from-other-repo
Gaol to copy artifact from one repo to another. deploy:deploy-from-other-repo - Key: MDEPLOY-49 URL: http://jira.codehaus.org/browse/MDEPLOY-49 Project: Maven 2.x Deploy Plugin Issue Type: New Feature Reporter: Geoffrey De Smet Priority: Minor The deploy plugin supports deploying from a local file with deploy:deploy-file, but it would be easier if it also supports fetching that file from another remote repo. Now we're using inhouse scripts to do this (which have problems). Archiva will support proxying the remote repo, but some orginazations don't want to automate adding artifacts to their release repo (only to their snapshot repo). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MDEPLOY-48) deploy:deploy-file does not support deploying sources jars too
[ http://jira.codehaus.org/browse/MDEPLOY-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85762 ] Geoffrey De Smet commented on MDEPLOY-48: - the workaround of scp'ing the sources jar manually isn't that good because it misses out on sha and md5's. > deploy:deploy-file does not support deploying sources jars too > -- > > Key: MDEPLOY-48 > URL: http://jira.codehaus.org/browse/MDEPLOY-48 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Geoffrey De Smet > > deploy:deploy does, but deploy:deploy-file doesn't have a parameter to tell > him where the sources jar is: > mvn deploy:deploy-file -Dfile=$artifactFile -DpomFile=$pomFile -Durl=$toRepo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MDEPLOY-48) deploy:deploy-file does not support deploying sources jars too
deploy:deploy-file does not support deploying sources jars too -- Key: MDEPLOY-48 URL: http://jira.codehaus.org/browse/MDEPLOY-48 Project: Maven 2.x Deploy Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Geoffrey De Smet deploy:deploy does, but deploy:deploy-file doesn't have a parameter to tell him where the sources jar is: mvn deploy:deploy-file -Dfile=$artifactFile -DpomFile=$pomFile -Durl=$toRepo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MEAR-56) DefaultLibBundleDir property and ejb client type artifact
DefaultLibBundleDir property and ejb client type artifact - Key: MEAR-56 URL: http://jira.codehaus.org/browse/MEAR-56 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Petri Hakala Priority: Minor Fix For: 2.4 When plugin copies ejb-client type artifact to ear it doesn't care about defaultLibBundleDir property. If you take a look to sourcecode of class EarModuleFactory you can see following line "return new EjbClientModule( artifact, null );" Instead of null I think it should take defaultLibBundleDir as parameter. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1141) Add buttons to add Ant/Shell projects in projectGroupSummary
[ http://jira.codehaus.org/browse/CONTINUUM-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85748 ] Edwin Punzalan commented on CONTINUUM-1141: --- Hi, I did think about having another action to receive the *add new project* request, but that would result to a new Action class, a new entry in xwork.xml and would result to more server loads as opposed to having the client do some work. wdyt ? > Add buttons to add Ant/Shell projects in projectGroupSummary > > > Key: CONTINUUM-1141 > URL: http://jira.codehaus.org/browse/CONTINUUM-1141 > Project: Continuum > Issue Type: Improvement > Components: Web - UI >Affects Versions: 1.1 >Reporter: Edwin Punzalan > Assigned To: Edwin Punzalan > Fix For: 1.1 > > Attachments: projectGroupSummary.GIF > > > Currently only allows add m1 and m2 projects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-1141) Add buttons to add Ant/Shell projects in projectGroupSummary
[ http://jira.codehaus.org/browse/CONTINUUM-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85746 ] Emmanuel Venisse commented on CONTINUUM-1141: - Great idea to put it in group actions. Personally, I'd prefer to not use javascript for the form submission. Click on the dropdown to choose the project type to add, then click on a 'Add project' button. > Add buttons to add Ant/Shell projects in projectGroupSummary > > > Key: CONTINUUM-1141 > URL: http://jira.codehaus.org/browse/CONTINUUM-1141 > Project: Continuum > Issue Type: Improvement > Components: Web - UI >Affects Versions: 1.1 >Reporter: Edwin Punzalan > Assigned To: Edwin Punzalan > Fix For: 1.1 > > Attachments: projectGroupSummary.GIF > > > Currently only allows add m1 and m2 projects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
