AE project structure

[Jens Grivolla <j+...@grivolla.net>]

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

Re: AE project structure

[Tommaso Teofili <to...@gmail.com>]

Hi Jens,
What about extending the PearPackagingMavenPlugin to support other
locations?
Regards,
Tommaso


2013/5/28 Jens Grivolla <j+...@grivolla.net>

> 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
>
>

Re: AE project structure

[Richard Eckart de Castilho <ri...@gmail.com>]

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 <j+...@grivolla.net> 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
>