Maybe a good way to do this is to create a big jira and break it up into module-level jira's, then assign a person to each, and for each module: 1) Upgrade pom to latest release for modules being used 2) Recompile/retrain/retest and check in 3) Close jira for that module
Then have one last issue that is to 1) upgrade project-level pom managed versions to latest release 2) revert module-level poms to use managed versions 3) run tests and checkin How does that plan sound? Tim On 05/30/2013 11:06 PM, Steven Bethard wrote: > On May 30, 2013, at 8:38 PM, "Masanz, James J." <[email protected]> wrote: >> As a first pass, can we update the dependency to ClearTK 1.4.0 without >> retraining the models -- would retraining be necessary even if we didn't >> switch to LIBLINEAR. > Retraining might still be necessary for anything that uses CleartkExtractor, > since generation of out-of-bounds features has improved: > > https://groups.google.com/forum/#!topic/cleartk-users/KS2BLQcT-ds > > But anything not using CleartkExtractor should be safe. And even the things > that are using CleartkExtractor may not degrade much if the out-of-bounds > features aren't very important. But we'd need to test it a bit to see. > > Steve > > >> Just wonder if we have an option for staging this, in case we can't tackle >> it all now. >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf >> Of Steven Bethard >> Sent: Thursday, May 30, 2013 5:45 PM >> To: [email protected] >> Subject: upgrade ClearTK dependency to 1.4.0? >> >> I just released ClearTK 1.4.0 and there are a couple of reasons we should >> probably consider updating the cTAKES dependency: >> >> (1) ClearTK 1.4.0 can now load trained models from the classpath, so we >> could get rid of the workaround >> org.apache.ctakes.relationextractor.ae.RelationExtractorAnnotator.allowClassifierModelOnClasspath. >> >> (2) ClearTK 1.4.0 has wrappers for multi-class classification with LIBLINEAR >> which is orders of magnitude faster than LIBSVM. >> >> The main downside is that models will have to be re-trained. (It's not >> necessarily the case that all models would need to be retrained, depending >> on exactly which classes they were using, but it's probably safer to do so.) >> >> I believe this would mostly affect ctakes-temporal, >> ctakes-relation-extractor and ctakes-assertion. >> >> Thoughts? >> >> Steve >> >> P.S. I noticed that ctakes-assertion declares a dependency on >> cleartk-examples. The cleartk-examples module was never intended for >> release, and has not been released as part of ClearTK 1.4.0. Looking at the >> code, it seems like the dependency in cleartk-examples is not needed, but >> perhaps a ctakes-assertion person could weigh in on why this dependency was >> there? >
