ctakes-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chen, Pei" <Pei.C...@childrens.harvard.edu>
Subject RE: ytex ctakes patches
Date Fri, 01 Nov 2013 15:28:26 GMT
Hi VJ,
Apologies for the delayed response.  I'll try to incorporate the changes over the next few
days... unless someone beats me to it and tackles these Jira's beforehand...

Regarding uimaFIT vs XML descriptors.  Yes, I think some of the older components have remained
intact largely for legacy reasons, and no one has gotten back to upgrading them yet.
Especially since we no longer use the pear deployment, we should be able to simplify it significantly-
maybe remove all of the individual/duplicate descriptor files and leave a few sample aggregate
ones  (Note: you can also use uimaFIT to generate the xml descriptor files which is also pretty
handy for newer components).  
I'm a +1 for using the name in the classpath just like resources- There may have already been
an open Jira for it.  
It probably makes sense to spend some time and have a bit of an overhaul and have a fresh
eye on the descriptors just like what we did with resources... my 2 cents.
--Pei


> -----Original Message-----
> From: vijay garla [mailto:vngarla@gmail.com]
> Sent: Monday, October 28, 2013 10:20 PM
> To: dev@ctakes.apache.org
> Subject: ytex ctakes patches
> 
> For the YTEX port, I've taken a few baby steps ... I've filed some jira tickets
> with patches:
> CTAKES-253<https://issues.apache.org/jira/browse/CTAKES-253>
>  and CTAKES-252 <https://issues.apache.org/jira/browse/CTAKES-252>,
> more coming soon.
> 
> I have a question regarding testing: it seems to me that the old analysis
> engines all use xml descriptors, whereas the newer analysis engines appear
> to be using uimafit.  I understand why that's the case, but the dissonance
> between the development & user directory structures makes it very difficult
> to write portable tests and portable xml-based ae configs: for a 'user'
> install, everything under desc is in the classpath, whereas for the developer
> install, none of the desc directories are in the classpath.
> 
> When I'm writing an XML-based aggregate AE config, I prefer to import
> delegate AEs by name instead of location as resolving files by classpath is
> much more flexible than resolution by file paths.  Can we add the desc
> directories to the maven-surefire-plugin classpath (as is done with
> resources) so that the classpath is consistent across developer/user installs?
> 
> TIA,
> 
> VJ

Mime
View raw message