Thanks. I ended up just putting this into the main uimaj-core project (otherwise it's difficult to get the tests to work with out having identical copies of test support code in multiple projects).
I made up a new category of types: "semi-built-ins". These are types where the implementation is provided in the uimaj-core, but the type definition is not built-in. I added a type system descriptor which defines these three types, and put it in uimaj-core as a resource named org.apache.uima.semibuiltins. If your Java project wants to use these types, you can use the component descriptor editor to add an "import" in the type description panel, select import by name, and pick this name from the list. This is documented in the v3 users guide. -Marshall On 1/23/2017 2:14 AM, Peter Klügl wrote: > Sounds like a good idea. > > > Peter > > > Am 20.01.2017 um 17:17 schrieb Marshall Schor: >> Hi, >> >> I now believe that having the 3 new built-in types as "built-in" is a >> mistake; >> it causes some difficulties for serialization, deserialization, C++ >> interoperability, etc. when running a V3 pipeline with v2 (remote) components >> because the type systems differ, and this is a problem when they must "match" >> (for some binary serializations). >> >> So, I'm thinking a better design is to remove the "built-in" nature of the 3 >> new >> types, and just have them be normal ones, that can optionally be included >> (imported) by users. Users running old components where binary >> serialization is >> requiring matching type systems could then continue to work, by not >> including these. >> >> I plan to put this change into either 3.0.0 alpha (if rc3 fails) or the next >> beta version. >> >> I'll probably make a new project, "uimaj-types" whose purpose will be to >> collect >> "useful to a wider community" pre-defined types users could include all or >> some >> of in their pipelines, with the current 3 new built-in types as the first >> ones. >> >> What do you think? >> >> -Marshall >> >
