> 1. If referencing UIMA descriptors via name, make sure the descriptor name
> attribute and the filename are the same (not including the .xml).
> 2. In DictionaryLookupAnnotatorUMLS.xml there is a reference to the UMLS
> hsqldb via file path. To change it to class path, see the changes below
Thanks Brandyn and Co. for that excellent suggestion! It worked like a charm...
Since the resources and type systems have been automagically added to the
classpath/jars by maven, we can reference them by name easily now without
having to worry about those relative ../../.. locations. We'll see if we could
do the same for the AnalysisEngines in the future as well.
<import name="org.apache.ctakes.assertion.types.TypeSystem"/>
<import name="org.apache.ctakes.typesystem.types.TypeSystem"/>
> -----Original Message-----
> From: Kusenda, Brandyn J [mailto:[email protected]]
> Sent: Wednesday, September 26, 2012 11:05 AM
> To: [email protected]
> Subject: RE: ctakes-resources
>
> Hello,
>
> I've have some of the classpath related changes working on my local copy of
> cTAKES. Here are a couple of things I discovered, that might save you some
> time.
>
> 1. If referencing UIMA descriptors via name, make sure the descriptor name
> attribute and the filename are the same (not including the .xml).
>
> 2. In DictionaryLookupAnnotatorUMLS.xml there is a reference to the UMLS
> hsqldb via file path. To change it to class path, see the changes below
>
> Original using file path:
> --SNIP--
> <nameValuePair>
> <name>URL</name>
> <value>
> <string>jdbc:hsqldb:file:../dictionary
> lookup/resources/lookup/umls2011ab/umls</string>
> </value>
> </nameValuePair>
> --SNIP--
>
> Updated to use class path if the lookup directory is in the
> /src/main/resources/ (notice the use of 'res' as oppose to 'file' in the
> connection string)
> -SNIP-
> <nameValuePair>
> <name>URL</name>
> <value>
> <string>jdbc:hsqldb:res:lookup/umls2011ab/umls</string>
> </value>
> </nameValuePair>
> --SNIP--
>
> Thanks,
> Brandyn
>
> ________________________________________
> From: Chen, Pei [[email protected]]
> Sent: Tuesday, September 25, 2012 4:22 PM
> To: [email protected]
> Subject: RE: ctakes-resources
>
> I think Brandyn and others had a reasonable suggestion to use the name
> instead of location paths in those pesky descriptor xml files- Assuming
> they're in the classpath (placed in src/main/resources).
> I'll take a stab at this later this week if I get a chance. But trunk
> *should*
> compile now in case other want to start working on it. Apologies in advanced
> if I broke someone's build at this point- it was a pretty large change...
>
> Troy: If we do this correctly, this should be transparent (if not easier) to
> end-
> users.
>
> > -----Original Message-----
> > From: Coarr, Matt [mailto:[email protected]]
> > Sent: Tuesday, September 25, 2012 11:16 AM
> > To: [email protected]
> > Subject: Re: ctakes-resources
> >
> > Trying to distill some of the suggestions...
> >
> > Could we have two top level directories in svn -- main-modules and
> > resource-modules? And then below resource-modules we could have
> > dictionary-lookup-resources, lvg-resources, etc.
> >
> > * (ctakes svn trunk)
> > * main-modules
> > * core
> > * clinical-documents-pipeline
> > * dictionary-lookup
> > * lvg
> > * resource-modules
> > * dictionary-lookup-resources
> > * lvg-resources
> >
> > This means you could just checkout main-modules and keep it pretty
> > small (mostly just code and descriptors). Then you can checkout "main-
> modules"
> > a a few times to have different working directories without taking up
> > too much space (perhaps a working copy for trunk development, another
> > for clean copy of latest release, a third for an experimental branch,
> > and perhaps a fourth for a branch to patch the last release). But
> > they could all use the same resources.
> >
> > And ideally, most users and developers could pull those resources from
> > the maven repository as an artifact, unless they were working on
> > packaging up a new version of those resources.
> >
> > Matt
