This diagnosis doesn't seem right.

> And this is the bad news: ' is good for html but bad for
> XML. So, the result file is not well formed. And yes, now
> I tested that this was the real problem, you can do it, too:

This isn't correct. see <http://www.w3.org/TR/REC-xml#sec-predefined-ent>
"All XML processors must recognize these entities whether they are declared or not." (the next sentence - that XML documents should declare them anyway - is intended for interop with legacy SGML processors, the MUST in the first sentence applies to all conforming XML parsers). So the checkstyle xml is ok; the problem must be elsewhere.


Since Maven ships with Xerces, and the only other parser you're likely to be using is Crimson, and both of these handle &amp; correctly, it seems incredibly unlikely that the parser is at fault (though I do remember some talk ages ago about shipping jelly/maven with a 'mini' xml parser?) It seems far more likely to be a bug in whatever is being used as the EntityResolver.

-Baz

[EMAIL PROTECTED] wrote:

The following comment has been added to this issue:

     Author: Incze Lajos
    Created: Sat, 14 Jun 2003 6:26 PM
       Body:
OK. My previous diagnosis was all right (I've caught a real bug),
but the main disease was different. And it's not maven. Studying
the "target/checkstyle-raw-report.xml" which is produced by the
ant:checkstyle target and especially the ant:formatter target
inside, you can find lines like this one:

<error line="87" column="5" severity="error" message="Method &apos;setLanguague&apos; is not designed for extension - needs to be abstract, final or empty." source="com.puppycrawl.tools.checkstyle.checks.DesignForExtensionCheck"/>

And this is the bad news: &apos; is good for html but bad for
XML. So, the result file is not well formed. And yes, now
I tested that this was the real problem, you can do it, too:

1. Run site:generate
2. Edit target/checkstyle-raw-report.xml and chacge all
   "&apos;" to "'".
3. Run xdoc
4. Run site:fsdeploy or site:sshdeploy: and viola: you'll
   get a good checkstyle report.

So we have two issues:
1. maven checkstyle plugin's formatting jsl can't handle the
   ${basedir}/src/java construct in project.xml.
2. ant:checkstyle/ant:formatter produces ill XML.
---------------------------------------------------------------------
View the issue:

http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-489


Here is an overview of the issue: --------------------------------------------------------------------- Key: MAVEN-489 Summary: Checkstyle Error - "Got an exception - java.lang.ClassCastException " Type: New Feature

     Status: Unassigned
   Priority: Major

 Time Spent: Unknown
   Estimate: 0 minutes

Project: maven
Components: plugin-other
Versions:
1.0-beta-10


Assignee: Reporter: Nick Minutello

    Created: Sat, 14 Jun 2003 6:05 AM
    Updated: Sat, 14 Jun 2003 6:05 AM
Environment: JDK1.4.1_01 on Win2K

Description:

I have the latest HEAD build of Maven (built late 13th June GMT) and I am seeing this error 100s of times over in the checkstyle report.


Error Line Got an exception - java.lang.ClassCastException 0



Mailing list conversations:


On Fri, Jun 13, 2003 at 04:40:44PM +0800, Willie Vu wrote:

Vincent,

After I changed antlr plugin to use 2.7.2, I run into this problem:

XXX.java: 0: Got an exception - java.lang.ClassCastException

What is the problem?

Willie



I think, I've ran into the same problem - and nothing to do with the new checkstyle jar in my case. You cab check this by looking at the checkstyle reports in target - they are all right at me.

The problem is that in my project.xml I'm using the

<sourceDirectory>${basedir}/src/java</sourceDirectory>

convention, and in the checkstyle jsl, that formats the raw checkstyle
report expects the sourceDirectory as a ${baseDir} relative value (line 56):

<j:set var="fullSrcDir" value="${basedir}/${pom.build.sourceDirectory}"/>


And the whole jsl processing is went wrog from this, as the  transformer
would be working with a ${basedir}/ ${basedir}/<basedir_relative_filename>
from here. Sometimes it causes exception, sometimes simply wrong.

A dirty/quick cure to modify project.xml not to use ${basedir} (altough
if you use reactor you may get troubles with that). I'm thinking how to
patch the jsl script, just wrote this, maybe more knowledgeable jelliers
are faster at fix than I am.

incze



However, my Project.xml uses relative "src/java" and I still have the same problem.





--------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]




Privacy and Confidentiality Notice


------------------------------------------------

The information contained in this E-Mail message is intended only for the person or persons to whom it is addressed. Such information is confidential and privileged and no mistake in transmission is intended to waive or compromise such privilege. If you have received it in error, please destroy it and notify us on the telephone number printed above. If you do not receive complete and legible copies, please telephone us immediately. Any opinions expressed herein including attachments are those of the author only. i-documentsystems Ltd. does not accept responsibility for the accuracy or completeness of the information provided or for any changes to this Email, however made, after it was sent. (Please note that it is your responsibility to scan this message for viruses).


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to