[jira] Updated: (UIMA-371) XMI serialization to UIMA C++
[ https://issues.apache.org/jira/browse/UIMA-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhavani Iyer updated UIMA-371: -- Attachment: uimacpp-xmi.patch Previous patch was not ignoring line ends > XMI serialization to UIMA C++ > - > > Key: UIMA-371 > URL: https://issues.apache.org/jira/browse/UIMA-371 > Project: UIMA > Issue Type: New Feature > Components: C++ Framework >Reporter: Eddie Epstein > Assigned To: Eddie Epstein > Fix For: 2.2 > > Attachments: uimacpp-xmi.patch, uimacpp_xmi.patch, uimacpp_xmi.patch, > uimacpp_xmi.zip > > > In order to comply to the UIMA standard for CAS data, Bhavani Iyer has been > working on XMI serialization support for UIMA C++. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Default Result Specifications too complicated?
On 4/18/07, Michael Baessler <[EMAIL PROTECTED]> wrote: OK, but can the FlowController manipulate the ResultSpec for an annotator before it is called? Or can the FlowController just decide the flow of the engines (if they are called, which order ...) If the FlowController does not manipulate the ResultSpec where else can it be done, only in the application that calls the main engine? No, the FlowController can't manipulate result specs. This was a design choice when we exposed the FlowController in 2.0. ResultSpecifications are now independent of flow order. An application can override the ResultSpecification of the topmost aggregate, to specify that a subset of the topmost aggregate's outputs are actually desired. Then this trickles down to the delegates' ResultSpecs. I still think that it is necessary to have a way to specify what output types an annotator should produce. And it is not efficient that an annotator always produce anything that's possible. OK. I think what we're leaning towards doing here is just providing some better checking/tracing for result specs so that it is easier to debug problems with them. -Adam
Re: UIMACpp status
Have just tested with mscv 8, and the svn image builds and tests there ok too, after fixing one test case which had a bad component descriptor. Any idea why when msvc8 migrates test.sln, it disables the build for several components? Regards, Eddie
Re: Default Result Specifications too complicated?
Adam Lally wrote: This changed in 2.0 with the introduction of the flow controller. The ResultSpec no longer has any dependence on the flow. The framework assumes the most general case of the custom flow controller. The effect is that an annotator's ResultSpec will include all of the input types of *any* component in the same aggregate, even if that component happens to run before the annotator, not after it. We decide that this is such a strange case that it wasn't worth worrying about. OK, but can the FlowController manipulate the ResultSpec for an annotator before it is called? Or can the FlowController just decide the flow of the engines (if they are called, which order ...) If the FlowController does not manipulate the ResultSpec where else can it be done, only in the application that calls the main engine? The default result spec is not "all they can". A type is only included in an annotator's default result spec if one of the following is true: (a) The type is listed in the outputs of all containing aggregates (so it's concluded that the type is a final output of the whole aggregate which the application may inspect) (b) The type is listed in the inputs of some other component of the aggregate (so it's concluded that the type may be a necessary intermediate type that some other annotator may inspect in order to produce output that's of interest to the application) As I recall, you (Michael) and/or Thilo felt that a default result spec of "all they can" was not appropriate, and that it was a necessary feature to restrict the outputs of an annotator based on the declared outputs of an enclosing aggregate. In any case this was always done in the capability language flow in previous versions of UIMA, but in 2.0 was generalized to be independent of flow. I still think that it is necessary to have a way to specify what output types an annotator should produce. And it is not efficient that an annotator always produce anything that's possible. I will look into the code to get a better understanding how this stuff works in UIMA 2.1. -- Michael
[jira] Updated: (UIMA-371) XMI serialization to UIMA C++
[ https://issues.apache.org/jira/browse/UIMA-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhavani Iyer updated UIMA-371: -- Attachment: uimacpp_xmi.patch Fix default behavior for unknown xml elements and attributes to be compatible with Java implementation. Unknown elements and attributes are handled as out of typesystem data only if a handle to the XmiSerializationSharedData is passed in to the call to deserialize. > XMI serialization to UIMA C++ > - > > Key: UIMA-371 > URL: https://issues.apache.org/jira/browse/UIMA-371 > Project: UIMA > Issue Type: New Feature > Components: C++ Framework >Reporter: Eddie Epstein > Assigned To: Eddie Epstein > Fix For: 2.2 > > Attachments: uimacpp_xmi.patch, uimacpp_xmi.patch, uimacpp_xmi.zip > > > In order to comply to the UIMA standard for CAS data, Bhavani Iyer has been > working on XMI serialization support for UIMA C++. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (UIMA-377) add API to build PEAR packages
Michael Baessler (JIRA) wrote: add API to build PEAR packages -- Key: UIMA-377 URL: https://issues.apache.org/jira/browse/UIMA-377 Project: UIMA Issue Type: New Feature Components: Core Java Framework Reporter: Michael Baessler Assigned To: Michael Baessler Priority: Minor Fix For: 2.2 Currently pear packages can only be created when having the PearPackager plugin installed. I would like to add a pear packager API to create pear files without using the pearPackager eclipse plugin. Also I plan to create an ANT task to build pear packages directly in the build. I choose ANT since I think it is more common. We can run it in our Maven build and annotator developers can run it in their build as well even when they don't use Maven I just want to get some other opinion about where to check-in the Java class for the ANT task. The class has a dependency on uima_core and to an ANT jar. What do you think... 1) add it to the uima_core project where all the other pear stuff is checked-in 2) add it to a new project in the sandbox -- Michael
[jira] Created: (UIMA-377) add API to build PEAR packages
add API to build PEAR packages -- Key: UIMA-377 URL: https://issues.apache.org/jira/browse/UIMA-377 Project: UIMA Issue Type: New Feature Components: Core Java Framework Reporter: Michael Baessler Assigned To: Michael Baessler Priority: Minor Fix For: 2.2 Currently pear packages can only be created when having the PearPackager plugin installed. I would like to add a pear packager API to create pear files without using the pearPackager eclipse plugin. Also I plan to create an ANT task to build pear packages directly in the build. I choose ANT since I think it is more common. We can run it in our Maven build and annotator developers can run it in their build as well even when they don't use Maven. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: UIMACpp status
Frank, Glad you were able to build ok. And it sounds like you had no problems creating the SDK tree using buildsdk.cmd. Everything is working for me with vc7. I've just updated the README files in svn. Can you please try running the test suite based on the instructions there? Thanks, Eddie On 4/17/07, LeHouillier, Frank D. <[EMAIL PROTECTED]> wrote: What is the status of UIMACpp? It came up on the user list so I finally tried to compile the trunk version. Compiling and everything seemed straightforward but when I ran the DaveDetector sample analysis engine I got the following error: runAECpp.exe C:\UIMA\apache-uima\uimacpp\examples\descriptors\DaveDetector.xml C:\UIMA\apache-uima\examples\data runAECpp: Error string : UIMA_ERR_ENGINE_WINDOWS_EXCEPTION UIMACPP Error info: Error number : 50021 Recoverable : No Error : Windows exception "ACCESS VIOLATION" I am working in Windows XP, using Visual 8 and uimacpp/trunk revision 529758. Is this something that I have done wrong with my setup or is it a bug, and how can I help fix it if it is? Frank
