[jira] Commented: (MNG-4001) Unable to resolve Dashboard mojo from Central
[
http://jira.codehaus.org/browse/MNG-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215872#action_215872
]
Klaus Brunner commented on MNG-4001:
This issue needs to be re-opened. It's still there with the most recent release
of Maven (2.2.1), and it's unclear why it first is confirmed as a bug and then
simply labeled "not a bug" without further comment.
> Unable to resolve Dashboard mojo from Central
> -
>
> Key: MNG-4001
> URL: http://jira.codehaus.org/browse/MNG-4001
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Sites & Reporting
>Affects Versions: 2.0.9
> Environment: Windows, JDK 1.6
>Reporter: Anthony Whitford
>Assignee: Brett Porter
> Attachments: dashbug.zip
>
>
> I have a simple test project that declares the dashboard-maven-plugin (see
> http://mojo.codehaus.org/dashboard-maven-plugin/usage.html ).
> Note that the usage does explicitly state that the Codehaus repository must
> be specified as a plugin repository...
> However, according to:
> http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html
> I'm pretty sure that Maven should be able to resolve the
> dashboard-maven-plugin from the central repo.
> I validated that the [dashboard-maven-plugin residing in
> central|http://repo1.maven.org/maven2/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/]
> is indeed the same artifact as that which lives at the [codehaus
> repository|http://repository.codehaus.org/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/].
> But as you can see from my attached test case, the codehaus mojo is NOT being
> resolved without the special plugin repository defined. When running
> {noformat}mvn dashboard:dashboard{noformat}, I get the following error
> message:
> {noformat}
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'dashboard'.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] The plugin 'org.apache.maven.plugins:maven-dashboard-plugin' does not
> exist or no valid version could be found
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: < 1 second
> [INFO] Finished at: Sat Jan 24 12:40:55 PST 2009
> [INFO] Final Memory: 1M/254M
> [INFO]
> {noformat}
> If you edit the pom.xml to uncomment out the plugin repository declaration
> for codehaus, it works as one would expect.
> My understanding is that the only reason why the Dashboard Usage mentions
> their plugin repository is because the artifact was not available on the
> central repository -- but it certainly is today.
> I also thought that perhaps the maven-metadata.xml might be incorrect
> (perhaps the dashboard plugin prefix is missing or different). I checked:
> * http://repo1.maven.org/maven2/org/codehaus/mojo/maven-metadata.xml
> * http://repository.codehaus.org/org/codehaus/mojo/maven-metadata.xml
> and they both look OK to me... I clearly see:{code:xml}
>
> Maven Dashboard Report Plugin
> dashboard
> dashboard-maven-plugin
>
> {code}
> And I don't see any plugin with a dashboard prefix specified as an Apache
> Maven Plugin here:
> * http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml
> If I explicitly specify the dashboard plugin like: {noformat}mvn
> org.codehaus.mojo:dashboard-maven-plugin:dashboard{noformat}
> that works...
> Overall, I am recording a bug because the
> [documentation|http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html]
> states:{quote}
> Maven will always search the following groupId's after searching any plugin
> groups specified in the user's settings:
> * org.apache.maven.plugins
> * org.codehaus.mojo
> {quote}
> I don't see this being done.
> Finally, I even tried adding a {{pluginGroups}} to my
> {{settings.xml}}:{code:xml}
>
> org.codehaus.mojo
>
> {code}
> But that did not work either...
--
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-424) Provide a way of setting password for ext connections using internal ssh code
Provide a way of setting password for ext connections using internal ssh code - Key: SCM-424 URL: http://jira.codehaus.org/browse/SCM-424 Project: Maven SCM Issue Type: New Feature Components: maven-scm-provider-cvs Environment: Any Reporter: Klaus Brunner ExtConnection apparently has all the necessary stuff in place to initiate an "ext using ssh" connection on its own, without an external ssh command. However, there seems to be no way of setting the password for such connections: ext URLs are fixed to 4 tokens so you can set a username, but not a password (see AbstractCvsScmProvider - not misleading message that there are "too few tokens" when in fact there may be too many). It's also not retrieved from a system property or such - so it's always "password is null", whatever you do. Suggestion: try to get the SSH password from a System property. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-132) extssh connection method not shown
[ http://jira.codehaus.org/browse/SCM-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152264#action_152264 ] Klaus Brunner commented on SCM-132: --- "extssh" is simply Eclipse's way of saying "ext using ssh as the external rsh". As far as I understand the Maven SCM code, using "ext" actually defaults to trying an ssh connection anyway: see CvsConnection.connect() and the ExtConnection class which uses a Java ssh library when no rsh is explicitly set. So ext is extssh in fact, unless CVS_RSH is set to point to something else. What's annoying is that there is apparently no way of setting the password (an SCM url with "ext" doesn't allow adding the password, and it seems it's not retrieved any other way). > extssh connection method not shown > -- > > Key: SCM-132 > URL: http://jira.codehaus.org/browse/SCM-132 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-cvs > Environment: Windows 2000; Java 1.4 JDK, Maven 2.01 maven-scm-plugin > 1.0-alpha-2 >Reporter: Todd Nine > Fix For: future > > > When attemping to perform a release from a project checked out from eclipse I > receive the following error. > [INFO] [release:prepare] > [INFO] Verifying there are no local modifications ... > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error is occurred in the status process. > Embedded error: Error! > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred > in the status process. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:216) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > 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:249) > 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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: An error is > occurred in the status process. > at > org.apache.maven.plugins.release.PrepareReleaseMojo.checkForLocalModifications(PrepareReleaseMojo.java:514) > at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:201) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) > ... 16 more > Caused by: org.apache.maven.scm.ScmException: Error! > at > org.apache.maven.plugins.release.helpers.ScmHelper.checkResult(ScmHelper.java:124) > at > org.apache.maven.plugins.release.helpers.ScmHelper.getStatus(ScmHelper.java:175) > at > org.apache.maven.plugins.release.PrepareReleaseMojo.checkForLocalModifications(PrepareReleaseMojo.java:510) > ... 19 more > Since Eclipse is a commonly used IDE, is it possible to add the extssh > connection parameter. Below is my scm from my pom.xml > > scm:cvs:ext:[EMAIL > PROTECTED]:/a01/proj/CVS:webservices/ServiceProviders > scm:cvs:ext:[EMAIL > PROTECTED]:/a01/proj/CVS:webservices/ServiceProviders > HEAD > > http://empt.ata.com/cgi-bin/cvsweb.cgi/webservices/ServiceProviders/?cvsroot=ATA.com-Development > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.or
[jira] Created: (MPIR-131) NPE in printArtifactsLocations() for blacklisted repo
NPE in printArtifactsLocations() for blacklisted repo - Key: MPIR-131 URL: http://jira.codehaus.org/browse/MPIR-131 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: dependencies Affects Versions: 2.1 Environment: Linux (Sun JDK 1.6), Windows (IBM VM 1.4). No direct Internet access; going through local Artifactory repository. Reporter: Klaus Brunner Priority: Critical I'm getting NPEs when running the reports plugin at this location: [INFO] Generating "Dependencies" report. [WARNING] The repository url 'http://repo1.maven.org/maven2' is invalid - Repository 'central' will be blacklisted. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printArtifactsLocations(DependenciesRenderer.java:1182) at org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyRepositoryLocations(DependenciesRenderer.java:641) at org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:274) at org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) at org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:239) Taking a brief look with the debugger, it appears that the totalByRepo map in DependenciesRenderer.printArtifactsLocations() is empty - so looking up any entry will of course return null and result in an NPE here: totalRow[idnum++] = totalByRepo.get( repokey ).toString(); Note that this used to work fine before the 2.1 release. -- 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-109) .component wb-resource source path incorrect for ear packaging
[
http://jira.codehaus.org/browse/MECLIPSE-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=137475#action_137475
]
Klaus Brunner commented on MECLIPSE-109:
This fix actually breaks EARs for me (using IBM RAD 7.0.0.4 with WTP 1.5). The
application.xml editor refuses to start with a cryptic error, and the modules
are not shown in the tree view. Changing it back to "/" makes things work fine
again.
So at least it should be configurable instead of hard-coded as it is now.
> .component wb-resource source path incorrect for ear packaging
> --
>
> Key: MECLIPSE-109
> URL: http://jira.codehaus.org/browse/MECLIPSE-109
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: WTP support
>Affects Versions: 2.2
>Reporter: Stuart Bargon
>Assignee: Arnaud Heritier
>Priority: Critical
> Fix For: 2.4
>
>
> Currently for ear packaging the wb-resource element in the .component file
> set the path to "/". This should be set to the earSourceDirectory which is by
> deafult ${basedir}/src/main/application.
--
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-262) Maven compilation and eclipse classpath don't match with conflicting versions at same dependency depth
[ http://jira.codehaus.org/browse/MECLIPSE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Klaus Brunner updated MECLIPSE-262: --- Attachment: screenshot-1.jpg version conflict between eclipse and maven build (WAR project) > Maven compilation and eclipse classpath don't match with conflicting versions > at same dependency depth > -- > > Key: MECLIPSE-262 > URL: http://jira.codehaus.org/browse/MECLIPSE-262 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution >Affects Versions: 2.3 > Environment: Maven 2.0.6, 2.0.4 >Reporter: Carlos Sanchez > Attachments: compile.txt, eclipse.txt, screenshot-1.jpg, testcase.zip > > > https://svn.apache.org/repos/asf/maven/components/trunk/maven-core rev# 533182 > compile uses plexus-component-api-1.0-alpha-24 (the right one) > eclipse:eclipse uses plexus-component-api-1.0-alpha-16 -- 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-262) Maven compilation and eclipse classpath don't match with conflicting versions at same dependency depth
[ http://jira.codehaus.org/browse/MECLIPSE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98868 ] Klaus Brunner commented on MECLIPSE-262: I'm apparently having the same problem. I wrote this up for opening a new bug report, but I'll attach it anyway in case it helps: Find attached a sample WAR project (testcase.zip) that lists commons-configuration and commons-jxpath as dependencies. Both of these artifacts depend (directly or transitively) on commons-collections, although there is a version conflict: c-configuration requires c-collections 3.2, but c-jxpath requires c-collections 2.0. Running "mvn clean eclipse:eclipse package" has the following effect: 1) The Eclipse classpath includes commons-collections-3.2.jar 2) The Maven-built WAR archive in the target folder includes commons-collections-2.0.jar (WEB-INF/lib). Also seen on attached screenshot. In this specific case, the result is that everything works fine in Eclipse, but when the Maven-built WAR is deployed, it fails because c-collections 3.2 is definitely required at runtime. Not good. > Maven compilation and eclipse classpath don't match with conflicting versions > at same dependency depth > -- > > Key: MECLIPSE-262 > URL: http://jira.codehaus.org/browse/MECLIPSE-262 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution >Affects Versions: 2.3 > Environment: Maven 2.0.6, 2.0.4 >Reporter: Carlos Sanchez > Attachments: compile.txt, eclipse.txt, testcase.zip > > > https://svn.apache.org/repos/asf/maven/components/trunk/maven-core rev# 533182 > compile uses plexus-component-api-1.0-alpha-24 (the right one) > eclipse:eclipse uses plexus-component-api-1.0-alpha-16 -- 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-262) Maven compilation and eclipse classpath don't match with conflicting versions at same dependency depth
[ http://jira.codehaus.org/browse/MECLIPSE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Klaus Brunner updated MECLIPSE-262: --- Attachment: testcase.zip Test case (WAR project). > Maven compilation and eclipse classpath don't match with conflicting versions > at same dependency depth > -- > > Key: MECLIPSE-262 > URL: http://jira.codehaus.org/browse/MECLIPSE-262 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution >Affects Versions: 2.3 > Environment: Maven 2.0.6, 2.0.4 >Reporter: Carlos Sanchez > Attachments: compile.txt, eclipse.txt, testcase.zip > > > https://svn.apache.org/repos/asf/maven/components/trunk/maven-core rev# 533182 > compile uses plexus-component-api-1.0-alpha-24 (the right one) > eclipse:eclipse uses plexus-component-api-1.0-alpha-16 -- 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-2921) ejb-client dependency no longer working
[ http://jira.codehaus.org/browse/MNG-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92726 ] Klaus Brunner commented on MNG-2921: I don't know about the 'community', but I've certainly noticed it as well. This is a major problem for us and I hope it's fixed very quickly. > ejb-client dependency no longer working > --- > > Key: MNG-2921 > URL: http://jira.codehaus.org/browse/MNG-2921 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: Fedora Core 6 >Reporter: Frank Cornelis >Priority: Blocker > Attachments: test.zip > > > When running 'mvn clean install' on the test project (see attachment) under > Maven 2.0.5 every builds as expected. On Maven 2.0.6 it no longer compiles. > On Maven 2.0.5 I get in the log: > [DEBUG] be.frankcornelis.maven:client:jar:1.0-SNAPSHOT (selected for null) > [DEBUG] be.frankcornelis.maven:model:ejb-client:client:1.0-SNAPSHOT:compile > (selected for compile) > Under Maven 2.0.6 I get: > [DEBUG] be.frankcornelis.maven:client:jar:1.0-SNAPSHOT (selected for null) > [DEBUG] be.frankcornelis.maven:model:ejb-client:client:1.0-SNAPSHOT > (selected for null) > and an error message saying it cannot find the required interfaces defined in > Model. > When I remove type:ejb-client in the Client pom.xml it compiles again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-198) Maven Relese taggs with version number, but dots are not supported in CVS
[ http://jira.codehaus.org/browse/MRELEASE-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90275 ] Klaus Brunner commented on MRELEASE-198: This is a quite annoying bug. Apparently somebody has provided a patch a while ago (see duplicate MRELEASE-110), but there's no new release of the plugin yet. > Maven Relese taggs with version number, but dots are not supported in CVS > - > > Key: MRELEASE-198 > URL: http://jira.codehaus.org/browse/MRELEASE-198 > Project: Maven 2.x Release Plugin > Issue Type: Wish >Affects Versions: 2.0-beta-4 > Environment: Linux >Reporter: Max Berger >Priority: Minor > > Dear developers, > I was trying to release a project that was stored in CVS and had the version > 2.9.3. The release-plugin tried to tag the release using that version and > failed terribly, I had to manually set the tag to 2-9-3. > It would be nice if the plugin could avoid illegal tag names. > as the project has been moved to svn this is no longer an issue for me, but > the general issue remains. > Max -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-242) RAD goal: missing lib-modules in .websettings
RAD goal: missing lib-modules in .websettings - Key: MECLIPSE-242 URL: http://jira.codehaus.org/browse/MECLIPSE-242 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.3, 2.4 Environment: IBM Rational Application Developer 6.0.x Reporter: Klaus Brunner Attachments: RadWebSettingsWriter.java The eclipse:rad goal does not currently write the lib-modules element of the .websettings file. When developing with RAD and WAS, this results in dependent projects' code not being packaged and deployed as part of the WAR by the RAD build and deploy process. This applies to project dependencies only. Adapted version of RadWebSettingsWriter.java is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-237) unsafe EclipseSourceDir.equals() method
unsafe EclipseSourceDir.equals() method
---
Key: MECLIPSE-237
URL: http://jira.codehaus.org/browse/MECLIPSE-237
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.4
Reporter: Klaus Brunner
Priority: Trivial
EclipseSourceDir.equals(Object o) does not check the passed object for null or
incompatible class, which may cause NPEs and ClassCastExceptions.
Fix suggestion:
public boolean equals( Object obj )
{
return (obj != null) && (obj instanceof EclipseSourceDir) &&
this.path.equals( ( (EclipseSourceDir) obj ).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: (SUREFIRE-52) XML Reports include testcases from previous tests
[ http://jira.codehaus.org/browse/SUREFIRE-52?page=comments#action_81521 ]
Klaus Brunner commented on SUREFIRE-52:
---
My workaround is to use always in the surefire plugin
config of the POM. Slows things down a bit, but at least the reports are
coherent.
> XML Reports include testcases from previous tests
> -
>
> Key: SUREFIRE-52
> URL: http://jira.codehaus.org/browse/SUREFIRE-52
> Project: surefire
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: bin zhu
>Priority: Minor
> Fix For: 2.1
>
> Attachments: patch.txt
>
>
> to reproduce
> 1. create the following JUnit tests:
> public class TestA extends TestCase {
>public void test1() {
>}
> }
> public class TestB extends TestCase {
>public void test2() {
> }
> 2. run 'mvn clean install'
> note that in TEST-TestB.xml includes testcase results from test1 and test2,
> even though TestB only has test2()
> name="TestB">
> ...
>
>
>
--
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-57) Invalid characters in XML reports
Invalid characters in XML reports
-
Key: SUREFIRE-57
URL: http://jira.codehaus.org/browse/SUREFIRE-57
Project: surefire
Issue Type: Bug
Components: JUnit 3.x support
Reporter: Klaus Brunner
Priority: Critical
Surefire (or possibly Xpp3Dom?) should check for invalid characters in JUnit
output and escape or mask them to ensure valid XML reports. This applies to all
characters outside the allowed range defined in the XML spec
(http://www.w3.org/TR/REC-xml/#NT-Char).
I have a JUnit test case that uses assertEquals on strings. In some situations,
the string to compare against the reference may be completely garbled and
contain things such as null characters, which then show up in the assertion
failure message ("expected X but was Y") and consequently in the XML reports.
Here's a simple test case to trigger the problem:
public class InvalidCharactersTest extends TestCase {
public void testStrings() {
String expected = "abc";
String actual = "abc" + '\u';
assertEquals(expected, actual);
}
}
The resulting Surefire XML report contains the null character as is and is
therefore not valid XML. Running the Surefire Reports plugin then fails with a
parsing error.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
