History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: CCNET-1197
Type: Improvement Improvement
Status: Open Open
Priority: Minor Minor
Assignee: Unassigned
Reporter: Ross Patterson
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
CruiseControl .NET

<merge> task should support non-XML files cleanly

Created: 21/Jul/08 11:35 AM   Updated: 14/Oct/08 05:08 AM
Component/s: Builder
Affects Version/s: 1.4
Fix Version/s: None

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown
File Attachments: 1. Text File ccnet-1197.patch (14 kb)



 Description  « Hide
pesso <codesolutions@yahoo.com> reported on 2008-07-21 to the ccnet-user mailing list:


After adding <merge><files><file>c:\cygwin\bin\build.log</file></
files></merge> in the publishers block, I'm getting the following
exception at the end of a build. Does any one know what might be causing it? How would I fix it?

[ITU:DEBUG] Exception: System.Xml.XmlException: Name cannot begin with the '>' character, hexadecima l value 0x3E. Line 85, position 124.
   at System.Xml.XmlTextReaderImpl.Throw(Exception e)
   at System.Xml.XmlTextReaderImpl.Throw(String res, String[] args)
   at System.Xml.XmlTextReaderImpl.Throw(Int32 pos, String res, String[] args)
   at System.Xml.XmlTextReaderImpl.ParseQName(Boolean isQName, Int32 startOffset, Int32& colonPos)
   at System.Xml.XmlTextReaderImpl.ParseElement()
   at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
   at System.Xml.XmlTextReaderImpl.Read()
   at System.Xml.XmlWriter.WriteNode(XmlReader reader, Boolean
defattr)
   at
ThoughtWorks.CruiseControl.Core.Util.XmlFragmentWriter.WriteNode(XmlReader
reader, Boolean def
attr)
   at
ThoughtWorks.CruiseControl.Core.Util.XmlFragmentWriter.WriteNode(String
xml)
[ITU:INFO] Integration complete: Failure - 7/16/2008 2:53:08 PM

My publishers block looks like this:
    <publishers>
<merge><files><file>c:\cygwin\bin\build.log</file></files></merge>
          <xmllogger logDir="D:\Output\buildlogs" />
          <email from="xyz@abc.com" mailhost="xyz.local"
includeDetails="TRUE">


 All   Comments   Work Log   Change History      Sort Order:
Ross Patterson [21/Jul/08 11:36 AM]
I responded to the ccnet-user mailing list on 2008-07-21:

pesso writes:
>[ITU:DEBUG] Exception: System.Xml.XmlException: Name cannot begin with
>the '>' character, hexadecimal value 0x3E. Line 85, position 124.

That message should have been preceded by a message telling you that the data was being written to the build log anyway ("Supplied output is not valid xml. Writing as CDATA"), and it should be there. What you've discovered the hard way is that files processed by the <merge> task must be in proper XML format. The documentation doesn't say that, so I'll correct it.

Ross Patterson [21/Jul/08 11:38 AM]
We should consider explicitly supporting non-XML files in the <merge> task, rather than treating them as an error case. Perhaps we should add an 'xml="true|false"' attribute to the <file> element, defaulting to "true" to match current behavior. If xml="false", CCNET would treat the file as CDATA just as it does now, but without all the ugly writing to the log file and the exception.

Ross Patterson [15/Aug/08 10:46 PM]
I have a working version of this, but it causes a breaking change in the CCNET configuration. The current syntax of "<file>... fileid pattern ...</file>" can't easily be modified to "<file isXml='false'> ...", at least not that I can find. For the time being, the version I have working replaces:

   <file>... fileid pattern ...</file>

with

   <file name="...fileid pattern ..." isXml="true|false"/>

I'm still looking for ways to make the configuration compatible.

Ross Patterson [14/Oct/08 04:48 AM]
I'm returning this issue to the unassigned pool. I no longer have any CCNET systems to work with.

Ross Patterson [14/Oct/08 05:08 AM]
I've attached my working version as ccnet-1197.patch. It was up-to-date as of a few weeks ago, and worked well except for the configuration effect I noted above.