I concur. +1 for option 2 -- I do not really see any advantages that option 3 could have over option 2, as the difference should be largely transparent to users (and even developers)
-- Karthik Sarma UCLA Medical Scientist Training Program Class of 20?? Member, UCLA Medical Imaging & Informatics Lab Member, CA Delegation to the House of Delegates of the American Medical Association [email protected] gchat: [email protected] linkedin: www.linkedin.com/in/ksarma On Tue, Mar 19, 2013 at 9:49 AM, Masanz, James J. <[email protected]>wrote: > I also am +1 for option 2. > > #3 is my least favorite, because of the download time for some of the > models, both for cases like Steve mentioned but also for cases of wanting > to check out a fresh copy of the code and not wanting to wait to check out > the models again > > -- James > > > > -----Original Message----- > > From: ctakes-dev-return-1378-Masanz.James=mayo....@incubator.apache.org > > [mailto:ctakes-dev-return-1378-Masanz.James= > [email protected]] > > On Behalf Of Steven Bethard > > Sent: Friday, March 15, 2013 1:06 PM > > To: [email protected] > > Subject: Re: [DISCUSS] Where should cTAKES models live? > > > > On Mar 15, 2013, at 4:39 PM, "Chen, Pei" <[email protected] > > > > wrote: > > > So the question is: What should we do with the model files? Some > > options include: > > > > > > 1) Leave them in SourceForge/Maven Central. Maven can download > and > > include them in the convenience binaries in the ctakes-distribution > > project. Something we did quickly for 3.0, but needs to be improved if we > > go with this approach. For example: [2] > > > > > > 2) Leave them in the ASF repo, but separate modules/projects. > > > > > > 3) Keep them in the same respective ASF modules under > > /src/main/resources > > > > > > I think it's nice to keep these fairly large (~1GB) and static resource > > files separate from the source code (Either option 1 or 2). Also, option > > 1 will require a little more work by the committers/release managers but > > will definitely avoid any licensing issues/concerns. > > > > I'd definitely vote for (2). That makes releases much easier than if you > > have to coordinate between the ASF and Sourceforge repositories, but also > > allows people to depend on the code in a module without also pulling in > > all the models as well. (This would make a lot of sense even now, for > > example, in ctakes-temporal which depends on ctakes-relation-extractor > > only for the relation extraction framework and not for the location_of > and > > degree_of models.) > > > > Steve >
