This is OK with me. I can even volunteer to write the docs (but am happy to others do it :-) ).
I'll wait to hear about the split (if any) between the public API and the impl. And, we'll need to change the next version # to 2.9.0, from 2.8.2, due to this being that kind of a change. Is everyone OK with all of this? -Marshall On 7/18/2016 2:39 PM, Richard Eckart de Castilho wrote: > I believe the intention is that this class becomes part of the public API. > > Also, my understanding is that it would do a superset of what the > uimaFIT class by the same name does. We could then probably deprecate > the respective uimaFIT class and suggest using the core class instead. > > Best, > > -- Richard > >> On 18.07.2016, at 20:30, Marshall Schor <[email protected]> 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 >> >
