[jira] Moved: (SCM-353) maven-scm-plugin configuration is ignored if executions present
[ http://jira.codehaus.org/browse/SCM-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl moved MPSCM-98 to SCM-353: Complexity: Intermediate Workflow: Maven New (was: jira) Key: SCM-353 (was: MPSCM-98) Project: Maven SCM (was: Maven 1.x SCM Plugin) > maven-scm-plugin configuration is ignored if executions present > --- > > Key: SCM-353 > URL: http://jira.codehaus.org/browse/SCM-353 > Project: Maven SCM > Issue Type: Bug > Components: maven-plugin > Environment: Maven version: 2.0.7 > Java version: 1.6.0_01 >Reporter: jason harrop >Priority: Minor > > If I don't use the element, the embedded configuration is used. > > org.apache.maven.plugins > maven-scm-plugin > 1.0 > > > > scm:svn:http://dev.plutext.org/svn/docx4j/trunk/docx4j > > docx4j > validate > > > However, I would like to checkout 2 modules from each of 2 different > repositories. > If I introduce , the plugin doesn't read the embedded > configuration. Instead, it falls back to what is defined in the > element (or if none exists, the super pom). > Here is what I have trying: > > org.apache.maven.plugins > maven-scm-plugin > 1.0 > > > > > > checkout-docx4j > > > > scm:svn:http://dev.plutext.org/svn/docx4j/trunk/docx4j > > > docx4j > > > validate > > > > checkout-jackrabbit-webapp > > > > scm:svn:http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-webapp > > > jackrabbit-webapp > > > > validate > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-353) maven-scm-plugin configuration is ignored if executions present
[ http://jira.codehaus.org/browse/SCM-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated SCM-353: -- Component/s: maven-plugin > maven-scm-plugin configuration is ignored if executions present > --- > > Key: SCM-353 > URL: http://jira.codehaus.org/browse/SCM-353 > Project: Maven SCM > Issue Type: Bug > Components: maven-plugin > Environment: Maven version: 2.0.7 > Java version: 1.6.0_01 >Reporter: jason harrop >Priority: Minor > > If I don't use the element, the embedded configuration is used. > > org.apache.maven.plugins > maven-scm-plugin > 1.0 > > > > scm:svn:http://dev.plutext.org/svn/docx4j/trunk/docx4j > > docx4j > validate > > > However, I would like to checkout 2 modules from each of 2 different > repositories. > If I introduce , the plugin doesn't read the embedded > configuration. Instead, it falls back to what is defined in the > element (or if none exists, the super pom). > Here is what I have trying: > > org.apache.maven.plugins > maven-scm-plugin > 1.0 > > > > > > checkout-docx4j > > > > scm:svn:http://dev.plutext.org/svn/docx4j/trunk/docx4j > > > docx4j > > > validate > > > > checkout-jackrabbit-webapp > > > > scm:svn:http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-webapp > > > jackrabbit-webapp > > > > validate > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-344) connecting existing workspace artifact-projects
[ http://jira.codehaus.org/browse/MECLIPSE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114636 ] Richard van Nieuwenhoven commented on MECLIPSE-344: --- a good question! the problem is that the eclipse.workspace variable is used for something different. And i didn't want to break the old behavior! Could you check if it it is still needed? maybe even deprecate it? > connecting existing workspace artifact-projects > --- > > Key: MECLIPSE-344 > URL: http://jira.codehaus.org/browse/MECLIPSE-344 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: dependency resolution >Reporter: Richard van Nieuwenhoven > Attachments: workspace-new-files.tgz, workspace.patch, > workspace_with_limit.patch > > > This patch enables you to specify your workspace, and all dependent artefacts > that are available in your eclipse-workspace will be attached as project > references even if they are not in the reactor. > the property can be set with -DworkspaceToConnect=. > I did not have the time to create Test cases but, i maybe someone can help > with that! > The patch is based on the MECLIPSE-333 branch. > as usual the new files are in the extra tgz. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-137) provide option to list all of the test cases which failed when running a build
[ http://jira.codehaus.org/browse/SUREFIRE-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-137. - Resolution: Fixed This was fixed in 2.3. > provide option to list all of the test cases which failed when running a build > -- > > Key: SUREFIRE-137 > URL: http://jira.codehaus.org/browse/SUREFIRE-137 > Project: Maven Surefire > Issue Type: Improvement >Reporter: james strachan > Fix For: 2.4 > > Attachments: MSUREFIRE-143-maven-surefire-plugin.patch, > MSUREFIRE-143-maven-surefire-plugin.patch, MSUREFIRE-143-surefire-api.patch, > MSUREFIRE-143-surefire-api.patch > > > Lots of projects I work on have large numbers of test cases; the execution of > the tests takes up many screens. We are often see the output... > Results : > Tests run: 1496, Failures: 0, Errors: 5, Skipped: 0 > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] There are test failures. > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > > Then we have to page up manually grepping for <<< FAILURE which can take a > while. It would be good to just list the failed test cases in the output -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-353) Link to test JavaDoc in test repor
[ http://jira.codehaus.org/browse/SUREFIRE-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-353. - Resolution: Won't Fix Fix Version/s: (was: 2.x) We're limited to the information available in the JUnit XML output for information like this. Fortunately, the surefire-report plugin knows how to integrate with JXR for test failures, so you can click through to see the source code of offending test failures; that should be enough information to analyze the test results. > Link to test JavaDoc in test repor > -- > > Key: SUREFIRE-353 > URL: http://jira.codehaus.org/browse/SUREFIRE-353 > Project: Maven Surefire > Issue Type: New Feature > Components: report plugin >Reporter: Francois Loison >Priority: Minor > > Current report could be improved by displaying functional information of test > cases. > For exemple: > TestX : tests functionality X > One way should be to document test case functionality in javadoc and add an > hyperlink in surefire report to javadoc. > If feature agreed, I could propose some code. > [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-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 ] Dan Fabulich closed SUREFIRE-171. - Resolution: Incomplete Fix Version/s: (was: 2.4) This isn't enough information for us to reproduce the problem. If you're still having difficulties, please provide a reduced test case (in the form of an archived minimal Maven project) that exhibits the problem. > 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 > 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] Closed: (SUREFIRE-185) Known bug should not break the build
[ http://jira.codehaus.org/browse/SUREFIRE-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-185. - Resolution: Fixed Fix Version/s: (was: 2.x) JUnit 4 and TestNG both provide support for skipping tests that can be ignored; Surefire now supports both of those frameworks. If you use those frameworks to skip tests, the build won't fail. > Known bug should not break the build > > > Key: SUREFIRE-185 > URL: http://jira.codehaus.org/browse/SUREFIRE-185 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 3.x support >Affects Versions: 2.0 (2.2 plugin) > Environment: Maven 2.0.4 >Reporter: J-C Walmetz >Priority: Minor > > With surefire plugin we can exclude a test, Ignore failures or skip tests. > - If I exclude a test, test is not in surefire report > - If I ignore failures, it ignore all the failures. Report contains all the > tests but I not able to know is tests in failure where expectedc or not. > - If I skip test, I have no more report. > Sometimes we discover a bug in our source code but don't know how to fix it. > If this bug is acceptable, it is a known bug. In order not to forget it, I'd > like to implement a testcase that have to be in the final report. This bug is > known and accepted, so it sould not break the build. It would be great to be > able to add in plugin configuration a list of know test failure. If a tests > included in this list failed, it does not break the build but as test has > been executed it will be display in the report. If another tests failed, it > is an unknown bug, it should break the build. > Config may looks like: > > org.apache.maven.plugins > maven-surefire-plugin > > > < knownFailure > > com.mytest.MyBugTestCase > java.lang.NullPointerException > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-109) VM Forking manifests itself behind HTTP proxy
[ http://jira.codehaus.org/browse/SUREFIRE-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-109. - Resolution: Incomplete Fix Version/s: (was: 2.4) This isn't enough information to reproduce the problem; as Kenney suggested, it's reasonable to think that the bug is related to your network configuration. If possible, please provide a reduced test case (in the form of an archive of a minimal Maven project) that reproduces the problem. > VM Forking manifests itself behind HTTP proxy > - > > Key: SUREFIRE-109 > URL: http://jira.codehaus.org/browse/SUREFIRE-109 > Project: Maven Surefire > Issue Type: Bug > Components: classloading, plugin >Affects Versions: 2.3 > Environment: win2k, java 1.5 >Reporter: Ben Hood > Attachments: mvn_trace.txt > > > I have reason to believe that the forking behaviour of the surefire execution > has adverse effects when executed behind an HTTP proxy in combination with > DTD resolution (e.g. the loading of Spring beans). > Whilst using surefire to test a project (the acegi module from the mule > project, svn respo : http://svn.codehaus.org/mule/trunk/mule/modules/acegi , > revision 2859) I was getting DTD resolution errors (see attached trace). > I orginally posted this over at Spring: > http://opensource.atlassian.com/projects/spring/browse/SPR-2466. > Trying to get Eclipse to attach to the Maven debug process I set up (i.e. > running maven with MAVEN_OPTS="-Xdebug -Xnoagent > -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8787"), I found out > that this won't work because the plugin executing the code forks a new VM. > After telling the maven surefire-plugin not to fork with this setting: > > > > org.apache.maven.plugins > maven-surefire-plugin > > never > > > > > the problem with the DTD resolution from Spring went away. > Under normal circumstances, the DTD should get resolved from within the > classpath, as it is bundled in the jar. > So therefore I conclude that it is indeed a maven classloading / VM issue and > not a Spring issue as first thought. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-103) 2.3-SNAPSHOT fails to deserialize an object due to ClassNotFoundException (regression)
[
http://jira.codehaus.org/browse/SUREFIRE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich closed SUREFIRE-103.
-
Resolution: Incomplete
Fix Version/s: (was: 2.4)
This isn't enough information to work on this bug; please provide (attach) a
reduced test case demonstrating the problem, ideally in the form of a minimal
Maven project exhibiting the problem. [The code base of the entire mule
project is not reduced enough. ;-)]
> 2.3-SNAPSHOT fails to deserialize an object due to ClassNotFoundException
> (regression)
> --
>
> Key: SUREFIRE-103
> URL: http://jira.codehaus.org/browse/SUREFIRE-103
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Andrew Perepelytsya
> Attachments:
> FAILED_org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.txt,
>
> FAILED_TEST-org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.xml,
> org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.txt,
> RELEASE-m2-run.txt, SNAPSHOT-m2-run.txt,
> TEST-org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.xml
>
>
> Ok, I know how tricky it can be to explain such bug, but I'll try. We've
> switched to using 2.3-SNAPSHOT version of the plugin to get the fix for this
> error when test reports failed the build in case of test errors without
> generating any report. This part works fine now, but it has introduced a
> regression.
> I'm attaching the test failure reports(it always worked before). To reproduce
> the error (tricky part) - I can only think of checking out Mule project SVN
> source as of r2315 from http://svn.codehaus.org/mule/ What you need is only a
> top-level dir and mule-core.
> {panel}
> mvn test -Dtest=SerializedUMOMessageTransformersTestCase
> {panel}
> r2315 has 2.3-SNAPSHOT plugin version declared in a top-level pom. Change it
> to RELEASE, and the problem is again gone.
> I'm also attaching m2 debug output for SNAPSHOT and RELEASE runs, hope it
> helps.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-335) forkMode = none is incompatible with useSystemClassLoader = true
[ http://jira.codehaus.org/browse/SUREFIRE-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114628 ] Dan Fabulich commented on SUREFIRE-335: --- I don't understand this bug at all. As noted, you can't modify the system classpath once you're running (hence the need to fork). It sounds like you're imagining an alternate meaning of "useSystemClassloader" which would merely copy the system classloader (or just inherit from it)? Why would you want that? Are you saying that it would have helped solve the CNFE you had with your Archiva test? How? > forkMode = none is incompatible with useSystemClassLoader = true > > > Key: SUREFIRE-335 > URL: http://jira.codehaus.org/browse/SUREFIRE-335 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.3.1 > > > these options are obviously not compatible as the method of implementation of > the latter requires forking. An alternate implementation should be used that > includes the system class loader > However, the following occurs in Archiva: > Caused by: java.lang.ClassNotFoundException: > org.apache.maven.archiva.configuration.ArchivaConfigurationTest > at java.net.URLClassLoader$1.run(URLClassLoader.java:200) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at > org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195) > at > org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255) > at > org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) > at > org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:87) > ... 27 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-44) Inner class inclusion too powerful
[
http://jira.codehaus.org/browse/SUREFIRE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich closed SUREFIRE-44.
Resolution: Cannot Reproduce
Fix Version/s: (was: 2.4)
Can't reproduce; integration checked in revision 597570
> Inner class inclusion too powerful
> --
>
> Key: SUREFIRE-44
> URL: http://jira.codehaus.org/browse/SUREFIRE-44
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.0 (2.2 plugin)
>Reporter: Ken Arnold
>
> When inner classes were included, it was done in a way that was too powerful.
> I believe it is too powerful in the following ways:
> It is not name based -- it assumes that all inner classes of an included
> class are test cases.
> It does not work on nested classes (non-static classes)
> See the test case and stack trace below.
> I know people put tests in nested classes, but many nested classes exist for
> other reasons (simple mock objects, for example). Inner classes do not have
> no-arg constructors, and so including them includes classes that pretty much
> by definition will not be runnable.
> As things stand, I cannot put a nested (non-static inner) class in a test
> case. I will get the exception below.
> There needs to be some marker for nested test classes. If nothing else,
> nested classes without a no-arg constructor should be ignored.
> But that still makes the inclusion very broad. The default inclusion of
> top-level classes is much more selective. I would prefer if the default
> inclusion of nested classes followed the same default naming pattern. But at
> the very least, please ignore classes without no-arg constructors.
> I have been puzzling myself over errors like the following:
> java.lang.NoSuchMethodException:
> com.hyphenhealth.edc.drq.editchecks.queries.compute.TestAThing$Foo.()
> at java.lang.Class.getConstructor0(Class.java:2647)
> at java.lang.Class.getConstructor(Class.java:1629)
> at
> org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
> at
> org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:150)
> at
> org.apache.maven.surefire.battery.JUnitBattery.(JUnitBattery.java:81)
> at
> org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:63)
> at
> org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:140)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:63)
> 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.SurefireBooter.main(SurefireBooter.java:785)
> RUN ABORTED
> java.lang.NoSuchMethodException
> Test code:
> public class TestAThing {
> public class Foo { }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-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 ] Dan Fabulich closed SUREFIRE-266. - Resolution: Cannot Reproduce Fix Version/s: (was: 2.4) Must have been fixed at some point; this is working in the latest 2.4 trunk > 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 > > 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) >
[jira] Closed: (SUREFIRE-355) Sort tests in alphabetical order in the report
[ http://jira.codehaus.org/browse/SUREFIRE-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-355. - Resolution: Duplicate Fix Version/s: (was: 2.x) Duplicate of SUREFIRE-321 > Sort tests in alphabetical order in the report > -- > > Key: SUREFIRE-355 > URL: http://jira.codehaus.org/browse/SUREFIRE-355 > Project: Maven Surefire > Issue Type: Wish > Components: report plugin >Affects Versions: 2.3 >Reporter: Samuel Langlois >Priority: Minor > > The surefire report lists the tests in an arbitrary order. > It would be better if they were sorted alphabetically. > Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-358) Surefire: Testexecution fails if directory name conains german umlauts
[ http://jira.codehaus.org/browse/SUREFIRE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-358. - Resolution: Duplicate Fix Version/s: (was: 2.4) duplicate of SUREFIRE-313 > Surefire: Testexecution fails if directory name conains german umlauts > -- > > Key: SUREFIRE-358 > URL: http://jira.codehaus.org/browse/SUREFIRE-358 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven version: 2.0.7; Java version: 1.6.0_01; OS: German > Windows XP Version: 5.1 Arch: x86 >Reporter: codehauser > Attachments: Error.log > > > If I execute "mvn install" and the project is located in a directory which > contains umlauts (e.g. Übung) the test-execution (or maybe already build) > fails. With a > org.apache.maven.surefire.booter.SurefireExecutionException: Unable to create > test class 'X'; nested exception is java.lang.ClassNotFoundException > Exception > Attached a log with sensitive information removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-359) surefire:surefire failes when there are spaces in directory names
[ http://jira.codehaus.org/browse/SUREFIRE-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-359. - Resolution: Duplicate Fix Version/s: (was: 2.4) Duplicate of SUREFIRE-285 > surefire:surefire failes when there are spaces in directory names > - > > Key: SUREFIRE-359 > URL: http://jira.codehaus.org/browse/SUREFIRE-359 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support >Affects Versions: 2.4 > Environment: linux > maven 2.0.7 > surefire-2.4-snapshot >Reporter: Jeff Black > > This issue is similar to others filed, but specific enough I wanted to report > it separately. > On an ubunu linux system, if I checkout a maven project into a directory with > spaces in the full path, surefire will fail the build before the tests are > actually executed. (Spaces in the path occur, for example, when I build a > Hudson job with spaces in the project name.) > [INFO] [clean:clean] > [INFO] Deleting directory /home/hudson/.hudson/jobs/sto > dirspaces/workspace/persistence/target > [INFO] Deleting directory /home/hudson/.hudson/jobs/sto > dirspaces/workspace/persistence/target/classes > [INFO] Deleting directory /home/hudson/.hudson/jobs/sto > dirspaces/workspace/persistence/target/test-classes > [INFO] Deleting directory /home/hudson/.hudson/jobs/sto > dirspaces/workspace/persistence/target/site > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] Copying 1 resource > [INFO] [compiler:compile] > [INFO] Compiling 50 source files to /home/hudson/.hudson/jobs/sto > dirspaces/workspace/persistence/target/classes > [INFO] [resources:testResources] > [INFO] Using default encoding to copy filtered resources. > [INFO] Copying 2 resources > [INFO] [compiler:testCompile] > [INFO] Compiling 14 source files to /home/hudson/.hudson/jobs/sto > dirspaces/workspace/persistence/target/test-classes > [INFO] [surefire:test] > [INFO] Surefire report directory: /home/hudson/.hudson/jobs/sto > dirspaces/workspace/persistence/target/surefire-reports > /bin/bash: line 0: cd: /home/hudson/.hudson/jobs/sto: No such file or > directory > [ERROR] There are test failures. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-341) Surefire fails with java.lang.ClassNotFoundException: org.apache.maven.surefire.Surefire
[ http://jira.codehaus.org/browse/SUREFIRE-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-341. - Resolution: Duplicate Fix Version/s: (was: 2.x) duplicate of SUREFIRE-313 > Surefire fails with java.lang.ClassNotFoundException: > org.apache.maven.surefire.Surefire > > > Key: SUREFIRE-341 > URL: http://jira.codehaus.org/browse/SUREFIRE-341 > Project: Maven Surefire > Issue Type: Bug >Reporter: Pär Wenåker > > Surefire fails with exception: > org.apache.maven.surefire.booter.SurefireExecutionException: Unable to > instantiate and execute Surefire; nested exception is > java.lang.ClassNotFoundException: org.apache.maven.surefire.Surefire > java.lang.ClassNotFoundException: org.apache.maven.surefire.Surefire > at java.net.URLClassLoader$1.run(URLClassLoader.java:200) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at > org.apache.maven.surefire.booter.IsolatedClassLoader.loadClass(IsolatedClassLoader.java:103) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:281) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) > This is probably due to the maven repository being located in a director > containing a Swedish letter (C:\Documents and Settings\Pär\.m2\repository). > When I changed the location of the repository the problem disappeared -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-48) TestSetup decorators don't work
[ http://jira.codehaus.org/browse/SUREFIRE-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-48. Resolution: Duplicate Fix Version/s: (was: 2.4) Duplicate of SUREFIRE-114 > TestSetup decorators don't work > --- > > Key: SUREFIRE-48 > URL: http://jira.codehaus.org/browse/SUREFIRE-48 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.0 (2.2 plugin) >Reporter: Mike Perham > > junit.extensions.TestSetup allow you to decorate a test like this: > ts.addTest(new CargoTestSetup(DetailPageTest.suite())); > Basically this will run Cargo to startup a container before running the tests > within that suite. When I try this, I get this error: > Caused by: java.lang.NoSuchMethodException: tools.CargoTestSetup.getName() > at java.lang.Class.getMethod(Class.java:986) > at > org.apache.maven.surefire.junit.TestListenerInvocationHandler.getStackTraceWriter(TestListenerInvocationHandler.java:171) > at > org.apache.maven.surefire.junit.TestListenerInvocationHandler.handleAddError(TestListenerInvocationHandler.java:160) > at > org.apache.maven.surefire.junit.TestListenerInvocationHandler.invoke(TestListenerInvocationHandler.java:134) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-285) Build fails on Windows when the folder being executed has spaces in it.
[ http://jira.codehaus.org/browse/SUREFIRE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-285. - Resolution: Cannot Reproduce Fix Version/s: (was: 2.4) Can't reproduce this on latest 2.4 trunk; integration tested. > Build fails on Windows when the folder being executed has spaces in it. > --- > > Key: SUREFIRE-285 > URL: http://jira.codehaus.org/browse/SUREFIRE-285 > Project: Maven Surefire > Issue Type: Bug > Components: plugin >Affects Versions: 2.3 > Environment: Windows XP, Maven 2.0.4 >Reporter: Petar Tahchiev > Attachments: MavenSurefire.patch, SUREFIRE-285.patch > > > Hi guys, > I am a fan of the Fedora Core linux system, and I don't have any problem when > trying to build the surefire plugin on that box, but today I sat on a Windows > PC and I checkout the project in "My Documents" folder. I tried to build the > plugin and one of the tests - UrlUtilTest failed. After examining the results > it turned out that it was looking for url of the type: > "file:/C:\My Documents\workspace\surefire" but found > "file:/C:\My%20Documents\workspace\surefire", which I guess is because you > have forgotten to escape the intervals. > Anyway I escaped the spaces and it works as a charm. > Please review accept my patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-128) Argline splits on spaces, should not when quoted
[
http://jira.codehaus.org/browse/SUREFIRE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich closed SUREFIRE-128.
-
Resolution: Duplicate
Fix Version/s: (was: 2.4)
Duplicate of SUREFIRE-55
> Argline splits on spaces, should not when quoted
>
>
> Key: SUREFIRE-128
> URL: http://jira.codehaus.org/browse/SUREFIRE-128
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.0 (2.2 plugin)
>Reporter: Andrea Aime
>Priority: Blocker
>
> I need to run surefire with the following argline:
> -javaagent:\"${user.home}\.m2\repository\aspectj\aspectjweaver\1.5.0\aspectjweaver-1.5.0.jar\"
> -javaagent:\"C:\Documents
> Settings\wolf\.m2\repository\aspectj\aspectjweaver\1.5.0\aspectjweaver-1.5.0.jar\"
> The problem is, ForkConfiguration splits the arguments blindly with
> StringUtils.split and the above turns into three
> separate arguments:
> -javaagent:"C:\Documents
> and
> Settings\wolf\.m2\repository\aspectj\aspectjweaver\1.5.0\aspectjweaver-1.5.0.jar"
> And the the vm complains it cannot find the jar C:\Documents.
> When quoted, the split should not happen!
> The following method proved to support quoting properly when splitting on
> spaces (I'm using it in UmlGraph):
> public static String[] tokenize(String s) {
> ArrayList r = new ArrayList();
> String remain = s;
> int n = 0, pos;
> remain = remain.trim();
> while (remain.length() > 0) {
> if (remain.startsWith("\"")) {
> // Field in quotes
> pos = remain.indexOf('"', 1);
> if (pos == -1)
> break;
> r.add(remain.substring(1, pos));
> if (pos + 1 < remain.length())
> pos++;
> } else {
> // Space-separated field
> pos = remain.indexOf(' ', 0);
> if (pos == -1) {
> r.add(remain);
> remain = "";
> } else
> r.add(remain.substring(0, pos));
> }
> remain = remain.substring(pos + 1);
> remain = remain.trim();
> // - is used as a placeholder for empy fields
> if (r.get(n).equals("-"))
> r.set(n, "");
> n++;
> }
> return r.toArray(new String[0]);
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-175) NoClassDefFoundError for UrlUtils
[ http://jira.codehaus.org/browse/SUREFIRE-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-175. - Resolution: Cannot Reproduce Fix Version/s: (was: 2.4) Doesn't appear to be happening in 2.4 trunk; integration tests are passing. > 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 > > 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] Closed: (SUREFIRE-368) Property java.class.path modified by the user, it is not taken into account by ClassLoader
[
http://jira.codehaus.org/browse/SUREFIRE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich closed SUREFIRE-368.
-
Resolution: Duplicate
Fix Version/s: (was: 2.4)
Duplicate of SUREFIRE-180
> Property java.class.path modified by the user, it is not taken into account
> by ClassLoader
> --
>
> Key: SUREFIRE-368
> URL: http://jira.codehaus.org/browse/SUREFIRE-368
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: David Leal
> Attachments: FileUtils.java, TestFileUtils2.java
>
>
> I have a simple class that just find a file on classpath, i.e.:
> public final class FileUtils extends org.apache.commons.io.FileUtils {
> public static File findFileInClasspath(String fileName)
> throws UnsupportedEncodingException, FileNotFoundException {
> return findFileInClasspath(fileName, FileUtils.LATIN_CODE);
> }
>
> public static File findFileInClasspath(String fileName, String encoding)
> throws UnsupportedEncodingException, FileNotFoundException {
> URL url = FileUtils.class.getClassLoader().getResource(fileName);
> if (url == null) {
> throw new FileNotFoundException(fileName);
> }
> String file = URLDecoder.decode(url.getFile(), encoding);
> return new File(file);
> }
> }
> I would like to test this method, without leaving a testing file on
> test/resources, so I want to use at valid location on classpath, so I
> configurate the pluggin:
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
> once
>
>
> java.class.path
> ${user.dir}
>
>
>
>
>
> Note: if I add the variable: ${maven.test.classpath} its value is not
> translated into the corresponding value.
> On my testing process I look on the property variable: java.class.path in
> effect its point into: ${user.dir} but the testing method still fails. Under
> Eclipse the same test, doesn't fail.
> Under Maven the test for some reason it fails even the on the java.class.path
> there is directory (that's the condition I need in order to run the test).
> On the atached file you can find the source and testing file.
> I now it is possible to desing a different test using a resource file for
> this purpose, but I am very suprise about this behavour. It open for me the
> question about: How really the user control de classpath during the testing
> process.
> After running the testing file I get:
> ---
> T E S T S
> ---
> Running com.ceb2b2000.commons.io.TestFileUtils2
> 30-oct-2007 0:25:34 com.ceb2b2000.commons.io.TestFileUtils2
> findDirectoryOnClass
> path
> INFO: classpath = P:\ceb2b2000-commons\ceb2b2000-commons-io
> <<< FAILURE!
> Results :
> Tests in error:
> testFindFileInClasspath(com.ceb2b2000.commons.io.TestFileUtils2)
> Tests run: 4, Failures: 0, Errors: 3, Skipped: 0
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-288) Surefire tries to instantiate nested TestCase classes
[ http://jira.codehaus.org/browse/SUREFIRE-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-288. - Resolution: Duplicate Fix Version/s: (was: 2.4) Duplicate of surefire-44, fixed and integration tested. > Surefire tries to instantiate nested TestCase classes > - > > Key: SUREFIRE-288 > URL: http://jira.codehaus.org/browse/SUREFIRE-288 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support, Junit 4.x support >Affects Versions: 2.0 (2.2 plugin) > Environment: Windows XP, Java 1.4.2 >Reporter: Stephen Coy > > If a JUnit TestCase contains any kind of nested class (static or not), > Surefire feels obliged to try and instantiate it. This will fail with access > violations if the class is not public. > Work around seems to be to make the nested class public, but surely Surefire > has no business doing this anyway? > Here is a sample stack trace: > org.apache.maven.surefire.booter.SurefireExecutionException: Unable to > instantiate POJO 'class > au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent'; > nested exception is java.lang.InstantiationException: > au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent; > nested exception is > org.apache.maven.surefire.testset.TestSetFailedException: Unable to > instantiate POJO 'class > au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent'; > nested exception is java.lang.InstantiationException: > au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent > org.apache.maven.surefire.testset.TestSetFailedException: Unable to > instantiate POJO 'class > au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent'; > nested exception is java.lang.InstantiationException: > au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent > java.lang.InstantiationException: > au.com.optus.eFulfilment.sap.test.moduleTest.TestSapOrderComponent$MySapOrderComponent > at java.lang.Class.newInstance0(Class.java:293) > at java.lang.Class.newInstance(Class.java:261) > at > org.apache.maven.surefire.testset.PojoTestSet.(PojoTestSet.java:52) > at > org.apache.maven.surefire.junit.JUnitDirectoryTestSuite.createTestSet(JUnitDirectoryTestSuite.java:61) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:93) > at > org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:147) > 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:324) > 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] Closed: (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 ] Dan Fabulich closed SUREFIRE-256. - Resolution: Duplicate Fix Version/s: (was: 2.4) Duplicate of SUREFIRE-122, fixed and tested. > 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 > 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] Closed: (SUREFIRE-115) Surefire-JUnit does not recognize "suite"-methods
[
http://jira.codehaus.org/browse/SUREFIRE-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Fabulich closed SUREFIRE-115.
-
Resolution: Cannot Reproduce
This was fixed in 2.3. 2.4 integration tests are passing, so this works now.
> Surefire-JUnit does not recognize "suite"-methods
> -
>
> Key: SUREFIRE-115
> URL: http://jira.codehaus.org/browse/SUREFIRE-115
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.0 (2.2 plugin)
>Reporter: Philip Gerlach
> Fix For: 2.4
>
> Attachments: commons-events-pom.xml,
> maven-surefire-junit-trunk-412516.patch,
> maven-surefire-junit-trunk-492590.patch, surefire-test.zip
>
>
> Since Surefire-JUnit doesn't support JUnit4 yet, i tried to use a
> "suite"-method like
> --
> public static junit.framework.Test suite() {
>return new junit.framework.JUnit4TestAdapter(Foo.class);
> }
> -
> to run it, but Surefire-JUnit did not recognize these methods and treated
> them like PojoTests what obviously lead to TestFailures.
> So I fetched the source code from the repository and searched for the
> problem. I found two if-conditons in JUnitTestSet and JUnitDirectoryTestSuite
> that did not test for the "suite"-mechanism, so I wrote a new static method
> to test for this situation and integrated it in the if-conditions.
> Now the "suite"-methods work for my JUnit4 Tests and should do also for
> others ;-)
> The patch is attached.
> P.S. Since this it is the first time, I'm trying to bugfix something for an
> open source-project, please just let me know, if I have done something wrong
> with this process.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-42) TestListenerInvocationHandler incorrectly assumes getName()
[ http://jira.codehaus.org/browse/SUREFIRE-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-42. Resolution: Cannot Reproduce This bug was fixed at some point; integration test checked in revision 597574. > TestListenerInvocationHandler incorrectly assumes getName() > --- > > Key: SUREFIRE-42 > URL: http://jira.codehaus.org/browse/SUREFIRE-42 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.0 (2.2 plugin) >Reporter: Matthew Beermann > Fix For: 2.4 > > Attachments: patch.txt, SUREFIRE-42-surefire-junit.patch > > > I'm running test cases that extend our own custom base test case. If one of > the tests fails, Surefire itself fails: > org.apache.maven.surefire.booter.SurefireExecutionException: > com.cerner.system.util.CalendarsTest; nested exception is > java.lang.reflect.UndeclaredThrowableException: null; nested exception is > org.apache.maven.surefire.testset.TestSetFailedException: > com.cerner.system.util.CalendarsTest; nested exception is > java.lang.reflect.UndeclaredThrowableException: null > org.apache.maven.surefire.testset.TestSetFailedException: > com.cerner.system.util.CalendarsTest; nested exception is > java.lang.reflect.UndeclaredThrowableException: null > java.lang.reflect.UndeclaredThrowableException > at $Proxy0.addError(Unknown Source) > at junit.framework.TestResult.addError(TestResult.java:36) > ... > Caused by: java.lang.NoSuchMethodException: > com.cerner.junit.madhatter.classreloader.ReloadedTestCaseDecorator.getName() > at java.lang.Class.getMethod(Class.java:986) > at > org.apache.maven.surefire.junit.TestListenerInvocationHandler.getStackTraceWriter(TestListenerInvocationHandler.java:171) > at > org.apache.maven.surefire.junit.TestListenerInvocationHandler.handleAddError(TestListenerInvocationHandler.java:160) > at > org.apache.maven.surefire.junit.TestListenerInvocationHandler.invoke(TestListenerInvocationHandler.java:134) > ... 23 more > At TestListenerInvocationHandler:171, I see that it's trying to reflect to a > method called getName(). This seems like a very poor assumption, given that > nothing on the Test or TestListener interfaces guarantees that there'll be a > method called getName(). At the very least, shouldn't the > NoSuchMethodException be caught and handled somewhere? See: > http://www.junit.org/junit/javadoc/3.8.1/index.htm -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-344) connecting existing workspace artifact-projects
[ http://jira.codehaus.org/browse/MECLIPSE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114611 ] Arnaud Heritier commented on MECLIPSE-344: -- One question about your patch : Why did you call the configuration variable for the workspace : workspaceToConnect I believed there was already a workspace var but it's not the case. The workspace is in the new Mojo for workspace configuration. > connecting existing workspace artifact-projects > --- > > Key: MECLIPSE-344 > URL: http://jira.codehaus.org/browse/MECLIPSE-344 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: dependency resolution >Reporter: Richard van Nieuwenhoven > Attachments: workspace-new-files.tgz, workspace.patch, > workspace_with_limit.patch > > > This patch enables you to specify your workspace, and all dependent artefacts > that are available in your eclipse-workspace will be attached as project > references even if they are not in the reactor. > the property can be set with -DworkspaceToConnect=. > I did not have the time to create Test cases but, i maybe someone can help > with that! > The patch is based on the MECLIPSE-333 branch. > as usual the new files are in the extra tgz. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRM-595) regression : server-side relocation fails
[ http://jira.codehaus.org/browse/MRM-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRM-595. Assignee: Maria Odea Ching Resolution: Fixed > regression : server-side relocation fails > - > > Key: MRM-595 > URL: http://jira.codehaus.org/browse/MRM-595 > Project: Archiva > Issue Type: Bug > Components: WebDAV interface >Affects Versions: 1.0-beta-4 >Reporter: nicolas de loof >Assignee: Maria Odea Ching > Fix For: 1.0 > > Attachments: MRM-595.patch, plexus-webdav-api.patch > > > 1.0-beta-4 introduces a regression in maven1 request handling : > simply try to get : > http://localhost:8080/archiva/repository/internal/servletapi/jars/servletapi-2.4.jar > two causes : > 1. as fetchContentFromProxies MAY change the request pathInfo when relocation > occurs, it MUST be called before resource file is build based on > request.getLogicalResource(). > 2. getLogicalResource() is used to get the resource path. The value returned > is not affected when the request PathInfo has been changed. > point 2 may require some changes in plexus DavServerRequest : compute the > logical resource on-demand, or add a new public method to set it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPSCM-98) maven-scm-plugin configuration is ignored if executions present
maven-scm-plugin configuration is ignored if executions present --- Key: MPSCM-98 URL: http://jira.codehaus.org/browse/MPSCM-98 Project: Maven 1.x SCM Plugin Issue Type: Bug Environment: Maven version: 2.0.7 Java version: 1.6.0_01 Reporter: jason harrop Priority: Minor If I don't use the element, the embedded configuration is used. org.apache.maven.plugins maven-scm-plugin 1.0 scm:svn:http://dev.plutext.org/svn/docx4j/trunk/docx4j docx4j validate However, I would like to checkout 2 modules from each of 2 different repositories. If I introduce , the plugin doesn't read the embedded configuration. Instead, it falls back to what is defined in the element (or if none exists, the super pom). Here is what I have trying: org.apache.maven.plugins maven-scm-plugin 1.0 checkout-docx4j scm:svn:http://dev.plutext.org/svn/docx4j/trunk/docx4j docx4j validate checkout-jackrabbit-webapp scm:svn:http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-webapp jackrabbit-webapp validate -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (SCM-352) maven-scm-plugin configuration is ignored if executions present
[ http://jira.codehaus.org/browse/SCM-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jason harrop closed SCM-352. Resolution: Fixed Hmm, i can clone an issue, but can't then change its description? Closing it, to start a new one from scratch. > maven-scm-plugin configuration is ignored if executions present > --- > > Key: SCM-352 > URL: http://jira.codehaus.org/browse/SCM-352 > Project: Maven SCM > Issue Type: Bug > Components: maven-plugin > Environment: xp, linux starteam >Reporter: jason harrop >Assignee: Dan Tran > > I am trying to do this > > > > maven.scm.plugin > > > > checkin > > xuy > > > > ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-352) maven-scm-plugin configuration is ignored if executions present
maven-scm-plugin configuration is ignored if executions present --- Key: SCM-352 URL: http://jira.codehaus.org/browse/SCM-352 Project: Maven SCM Issue Type: Bug Components: maven-plugin Environment: xp, linux starteam Reporter: jason harrop Assignee: Dan Tran I am trying to do this maven.scm.plugin checkin xuy ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-349) Move integration tests in the integration-tests profile
[ http://jira.codehaus.org/browse/MECLIPSE-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-349: - Issue Type: Task (was: Improvement) > Move integration tests in the integration-tests profile > --- > > Key: MECLIPSE-349 > URL: http://jira.codehaus.org/browse/MECLIPSE-349 > Project: Maven 2.x Eclipse Plugin > Issue Type: Task >Affects Versions: 2.4 >Reporter: Arnaud Heritier > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MNG-3300) Nested compile source roots in effective POM cause bad Eclipse build path
[
http://jira.codehaus.org/browse/MNG-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier moved MECLIPSE-335 to MNG-3300:
---
Affects Version/s: (was: 2.4)
2.0.7
Key: MNG-3300 (was: MECLIPSE-335)
Project: Maven 2 (was: Maven 2.x Eclipse Plugin)
> Nested compile source roots in effective POM cause bad Eclipse build path
> -
>
> Key: MNG-3300
> URL: http://jira.codehaus.org/browse/MNG-3300
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.7
> Environment: Maven 2.0.7, JDK 1.5.0_12, WinXP
>Reporter: Benjamin Bentmann
> Attachments: nested-source-roots.patch, nested-sources.zip
>
>
> Source generating plugins like for JavaCC or JFlex usually add their output
> folder to the POM as a compile source root. If these source directories
> happen to be nested, i.e. "src/main/java" and additional something like
> "src/main/java/org/apache", mvn eclipse:eclipse produces the following bad
> .classpath contents with overlapping build paths:{code:xml}
>
>
>
> ...
>
> {code}
> While this issues relates to MECLIPSE-114, I really think my problem is
> caused by Maven.
> Though the maven-eclipse-plugin causes the problem to manifest itself, it
> might not be the proper place to solve it as it appears to be a more general
> issue (i.e. the Maven Eclipse Integration might also be affected, though I
> did not test this). Surely, each and every plugin developer could be told to
> check for source directory nesting but I consider this an error-prone
> approach. I would rather appreciate either that
> MavenProject.addCompileSourceRoot() automatically ignores nested source
> directories (if such a general change is acceptable) or that new methods in
> MavenProject are introduced that allow for conditional addition of source
> roots only if they do not nest with existing roots such that plugin
> developers can easily fix the problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-352) RAD application.xml is not generated with good parameters
[ http://jira.codehaus.org/browse/MECLIPSE-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MECLIPSE-352. Assignee: Arnaud Heritier Resolution: Fixed Fix Version/s: 2.5 This time, it's fixed. I added a test case. A new SNAPSHOT is deployed > RAD application.xml is not generated with good parameters > - > > Key: MECLIPSE-352 > URL: http://jira.codehaus.org/browse/MECLIPSE-352 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: RAD support >Affects Versions: 2.4 > Environment: Windows XP, RAD6, JDK1.4 >Reporter: Olivier Chaumont >Assignee: Arnaud Heritier > Fix For: 2.5 > > > Hi, > The application.xml file which is generated by the command mvn eclipse:rad on > an EAR maven project is not correct beacuse the schema location is > xmlns:schemalocation and not xsi:schemalocation, and so the deploy on > WebSphere with RAD6 doesn't work. > I found the same bug in the issue MECLIPSE-137 (Developed RAD-6 Plugin > Extention) in the comment of Brandon Burk (19/Dec/06 10:40 PM) here: > Primary bug fix (that I can remember)... > - Rad6ApplicationXMLWriter.java: > changed: > private static final String XMLNS_SCHEMA_LOCATION = "xmlns:schemaLocation"; > to: > private static final String XMLNS_SCHEMA_LOCATION = "xsi:schemaLocation"; > This issue is fixed but I don't find the modification in 2.4 of the 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] Closed: (MINVOKER-9) Interpolate goal files
[
http://jira.codehaus.org/browse/MINVOKER-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MINVOKER-9.
---
Resolution: Fixed
committed in rev 597507
> Interpolate goal files
> --
>
> Key: MINVOKER-9
> URL: http://jira.codehaus.org/browse/MINVOKER-9
> Project: Maven 2.x Invoker Plugin
> Issue Type: New Feature
>Affects Versions: 1.1
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
> Fix For: 1.1
>
>
> I'd like to use goals like :
> ${project.groupId}:${project.artifactId}:${project.version}:mygoal.
> Actually it's with adding this goals but in the mojo but this means it will
> be the same for all it's.
> By default the interpolation values could contains the current pom which
> should be available with ${pom.} and adding a Map in the mojo in order to
> define some others.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-387) Build fails even though all the test passes and no information is provided by surefire
[ http://jira.codehaus.org/browse/SUREFIRE-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thibaut Bodart closed SUREFIRE-387. --- Resolution: Fixed Found the reason... Sorry for the inconvenience. Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.563 sec java.lang.IllegalThreadStateException at java.lang.ThreadGroup.add(ThreadGroup.java:856) at java.lang.Thread.start(Thread.java:573) at java.lang.Shutdown.runHooks(Shutdown.java:128) at java.lang.Shutdown.sequence(Shutdown.java:173) at java.lang.Shutdown.exit(Shutdown.java:218) at java.lang.Runtime.exit(Runtime.java:90) at java.lang.System.exit(System.java:869) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:824) Exception in thread "main" java.lang.IllegalThreadStateException at java.lang.Thread.start(Thread.java:571) at java.lang.Shutdown.runHooks(Shutdown.java:128) at java.lang.Shutdown.sequence(Shutdown.java:173) at java.lang.Shutdown.exit(Shutdown.java:218) at java.lang.Runtime.exit(Runtime.java:90) at java.lang.System.exit(System.java:869) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:832) One of my test is creating some background threads that are not killed when the test completes > Build fails even though all the test passes and no information is provided by > surefire > -- > > Key: SUREFIRE-387 > URL: http://jira.codehaus.org/browse/SUREFIRE-387 > Project: Maven Surefire > Issue Type: Bug > Components: plugin >Affects Versions: 2.3 > Environment: Maven 2.0.7 > Surefire 2.3 >Reporter: Thibaut Bodart >Priority: Minor > > Hi... > My problem is the following: > * I run "mvn clean install" > * All the tests passes > * Surefire says "BUILD FAILURE" and does not provide more information > Any idea ? > Is there any way of getting more information from surefire. Using -e or -X > does not help. > See logs below... > Results : > Tests run: 23, Failures: 0, Errors: 0, Skipped: 0 > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] There are test failures. > [INFO] > > [INFO] Trace > org.apache.maven.BuildFailureException: There are test failures. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoFailureException: There are test > failures. > at > org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:425) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > ... 16 more > [INFO] > > [INFO] Total time: 1 minute 21 seconds > [INFO] Finished at: Thu Nov 22 17:43:13 EET 2007 > [INFO] Final Memory: 11M/38M > [INFO] > > KR, > Thibaut --
[jira] Created: (MECLIPSE-352) RAD application.xml is not generated with good parameters
RAD application.xml is not generated with good parameters - Key: MECLIPSE-352 URL: http://jira.codehaus.org/browse/MECLIPSE-352 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: RAD support Affects Versions: 2.4 Environment: Windows XP, RAD6, JDK1.4 Reporter: Olivier Chaumont Hi, The application.xml file which is generated by the command mvn eclipse:rad on an EAR maven project is not correct beacuse the schema location is xmlns:schemalocation and not xsi:schemalocation, and so the deploy on WebSphere with RAD6 doesn't work. I found the same bug in the issue MECLIPSE-137 (Developed RAD-6 Plugin Extention) in the comment of Brandon Burk (19/Dec/06 10:40 PM) here: Primary bug fix (that I can remember)... - Rad6ApplicationXMLWriter.java: changed: private static final String XMLNS_SCHEMA_LOCATION = "xmlns:schemaLocation"; to: private static final String XMLNS_SCHEMA_LOCATION = "xsi:schemaLocation"; This issue is fixed but I don't find the modification in 2.4 of the 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] Created: (SUREFIRE-387) Build fails even though all the test passes and no information is provided by surefire
Build fails even though all the test passes and no information is provided by surefire -- Key: SUREFIRE-387 URL: http://jira.codehaus.org/browse/SUREFIRE-387 Project: Maven Surefire Issue Type: Bug Components: plugin Affects Versions: 2.3 Environment: Maven 2.0.7 Surefire 2.3 Reporter: Thibaut Bodart Priority: Minor Hi... My problem is the following: * I run "mvn clean install" * All the tests passes * Surefire says "BUILD FAILURE" and does not provide more information Any idea ? Is there any way of getting more information from surefire. Using -e or -X does not help. See logs below... Results : Tests run: 23, Failures: 0, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] Trace org.apache.maven.BuildFailureException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoFailureException: There are test failures. at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:425) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more [INFO] [INFO] Total time: 1 minute 21 seconds [INFO] Finished at: Thu Nov 22 17:43:13 EET 2007 [INFO] Final Memory: 11M/38M [INFO] KR, Thibaut -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-287) release:prepare does not change the version of parent snapshot
[ http://jira.codehaus.org/browse/MRELEASE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Philippe Steck updated MRELEASE-287: - Attachment: AbstractRewritePomsPhase.java This workaround is ok for me ! > release:prepare does not change the version of parent snapshot > -- > > Key: MRELEASE-287 > URL: http://jira.codehaus.org/browse/MRELEASE-287 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Reporter: Jean-Philippe Steck > Attachments: AbstractRewritePomsPhase.java, release-labo.zip > > > In a project pom.xml, when the parent version is a snapshot : for example : > > groupId > artifcatId > 0.1-SNAPSHOT > > Running "mvn release:prepare" prompt for > 'groupId:artifactId set to release? (yes/no) yes: : > What is the next development version? (0.2-SNAPSHOT) 0.2-SNAPSHOT: : > But then it's still 0.1-SNAPSHOT in the release and in the new developpement > version. > I expected the release version to be : > > groupId > artifcatId > 0.1 > > and the new developpement version : > > groupId > artifcatId > 0.2-SNAPSHOT > > I attached an exemple. > Thanks for any feedback on this. > JP -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1576) Ability to configure access or request logs for Continuum's embedded Jetty
Ability to configure access or request logs for Continuum's embedded Jetty -- Key: CONTINUUM-1576 URL: http://jira.codehaus.org/browse/CONTINUUM-1576 Project: Continuum Issue Type: Improvement Components: Environmental Affects Versions: 1.1-beta-4 Reporter: Wendy Smoak It appears to be possible to configure access logs for Jetty... http://docs.codehaus.org/display/JETTY/Logging+Requests However, the use of embedded Jetty and/or Plexus Appserver prevents this from being done. >From #continuum wsmoak: I need a request log for Continuum (Jetty). (Like httpd access.log) Found this... http://docs.codehaus.org/display/JETTY/Logging+Requests wsmoak: What file does and go in? trygvis: I would assume jetty.xml wsmoak: I don't see a jetty.xml anywhere in 1.1-beta-4 evenisse: we don't have a jetty.xml with embedded jetty evenisse: wsmoak: if you need it, you'll need to modify plexus-appserver wsmoak: evenisse: as in code changes and recompile? I was hoping it's just an xml file buried somewhere... evenisse: a code change is required wsmoak: thanks, knowing that will save time :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-3035) Maven caches missing snapshot dependencies, so further builds fail without checking the repo until the cache expires or -U is included to flush the cache
[ http://jira.codehaus.org/browse/MNG-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114579 ] bguerout edited comment on MNG-3035 at 11/22/07 9:12 AM: --- You haven't define your distribution Management repository as a repository in . Suppose you've got it in your settings.xml I've just tested your script in on windows, all work fine, Bob is very happy lol However, i was looking for an issue like this one because I encounter Snapshot dependencies resolutions errors like you describe : Sometimes, Maven is not able to retrieve new snapshot build from shared remote repository, i'm trying to investigate this point was (Author: bguerout): You haven't define your distribution Management repository as a repository in . Suppose you've got it in your settings.xml I've just tested your script in on windows, all work fine, Bob is very happy lol However, i was looking for an issue like this one because I encounter Snapshot dependencies resolutions like you describe : Sometimes, Maven is not able to retrieve new snapshot build from shared remote repository, i'm trying to investigate this point > Maven caches missing snapshot dependencies, so further builds fail without > checking the repo until the cache expires or -U is included to flush the cache > - > > Key: MNG-3035 > URL: http://jira.codehaus.org/browse/MNG-3035 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Tom Parker >Priority: Minor > Fix For: Reviewed Pending Version Assignment > > Attachments: MNG-3035.zip > > > The problem is caused by a slightly obscure sequence, in this example, I use > two projects, Server & Common. Server depends on Common: > Alice updates Server to depend on Common-1.2-SNAPSHOT instead of 1.1-SNAPSHOT > and commits that change. > Bob syncs that change and attempts a build of Server, maven checks for > Common-1.2-SNAPSHOT in the local repo, finds it missing and checks the global > repo, where it is also missing. Maven records this information in a cache and > fails the build. > Alice deploys Common-1.2-SNAPSHOT to the global repo. > Bob attempts to build Server again, maven checks it's cached information and > finds that Common-1.2-SNAPSHOT wasn't in the global repo last time, so fails > the build. > Maven should not fail the build due to missing dependencies simply because > the cache says the dependency was missing last time. It should check the > configured repos before failing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3299) Failed to resolve artifact.
[ http://jira.codehaus.org/browse/MNG-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed MNG-3299. Resolution: Incomplete Make sure Maven is allowed to connect to the central repository (are you behind an http proxy?) and try it again with -U on the command line. If you are still having trouble, please ask on the user list. You can find subscription info here: http://maven.apache.org/mail-lists.html > Failed to resolve artifact. > > > Key: MNG-3299 > URL: http://jira.codehaus.org/browse/MNG-3299 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.7 >Reporter: vamsikrishna > > Missing: > -- > 1) org.apache.maven.wagon:wagon-webdav:jar:1.0-beta-2 > Try downloading the file manually from the project website. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-3035) Maven caches missing snapshot dependencies, so further builds fail without checking the repo until the cache expires or -U is included to flush the cache
[ http://jira.codehaus.org/browse/MNG-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114579 ] Benoit Guerout commented on MNG-3035: - You haven't define your distribution Management repository as a repository in . Suppose you've got it in your settings.xml I've just tested your script in on windows, all work fine, Bob is very happy lol However, i was looking for an issue like this one because I encounter Snapshot dependencies resolutions like you describe : Sometimes, Maven is not able to retrieve new snapshot build from shared remote repository, i'm trying to investigate this point > Maven caches missing snapshot dependencies, so further builds fail without > checking the repo until the cache expires or -U is included to flush the cache > - > > Key: MNG-3035 > URL: http://jira.codehaus.org/browse/MNG-3035 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Tom Parker >Priority: Minor > Fix For: Reviewed Pending Version Assignment > > Attachments: MNG-3035.zip > > > The problem is caused by a slightly obscure sequence, in this example, I use > two projects, Server & Common. Server depends on Common: > Alice updates Server to depend on Common-1.2-SNAPSHOT instead of 1.1-SNAPSHOT > and commits that change. > Bob syncs that change and attempts a build of Server, maven checks for > Common-1.2-SNAPSHOT in the local repo, finds it missing and checks the global > repo, where it is also missing. Maven records this information in a cache and > fails the build. > Alice deploys Common-1.2-SNAPSHOT to the global repo. > Bob attempts to build Server again, maven checks it's cached information and > finds that Common-1.2-SNAPSHOT wasn't in the global repo last time, so fails > the build. > Maven should not fail the build due to missing dependencies simply because > the cache says the dependency was missing last time. It should check the > configured repos before failing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MECLIPSE-346. Resolution: Fixed Patch adapted and applied with testcase. You can check the snapshot > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution, WTP support >Affects Versions: 2.4 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch, test-project-MECLIPSE-346.zip > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MECLIPSE-346) Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions
[ http://jira.codehaus.org/browse/MECLIPSE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114500 ] aheritier edited comment on MECLIPSE-346 at 11/22/07 7:59 AM: Your solution is quite good, but in theory we shouldn't have to use MavenProject.getDependencies, MavenProject.getArtifacts or MavenProject.getProjectReferences to be sure that we don't ask to maven to resolve itself the dependencies (or we will have some problems, for example to create the eclipse config if the project has some dependencies not yet built). That's why we have some methods like AbstractIdeSupportMojo.doDependencyResolution() I wouldn't break something by using this method was (Author: aheritier): Your solution is quite good, but in theory we should have to use MavenProject.getDependencies, MavenProject.getArtifacts or MavenProject.getProjectReferences to be sure that we don't ask to maven to resolve itself the dependencies (or we will have some problems, for example to create the eclipse config if the project has some dependencies not yet built). That's why we have some methods like AbstractIdeSupportMojo.doDependencyResolution() I wouldn't break something by using this method > Transitive dependencies aren't used to resolve JEE/JSP/EJB/Servlet versions > --- > > Key: MECLIPSE-346 > URL: http://jira.codehaus.org/browse/MECLIPSE-346 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution, WTP support >Affects Versions: 2.4 > Environment: maven-eclipse-plugin-2.5-SNAPSHOT with freshly applied > WTP-2.0 patch >Reporter: Siarhei Dudzin >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: MECLIPSE-346.patch, test-project-MECLIPSE-346.zip > > > After using parent pom settings from test project 34 or 35 ( Revision 595865: > /maven/plugins/trunk/maven-eclipse-plugin/src/test/resources/projects/project-35 > ) > I've generated the project. As a result I had an error "The deployment > descriptor of the module 'jboss-seam-2.0.0.GA.jar' cannot be loaded." (using > jboss seam as an ejb module). After checking facets I've found that the the > ear module had ear version 1.4 in > org.eclipse.wst.common.project.facet.core.xml: > instead of 5.0. > After manually changing the facet version to version="5.0"/> and re-adding the project to the workspace the problem go > resolved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3299) Failed to resolve artifact.
Failed to resolve artifact. Key: MNG-3299 URL: http://jira.codehaus.org/browse/MNG-3299 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.7 Reporter: vamsikrishna Missing: -- 1) org.apache.maven.wagon:wagon-webdav:jar:1.0-beta-2 Try downloading the file manually from the project website. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-112) Allow to configure the filteredExtentions from the archetype.properties file
Allow to configure the filteredExtentions from the archetype.properties file Key: ARCHETYPE-112 URL: http://jira.codehaus.org/browse/ARCHETYPE-112 Project: Maven Archetype Issue Type: Improvement Components: Generator Affects Versions: 2.0-alpha-2 Reporter: nicolas de loof Priority: Minor The project I'm using to generate archetype has HTML that use "#end" as CSS selector. I have to set custom filteredExtentions to avoid this. - Using extension-based file selection is not fine-grained. Using some Ant expression for includes/excludes would be more configurable. - As my project is used to build archetypes, it includes an archetype.properties file in SVN. I'd like include the filteredExtentions in it, but simply adding archetype.filteredExtentions=java,xml,txt,groovy,jsp,gsp,vm,properties has no effect on my issue. It seems using "-Darchetype.filteredExtentions=..." is required. Ability to configure ALL the archetype generation in archetype.properties would be cleaner. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1630) Optional tag in dependencyManagement is not inherited in the children projects
[ http://jira.codehaus.org/browse/MNG-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114571 ] jh commented on MNG-1630: - I'm working with maven version 2.0.7 and am experiencing the same problem as mentioned here. I've defined a dependency as optional in the management part of a parent pom but the child pom doesn't state that dependency as optional. I can verify this with eg the help:effective-pom which shows a difference in the dependencies and dependencyManagement elements (only the latter contains the optional tag). Is this bug popping up again?? > Optional tag in dependencyManagement is not inherited in the children projects > -- > > Key: MNG-1630 > URL: http://jira.codehaus.org/browse/MNG-1630 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Carlos Sanchez >Assignee: John Casey > Fix For: 2.0.1 > > Attachments: it1020.patch, MNG-1630-maven-artifact.patch, > MNG-1630-maven-project.patch > > > If I put this in the parent pom, all the subprojects should inherit the > optional tag (and be able to override it) > > > > cglib > cglib > 2.1_2 > true > > > > it test attached -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-308) Change the method of verifying whether JRE is included in "classpathContainers"
[
http://jira.codehaus.org/browse/MECLIPSE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier closed MECLIPSE-308.
Assignee: Arnaud Heritier
Resolution: Duplicate
Fix Version/s: 2.5
Fixed with MECLIPSE-172
> Change the method of verifying whether JRE is included in
> "classpathContainers"
> ---
>
> Key: MECLIPSE-308
> URL: http://jira.codehaus.org/browse/MECLIPSE-308
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Wish
> Components: dependency resolution
>Affects Versions: 2.4
>Reporter: BABA,Yasuyuki
>Assignee: Arnaud Heritier
> Fix For: 2.5
>
> Attachments: classpathcontainers.patch
>
>
> I want to use specified JRE container in ".classpath" like this.
> {noformat}
> path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/>
> {noformat}
> And added to pom.xml
> {noformat}
>
>
> org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5
>
> {noformat}
> But JRE_CONTAINER node is duplicate in the ".classpath" written by "mvn
> eclipse:eclipse", like this...
> {noformat}
>
> path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/>
> {noformat}
> I want you to change the method of verifying whether JRE is included in
> "classpathContainers".
> See the patche please.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-171) Confluence "quote" macro not recognised
[ http://jira.codehaus.org/browse/DOXIA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-171. --- Assignee: Lukas Theussl Resolution: Fixed Applied, thanks! > Confluence "quote" macro not recognised > --- > > Key: DOXIA-171 > URL: http://jira.codehaus.org/browse/DOXIA-171 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > Attachments: code-patch.txt, DOXIA-171.patch, mylyn-context.zip, > mylyn-context.zip > > > The "quote" and "code" macros in Confluence should do something worthwhile in > Doxia. They seem to only generate errors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MECLIPSE-172) Don't add Default ClasspathContainer if a alternate JRE or a "Execution Environment" is configured as ClasspathContainer.
[ http://jira.codehaus.org/browse/MECLIPSE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114540 ] dashorst edited comment on MECLIPSE-172 at 11/22/07 2:38 AM: - My jdt.launching.prefs file. The best way to get the poms is to check out wicket from trunk: svn co https://svn.apache.org/repos/asf/wicket/trunk you'll get a three layered project layout: /wicket /wicket/jdk-1.4/ /wicket/jdk-1.4/wicket* wicket/jdk-1.5 wicket/jdk-1.5/wicket* the pom file in the jdk-1.4 directory sets the compiler to jdk 1.4 the pom file in the jdk-1.5 directory sets the compiler to jdk 1.5 In the root folder you will also see an eclipse.sh shell file that provides a workaround to this issue. was (Author: dashorst): My jdt.launching.prefs file. The best way to get the poms is to check out wicket from trunk: svn co https://svn.apache.org/repos/asf/wicket/trunk you'll get a three layered project layout: /wicket /wicket/jdk-1.4/ /wicket/jdk-1.4/wicket* wicket/jdk-1.5 wicket/jdk-1.5/wicket* the pom file in the jdk-1.4 directory sets the compiler to jdk 1.4 the pom file in the jdk-1.5 directory sets the compiler to jdk 1.5 > Don't add Default ClasspathContainer if a alternate JRE or a "Execution > Environment" is configured as ClasspathContainer. > - > > Key: MECLIPSE-172 > URL: http://jira.codehaus.org/browse/MECLIPSE-172 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2, 2.3 > Environment: Maven 2.0.4, Eclipse 3.2.1, Windows XP >Reporter: Markus Grieder >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: EclipsePlugin.java.patch, > MECLIPSE-172-fix-and-test.patch, org.eclipse.jdt.launching.prefs, patch.txt > > > If have a Eclipse Workspace with Projects where some use Java 1.5 (Default > JRE) and some Java 1.3 > For 1.3-Projects i have configured the following ClasspathContainer: > > org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre > > This generates in ".classpath": > > path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre"/> > Which is wrong, because the Default JRE is Java 1.5, but the Project should > only see Java 1.3-Libraries and not both. > -> The Default ClasspathContainer should only be added if no JRE_CONTAINER > (alternate JRE or a Execution Environment (>=Eclipse 3.2)) was specified. The > attached Patch replace the "contains"-match with a "starts-with"-match, which > only adds the Default ClasspathContainer if no classpathContainer is > configured which starts with the "JRE_CONTAINER"-Path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MECLIPSE-172) Don't add Default ClasspathContainer if a alternate JRE or a "Execution Environment" is configured as ClasspathContainer.
[ http://jira.codehaus.org/browse/MECLIPSE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114540 ] dashorst edited comment on MECLIPSE-172 at 11/22/07 2:37 AM: - My jdt.launching.prefs file. The best way to get the poms is to check out wicket from trunk: svn co https://svn.apache.org/repos/asf/wicket/trunk you'll get a three layered project layout: /wicket /wicket/jdk-1.4/ /wicket/jdk-1.4/wicket* wicket/jdk-1.5 wicket/jdk-1.5/wicket* the pom file in the jdk-1.4 directory sets the compiler to jdk 1.4 the pom file in the jdk-1.5 directory sets the compiler to jdk 1.5 was (Author: dashorst): My jdt.launching.prefs file > Don't add Default ClasspathContainer if a alternate JRE or a "Execution > Environment" is configured as ClasspathContainer. > - > > Key: MECLIPSE-172 > URL: http://jira.codehaus.org/browse/MECLIPSE-172 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2, 2.3 > Environment: Maven 2.0.4, Eclipse 3.2.1, Windows XP >Reporter: Markus Grieder >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: EclipsePlugin.java.patch, > MECLIPSE-172-fix-and-test.patch, org.eclipse.jdt.launching.prefs, patch.txt > > > If have a Eclipse Workspace with Projects where some use Java 1.5 (Default > JRE) and some Java 1.3 > For 1.3-Projects i have configured the following ClasspathContainer: > > org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre > > This generates in ".classpath": > > path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre"/> > Which is wrong, because the Default JRE is Java 1.5, but the Project should > only see Java 1.3-Libraries and not both. > -> The Default ClasspathContainer should only be added if no JRE_CONTAINER > (alternate JRE or a Execution Environment (>=Eclipse 3.2)) was specified. The > attached Patch replace the "contains"-match with a "starts-with"-match, which > only adds the Default ClasspathContainer if no classpathContainer is > configured which starts with the "JRE_CONTAINER"-Path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-172) Don't add Default ClasspathContainer if a alternate JRE or a "Execution Environment" is configured as ClasspathContainer.
[ http://jira.codehaus.org/browse/MECLIPSE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn Dashorst updated MECLIPSE-172: -- Attachment: org.eclipse.jdt.launching.prefs My jdt.launching.prefs file > Don't add Default ClasspathContainer if a alternate JRE or a "Execution > Environment" is configured as ClasspathContainer. > - > > Key: MECLIPSE-172 > URL: http://jira.codehaus.org/browse/MECLIPSE-172 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2, 2.3 > Environment: Maven 2.0.4, Eclipse 3.2.1, Windows XP >Reporter: Markus Grieder >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: EclipsePlugin.java.patch, > MECLIPSE-172-fix-and-test.patch, org.eclipse.jdt.launching.prefs, patch.txt > > > If have a Eclipse Workspace with Projects where some use Java 1.5 (Default > JRE) and some Java 1.3 > For 1.3-Projects i have configured the following ClasspathContainer: > > org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre > > This generates in ".classpath": > > path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre"/> > Which is wrong, because the Default JRE is Java 1.5, but the Project should > only see Java 1.3-Libraries and not both. > -> The Default ClasspathContainer should only be added if no JRE_CONTAINER > (alternate JRE or a Execution Environment (>=Eclipse 3.2)) was specified. The > attached Patch replace the "contains"-match with a "starts-with"-match, which > only adds the Default ClasspathContainer if no classpathContainer is > configured which starts with the "JRE_CONTAINER"-Path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-172) Don't add Default ClasspathContainer if a alternate JRE or a "Execution Environment" is configured as ClasspathContainer.
[ http://jira.codehaus.org/browse/MECLIPSE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114539 ] Richard van Nieuwenhoven commented on MECLIPSE-172: --- yes thats true, but with MECLIPSE-344 and the workspace location know it not that difficult, just wrote a good working version based on MECLIPSE-344! The only problem is ... test cases because eclipse writes absolute paths in its configuration files, and some of the files are binary. That makes writing a MOCK workspace directory for testing rather difficult. but possible. IMPORTANT: Could you people here send me your ".metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.launching.prefs" files and the maven-compiler-plugin configuration from your pom,xml that way i can write a representative test case. Arnaud: Could you move the WorkspaceConfiguration bean class from the writer.workspace package to the plugin ide package (i do not know how to do that in a patch). This way i can reuse it for a workspace reader! > Don't add Default ClasspathContainer if a alternate JRE or a "Execution > Environment" is configured as ClasspathContainer. > - > > Key: MECLIPSE-172 > URL: http://jira.codehaus.org/browse/MECLIPSE-172 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2, 2.3 > Environment: Maven 2.0.4, Eclipse 3.2.1, Windows XP >Reporter: Markus Grieder >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: EclipsePlugin.java.patch, > MECLIPSE-172-fix-and-test.patch, patch.txt > > > If have a Eclipse Workspace with Projects where some use Java 1.5 (Default > JRE) and some Java 1.3 > For 1.3-Projects i have configured the following ClasspathContainer: > > org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre > > This generates in ".classpath": > > path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre"/> > Which is wrong, because the Default JRE is Java 1.5, but the Project should > only see Java 1.3-Libraries and not both. > -> The Default ClasspathContainer should only be added if no JRE_CONTAINER > (alternate JRE or a Execution Environment (>=Eclipse 3.2)) was specified. The > attached Patch replace the "contains"-match with a "starts-with"-match, which > only adds the Default ClasspathContainer if no classpathContainer is > configured which starts with the "JRE_CONTAINER"-Path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-172) Don't add Default ClasspathContainer if a alternate JRE or a "Execution Environment" is configured as ClasspathContainer.
[ http://jira.codehaus.org/browse/MECLIPSE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MECLIPSE-172. Assignee: Arnaud Heritier Resolution: Fixed Fix Version/s: 2.5 Patch applied. SNAPSHOT deployed. Thanks. > Don't add Default ClasspathContainer if a alternate JRE or a "Execution > Environment" is configured as ClasspathContainer. > - > > Key: MECLIPSE-172 > URL: http://jira.codehaus.org/browse/MECLIPSE-172 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2, 2.3 > Environment: Maven 2.0.4, Eclipse 3.2.1, Windows XP >Reporter: Markus Grieder >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: EclipsePlugin.java.patch, > MECLIPSE-172-fix-and-test.patch, patch.txt > > > If have a Eclipse Workspace with Projects where some use Java 1.5 (Default > JRE) and some Java 1.3 > For 1.3-Projects i have configured the following ClasspathContainer: > > org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre > > This generates in ".classpath": > > path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre"/> > Which is wrong, because the Default JRE is Java 1.5, but the Project should > only see Java 1.3-Libraries and not both. > -> The Default ClasspathContainer should only be added if no JRE_CONTAINER > (alternate JRE or a Execution Environment (>=Eclipse 3.2)) was specified. The > attached Patch replace the "contains"-match with a "starts-with"-match, which > only adds the Default ClasspathContainer if no classpathContainer is > configured which starts with the "JRE_CONTAINER"-Path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
