simpler XMI writing than XWriter

[GoogleCodeExporter]

The whole FileNamer thing in XWriter is more complexity than most users need. 
You have to declare a new FileNamer class every time you create an XWriter. But 
that FileNamer class, even though it takes a JCas just like an annotator would, 
isn't actually an annotator, it's a totally different API.

We should instead leverage our users' existing understanding of the annotator 
API. If they're going to have to write a new class every time, we should let 
them write an annotator class like they're already used to. We should provide a 
simple static method that makes it easy to write such a class, something like:

public class XUtil {
    public static void writeXMI(JCas jCas, File outputFile) throws IOException, SAXException {
        FileOutputStream outputStream = new FileOutputStream(outputFile);
        try {
            ContentHandler handler = new XMLSerializer(outputStream).getContentHandler();
            XmiCasSerializer serializer = new XmiCasSerializer(jCas.getTypeSystem());
            serializer.serialize(jCas.getCas(), handler);
        }
        finally {
            outputStream.close();
        }
    }
}

(The new XUtil class could also grow methods for writing XCAS, and for reading 
XMI and XCAS.)

Original issue reported on code.google.com by steven.b...@gmail.com on 3 May 2012 at 10:14

[GoogleCodeExporter]

I'd also vote for removing the XWriter stuff from uimaFIT or at most keep it as 
a class used in tests. I think its a good policy for uimaFIT not to include any 
actual readers, writers or AEs.

I'd prefer placing such methods in CasUtil and/or JCasUtil. 

Original comment by richard.eckart on 3 May 2012 at 10:26

[GoogleCodeExporter]

Putting the method(s) in CasUtil and JCasUtil sounds reasonable to me.

And +1 on deprecating and removing XWriter.

Original comment by steven.b...@gmail.com on 3 May 2012 at 11:13

[GoogleCodeExporter]

I disagree.  The reason I put XWriter into uimaFIT is because it is very useful 
for testing (the 'T' in 'FIT').  This is explained in the #WritingTests wiki 
page and illustrated with a detailed example in XmiTest.  

I agree that we should not clutter uimaFIT with utility code in the form of 
various readers and writers - but since this one has a specific purpose to 
support testing I think it belongs in uimaFIT.  

That said, I can see Steve's point about the complexity of the FileNamer and I 
like the simplified static method given above.  Esp. given the narrow purpose 
of the use case (i.e. creating xmi files to go in src/test/resources) directory 
it doesn't seem we need the FileNamer abstraction.  

Original comment by philip.o...@oracle.com on 8 May 2012 at 9:48

[GoogleCodeExporter]

Philip has a point here. While I personally never used the XWriter in my test 
cases (I prefer the CasDumpWriter), some people might prefer it. And having a 
writer UIMA component that handles multiple CASes in a test pipeline is 
certainly better than manually writing stuff to disk using static utility 
methods.

Original comment by richard.eckart on 8 May 2012 at 10:10

[GoogleCodeExporter]

Original comment by richard.eckart on 7 Jan 2013 at 4:51

• Added labels: ASFJira-No

[GoogleCodeExporter]

This issue has been moved to ASF: 
https://issues.apache.org/jira/browse/UIMA-3219

Original comment by richard.eckart on 25 Aug 2013 at 8:22

• Added labels: ASFJira-Yes
• Removed labels: ASFJira-No

[GoogleCodeExporter]

Issue 122 has been merged into this issue.

Original comment by richard.eckart on 25 Aug 2013 at 8:23

[GoogleCodeExporter]

Original comment by richard.eckart on 25 Aug 2013 at 9:43

• Changed state: Fixed
• Added labels: Compatible-No