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 >
