The downside of putting descriptors inside a jar/war is that you would need to recompile/re-jar for simple xml changes. I think for some, they might consider xml a configuration change and not necessary a code change. I wonder if that was the motivation of why if you create a new UIMA nature, it puts it in a desc directory (let's dig into it a little bit, but probably could go either way on that).
What about those larger resources such as LVG or Dictionary Lookup? In my opinion, they probably shouldn't even be versioned in the same spot as the java srcs... Perhaps an /incr directory outside of trunk? I would image something like /dictionarylook2011ab, /dictionaryloookup2012aa doesn't need to be inside a particular release. > -----Original Message----- > From: Steven Bethard [mailto:[email protected]] > Sent: Tuesday, September 25, 2012 3:20 AM > To: [email protected] > Subject: Re: ctakes-resources > > On Sep 25, 2012, at 12:10 AM, "Chen, Pei" > <[email protected]> wrote: > > During the updating of the project names, I left the resources folders > intact. > > > > What do folks think about the resources? > > > > 1) Should we leave the resources as is (within each project)? Or > > > > 2) Create a ctakes-resources module that contains all of the resource > files? > > > > For example: > > ctakes-resources/ > > ctakes-chunker/desc > > ctakes-chunker/models > > ctakes-dictionary-lookup/somelookupbinariesfolder > > In an ideal world, all resources (descriptors, models, etc.) would be > distributed in the jar file and referenced via Java's Class.getResource > mechanism. In Maven, this means putting them into src/main/resources. > > So my vote would be one of: > > (1) In the src/main/resources directory of the ctakes-XXX project. > > (2) Descriptors that don't refer to specific models would go into > src/main/resources of ctakes-XXX, but the models and the descriptors that > refer to them would go into src/main/resources of a separate ctakes-XXX- > models project. This would allow people to exclude the models if they don't > need them, which can make a lot of sense for the big models. > > Steve
