In this theoretical version of things I would suggest we have 2 sets of descriptors and both would live in the cTAKES SVN - one set for all the real models - one set for the dummy models.
And 2 sets of tests, also both in cTAKES SVN -- James > -----Original Message----- > From: ctakes-dev-return-1371-Masanz.James=mayo....@incubator.apache.org > [mailto:ctakes-dev-return-1371-Masanz.James=mayo....@incubator.apache.org] > On Behalf Of Steven Bethard > Sent: Thursday, March 14, 2013 3:00 PM > To: [email protected] > Subject: Re: relation-extractor - how to include it as a dependency? > > On Mar 14, 2013, at 8:52 PM, "Masanz, James J." <[email protected]> > wrote: > > If we end up unable to keep the (real) models in the apache SVN, I'm > imagining not having the tests that rely on the real models run > automatically. > > > > We can create some dummy models just for testing and only run those > tests automatically. > > And to run the tests using the real models, someone would need to check > out the project, get the real resources, and run the real tests. > > And the descriptors in SVN would also point to the dummy models? > > Steve > > > > > > > Regards, > > James Masanz > > > > > >> -----Original Message----- > >> From: > >> ctakes-dev-return-1369-Masanz.James=mayo....@incubator.apache.org > >> [mailto:[email protected] > >> .org] > >> On Behalf Of Steven Bethard > >> Sent: Thursday, March 14, 2013 2:46 PM > >> To: [email protected] > >> Subject: Re: relation-extractor - how to include it as a dependency? > >> > >> On Mar 14, 2013, at 8:43 PM, "Masanz, James J." > >> <[email protected]> > >> wrote: > >>> I just posted a comment on LEGAL-157 asking for some movement. > >>> > >>> No matter what the answer there about the models, I suggest leaving > >>> the > >> descriptors and the tests in Apache cTAKES SVN. > >> > >> But if the tests require the models, won't they always fail if > >> they're in cTAKES SVN? > >> > >> Or are you imagining that ctakes-relation-extractor will depend on > >> ctakes- resources-relationextractor? > >> > >> Steve > >> > >>> > >>> -- James > >>> > >>>> -----Original Message----- > >>>> From: > >>>> ctakes-dev-return-1364-Masanz.James=mayo....@incubator.apache.org > >>>> [mailto:[email protected] > >>>> he > >>>> .org] > >>>> On Behalf Of Steven Bethard > >>>> Sent: Thursday, March 14, 2013 10:39 AM > >>>> To: [email protected] > >>>> Subject: Re: relation-extractor - how to include it as a dependency? > >>>> > >>>> Yeah, I never saw a conclusion to the discussion of where the > >>>> relation- extractor models should go. My last impression was that > >>>> they can't be in the Apache SVN at all, and they need to be in the > >>>> Sourceforge ctakesresources project. Is that right? > >>>> > >>>> If that's the case, we need to update RelationExtractorTrain to > >>>> deploy the models to that project rather than src/main/resources > >>>> (where it currently deploys them), and delete all the models in the > >> cTAKES SVN. > >>>> > >>>> And then where would the descriptors go? In the Sourceforge project? > >>>> Or in the cTAKES SVN? Seems weird to have them in the cTAKES SVN if > >>>> they can't refer to their models. > >>>> > >>>> And if we move the descriptors to Sourceforge, I guess that also > >>>> means moving the tests to Sourceforge? > >>>> > >>>> Steve > >>>> > >>>> P.S. In the meantime, you may be able to get things working by > >>>> making a copy of EntityMentionPairRelationExtractorAnnotator.xml > >>>> that looks in org/apache/ctakes/relationextractor/models/em_pair > >>>> instead of resources/models/em_pair, since there are currently > >>>> still models in src/main/resources. > >>>> > >>>> > >>>> On Mar 14, 2013, at 4:11 PM, "Chen, Pei" > >>>> <[email protected]> > >>>> wrote: > >>>> > >>>>> Hi Vinod, > >>>>> I think that looks like a bug. Feel free to open a Jira. > >>>>> > >>>>> Sent from my iPhone > >>>>> > >>>>> Sent from my iPhone > >>>>> > >>>>> On Mar 14, 2013, at 10:46 AM, "Kaggal, Vinod C." > >>>>> <[email protected]> > >>>> wrote: > >>>>> > >>>>>> Hello! > >>>>>> > >>>>>> Quick Background: We have been working on integrating CTAKES with > >>>> DataNormalization pipeline (as part of SHARPN effort). I have added > >>>> relation-extractor as a dependency to our Normalization project as > >>>> the template-filling module/project uses it. > >>>>>> > >>>>>> Question: What is the is a recommended way of adding the > >>>>>> relation- > >>>> extraction's resource directory to a project that uses this project? > >>>> Just adding the project (relation-extractor) to the build-path > >>>> (projects) results in the following error: > >>>>>> > >>>>>> > >>>>>> Caused by: org.apache.uima.resource.ResourceInitializationException > >>>>>> at > >>>> org.cleartk.classifier.CleartkAnnotator.initialize(CleartkAnnotator > >>>> .j > >>>> ava:1 > >>>> 15) > >>>>>> at > >>>> org.chboston.cnlp.ctakes.relationextractor.ae.RelationExtractorAnno > >>>> ta > >>>> tor.i > >>>> nitialize(RelationExtractorAnnotator.java:121) > >>>>>> at > >>>> org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.i > >>>> ni > >>>> tiali > >>>> zeAnalysisComponent(PrimitiveAnalysisEngine_impl.java:250) > >>>>>> ... 71 more > >>>>>> Caused by: java.io.FileNotFoundException: > >>>> resources/models/em_pair/model.jar (No such file or directory) > >>>>>> at java.io.FileInputStream.open(Native Method) > >>>>>> at java.io.FileInputStream.<init>(FileInputStream.java:120) > >>>>>> at java.io.FileInputStream.<init>(FileInputStream.java:79) > >>>>>> at > >>>> org.cleartk.classifier.jar.GenericJarClassifierFactory.createClassi > >>>> fi > >>>> er(Ge > >>>> nericJarClassifierFactory.java:67) > >>>>>> at > >>>> org.cleartk.classifier.jar.JarClassifierFactory.createClassifier(Ja > >>>> rC > >>>> lassi > >>>> fierFactory.java:35) > >>>>>> at > >>>> org.cleartk.classifier.CleartkAnnotator.initialize(CleartkAnnotator > >>>> .j > >>>> ava:1 > >>>> 13) > >>>>>> > >>>>>> > >>>>>> Looks like copying the resources directory to the target project > >>>> (Normalization project in this case) seems to take care of this > issue. > >>>> However, I wanted to see a cleaner way of doing this instead of > >>>> duplicating the jar (and other resources). > >>>>>> > >>>>>> > >>>>>> Vinod > >>> > >
