oops, hit send too soon. I see the uimaFIT getLogger method is on a class which extends the main UIMA class which would have getLogger().
uimaFIT's method would clash, because it returns a different Java type. I'll pick another name to avoid the clash. -M On 2/6/2017 1:29 PM, Marshall Schor wrote: > > +1 to not clashing, etc. > > I'm not sure they would clash - because the uimaFIT getLogger method is on > > > On 2/3/2017 8:57 AM, Richard Eckart de Castilho wrote: >> On 02.02.2017, at 17:16, Marshall Schor <[email protected]> wrote: >>> 3) For Annotators, the base class they extend is augmented with getLogger() >>> and >>> getSlf4jLogger(); these return either the UIMA logger or an SLF4j logger >>> with >>> the name of the Annotator implementation class. getLogger() is just >>> shorthand >>> for the existing getContext().getLogger() api. >> It would be nice to make sure that a getLogger() method added to the UIMA >> core >> base classes would not clash with the one that the uimaFIT base-classes >> already >> provide - or if not, then it means that indeed uimaFIT needs to move to UIMA >> v3 >> meaning the discussion we had about setting up builds simultaneously against >> v2 >> and v3 would become obsolete at least for uimaFIT. >> >> -- Richard >
