I added it because Richard mentioned that he would like to have it (as far as I remember). I do not care since we do not need to include the type system.
Am 03.08.2016 um 22:34 schrieb Marshall Schor: > The save in format COMPRESSED_FILTERED only makes sense if you pass in an > additional type system to represent the "filter". > > Some choices: > > Disable this - throw unsupported operation exception for saving with > COMPRESSED_FILTERED until we get a real need/use-case for this. I would also > do > this for COMPRESSED_FILTERED_TS. *my choice* > > Otherwise, introduce another variant of save, which has an additional > argument, > which is the filtering TypeSystem, and require that form be used for these two > forms. > > -Marshall > > On 7/18/2016 2:30 PM, Marshall Schor wrote: >> This is a new class added to uimaj-core project, in org.apache.uima.util >> package. This is fine if this is to be part of the official public APIs >> supported by UIMA going forward; but if that is the case, it should probably >> be >> documented in the UIMA docs, and we'd have to change the version number (due >> to >> enforcer rules). >> >> If this is more of an internal use utilities, then it should be in one of the >> internal use packages, such as >> >> org.apache.uima.internal.util >> >> This class is similarly named to a UIMAFit class; are these related? >> >> If some of the APIs are to be permanent and public and part of the official >> public APIs, but some are internal implementation details, please consider >> using >> an interface and an ".impl" (or equivalent) approach; packages which support >> these are: >> >> org.apache.uima.util and >> >> org.apache.uima.util.impl >> >> -------------- >> >> If this is only an internal kind of change, not intending to affect the >> official >> UIMA APIs, then moving to the internal.util package will fix the "enforcer" >> error the build is currently getting. >> >> -Marshall >> >>
