Hi, we basically gave up on the data.path long time ago and load everything from what we call a "location". A "location" is a String which is interpreted as a classpath location if is starts with "classpath:", otherwise as a URL if it is a valid URL, otherwise as a File path if that path exists.
As you mentioned, not all components are able to access stuff from URLs or streams. We have a set of helper methods to convert a URL to a file (extracting to a temporary location if necessary), to help extracting whole directory structures from JARs to temporary locations, and to handle file which need to be executable. This is all in the DKPro Core ResourceUtils [1] and RuntimeProvider [2] classes. Of course, with this approach, we need to be able to control at least the UIMA wrapper code. That's one reason (of several) why we do not use the UIMA components from the OpenNLP project, but we wrote our own wrappers for OpenNLP. It works nicely though with external tools like TreeTagger, SFST, MeCab, and many others. Cheers, -- Richard [1] https://dkpro-core-asl.googlecode.com/svn/de.tudarmstadt.ukp.dkpro.core-asl/trunk/de.tudarmstadt.ukp.dkpro.core.api.resources-asl/src/main/java/de/tudarmstadt/ukp/dkpro/core/api/resources/ResourceUtils.java [2] https://dkpro-core-asl.googlecode.com/svn/de.tudarmstadt.ukp.dkpro.core-asl/trunk/de.tudarmstadt.ukp.dkpro.core.api.resources-asl/src/main/java/de/tudarmstadt/ukp/dkpro/core/api/resources/RuntimeProvider.java On 28.05.2013, at 18:47, Jens Grivolla <[email protected]> wrote: > Hi, > > we currently (almost always) use the CPE to run our AEs (packaged as PEARs > and then installed). However, we would like to start packaging our AEs > differently to make it easier to also use them programatically, or e.g. > include them in Solr using SolrUima. To do so we have started to modify some > of our annotators so they load their resources from the classpath instead of > using a file path and are getting closer to being able to package everything > in JAR files. > > However, the standard UIMA project structure puts things quite differently > from a typical Maven layout, meaning that there's quite a bit of tweaking to > make things fit with being both resolvable from the classpath and staying > close to the UIMA structure. Should we just forget about uima.datapath and > the /resource and /desc folders and put it all in /src/main/resources etc.? > How compatible would that be with the PearPackagingMavenPlugin? > > I think we will move to using UimaFit once it is released, but for some of > the people here being able to have readily packaged PEAR files with > descriptors that can be distributed is a big advantage that we don't want to > give up. > > Thanks, > Jens >
