ruta-core was built successfully on jenkins :-)
Am 19.08.2016 um 11:09 schrieb Peter Klügl: > Thanks Richard, I forgot that there are no problems at all if I use > uimaFIT "correctly". > > > +1 I will adapt ruta to use descriptions > > > I do already some stuff you mention below, but the part with the inlined > analysis engines was a bit neglected. > > > Best, > > > Peter > > > Am 19.08.2016 um 10:08 schrieb Richard Eckart de Castilho: >> I have been thinking a bit about this. >> >>> On 19.08.2016, at 09:57, Peter Klügl <[email protected]> wrote: >>> >>> What are our options concerning the three projects? The functionality in >>> ruta calling analysis engines is needed (preferable without switching in >>> future). >> With the present release versions of UIMA/uimaFIT, the following should >> be done when creating analysis engines inside other analysis engines: >> >> // use createEngineDescription instead of createEngine >> AnalysisEngineDescription aed = createEngineDescription(MyNestedAE.class); >> >> // Obtain resource manager from enclosing AE >> ResourceManager mgr = ((UimaContextAdmin) >> getContext()).getResourceManager(); >> >> // Use that resource manager when creating the actual engine >> AnalysisEngine engine = UIMAFramework.produceAnalysisEngine(aed, mgr, >> null); >> >>> Yes, uimaFIT should not create a resource manager, or at least there >>> should be an option to reuse a given one... >> There is no uimaFIT method for this because it can easily be >> accomplished using UIMAFramework. >> >>> or at least a given classloader. The switching is somewhat problematic >>> for me and Ruta, but did not cause too serious problems yet. >> You could also do that by creating your own resource manager and using >> it when creating the engine: >> >> ResourceManager resMgr = UIMAFramework.newDefaultResourceManager(); >> resMgr.setExtensionClassPath(myClassLoader, "", true); >> >>> There is of course ResourceManagerFactory.setResourceManagerCreator(). >>> With this, I could delegate the existing/ruta resource manager to the >>> uimaFIT factories, but I do not know if I should really do this in a >>> static manner. >> I don't think that makes sense in this case. I added that function in >> case somebody wants to use uimaFIT with the original UIMA behavior >> (i.e. without using the Thread context classloader) or to experiment >> with other classloading scenarios. >> >> What do you think? >> >> Cheers, >> >> -- Richard >> >>
