+1 on the Steve's points below. This actually gave me an idea to handle the #2,3 in Troy's user scenarios. I created some additional profiles in the pom.xml's to allow maven to launch Uima's CVD/CPE's from the command line using the exec plug-in. Essentially, one would just need to:
svn co https://svn.apache.org/repos/asf/incubator/ctakes/trunk mvn install (or clean, compile) //Option to update any desc/xml/resources/dictionaries modifications and rebuild] mvn exec:java -Pcvd //Launch UIMA CVD UI essentially using MVN to handle the dependencies by reusing the project's pom configuration. What do the rest of the folks think? If there are no objections, I'll commit those additions after the weekend. Obviously, #1 end-user we'll still need to provide something like the web interface. #4- I'm less concerned about since he/she will committing off the ctakes repository and I think it's fair to have a higher expectation if they are going to be committing back to the codebase. --Pei > -----Original Message----- > From: Steven Bethard [mailto:[email protected]] > Sent: Thursday, October 11, 2012 5:58 PM > To: [email protected] > Subject: Re: cTAKES uber jar distribution > > On Oct 11, 2012, at 3:21 PM, "Bleeker, Troy C." <[email protected]> > wrote: > > 1) A "user" (researcher but non-programmer) wants value from cTAKES > with no compiles, no dev env, just simple download/install/use. > > This sounds like someone who wants an executable jar file including all the > dependencies. We can create such a thing when there's a cTAKES GUI, using > an approach like the following: > > http://stackoverflow.com/questions/574594/how-can-i-create-an- > executable-jar-with-dependencies-using-maven > > > 2) A programmer new to cTAKES wants to take the whole, as quickly as > possible, into some kind of dev env, hopes not to have to deal with any > dependency or build issues (given a stable release) and invoke the APIs. Kick > the tires is the notion. > > This sounds like someone who wants a jar file with all the dependencies, but > doesn't care if it's executable. > > They can use the same jar file as generated for (1). > > (I personally think that any programmer who "hopes not to have to deal with > any dependency" is a lost cause in terms of a programmer, but it wouldn't > cost us anything to support this use case.) > > > 3) A programmer uses cTAKES mostly as a black-box. They take cTAKES as a > whole, perhaps minimal changes, include everything. Although dictionaries > could be replaced if they desire. > > I'm not sure what the difference between this person and the person from > (2) is. Do they also just want the jar files? Or do they want something else? > > Here's a more concrete suggestion: > > 3.5) A programmer who wants to use their favorite dependency > management tool (Maven, Ivy, SBT, Buildr, etc.) to depend on some (or all) > of released versions of cTAKES modules. > > This is someone who wants one jar file per module, deployed to Maven > Central (that's where all those dependency management tools look for jars). > This is pretty much the default thing supported by the standard `mvn > release:prepare` and `mvn release:perform`. > > > 4) An experienced cTAKES developer - mash cTAKES into any form they > want, change it, possibly contribute to Apache. May redistribute according to > the license. > > This person will be working from the cTAKES repository, and I think it's > acceptable to put additional constraints on them. In particular, I think we > should say that we only promise support for: > > * Building via Eclipse > * Building via Maven at the command line > > Steve
