Hi Pei, +1 to move forward, I don't think there has been any contention and I don't think we need a VOTE here.
How about this -- in 24-48 hours just start the migration process. If you are doing the work, and making progress, you have my full support in moving forward, and I encourage others to support you too. At Apache, "those who do, decide", and you have been doing a great job of "do'ing", so go ahead and "decide" :) Cheers, Chris On Jul 20, 2012, at 7:18 AM, Chen, Pei wrote: > There were a lot of interesting points in this discussion. > Shall we target to close the vote and summarize and collate the results at > the end of the Month (July 31)? > Then we could begin the migration process... > > --Pei > > -----Original Message----- > From: Coarr, Matt [mailto:[email protected]] > Sent: Thursday, July 19, 2012 10:11 AM > To: [email protected] > Subject: Re: SVN source structure for Apache cTAKES? > > +1 for a single trunk with all the subprojects below it. It makes checking > out the whole code base and tagging/branching much easier. So marking all > the components as ctakes 2.6 would be a lot simpler. > > +1 for multiple jars. Maven encourages a good practice here that is useful > in projects whether or not they use maven - each project should produce one > main jar (it may produce additional jars for things like source and > javadocs). This keeps a nice clean one-to-one association between projects > and jar files. > > +1 on using the standard src/main/java type directory structure. This is > very commonly used and I don't think we should invent our own. It makes it > easy for newcomers to just know where everything is without thinking about it. > > +1 for encouraging building of unit tests and examples. I'd suggest keeping > examples in their own projects (core, core-examples, assertion, > assertion-examples, etc). This makes it obvious where the examples are and > it doesn't clutter up the primary release binary. > > +1 for the common package structure and naming, though I think this probably > needs some more thought than just adopting whatever comes first. All of our > modules have some similar pieces seeing as their uima components doing nlp > work (analysis engine, configuration/resources, training, decoding, > evaluation, etc). > > I agree that models/resources to be managed specially. I'd like to see these > managed (on the deployment/release side) as maven artifacts. > > For these models, if we do keep them in svn, I'd like to suggest that we do > not keep them under the common root trunk/tags/branches. These files are > easily hundreds of MB to gigabytes. And I'd like to see the svn operations > perform quickly. I'd also like to be able to have multiple version of ctakes > checked out. > > Maybe we could use something like this: > > ctakes/modules/trunk > ctakes/modules/trunk/core > ctakes/modules/trunk/lvg > ctakes/resources/trunk > ctakes/resources/trunk/lvg-model > ctakes/resources/trunk > > Then if you're not working on model development, you just need to check out > ctakes/modules/trunk, and maven would pull in any resources as needed. > > Matt ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
