I'd go along with Pei's argumentation. If it is supposed to go into the JAR, it should not be in src/(main|test)/xxx.
For DKPro Core, I just these scripts to our wiki for the time being. The nice thing is that they are self-contained. So they are actually quite independent of the release cycle of DKPro Core - or in your case of cTAKES. -- Richard On 04.12.2013, at 14:51, Pei Chen <chen...@apache.org> wrote: > If we treat groovy as source code, I think maven has a convention of > putting them in > src > main >> java >> groovy >> scala > > src > test >> java >> groovy >> scala > > But since we're treating it as scripts, I would opt for the idea of keeping > it simple and having it as scripts/groovy/*.groovy > Would be nice to get some input from the other groovy users though... > > --Pei > > > > On Wed, Dec 4, 2013 at 10:09 AM, Tim Miller < > timothy.mil...@childrens.harvard.edu> wrote: > >> Very cool. I was noticing that it was downloading the umls resources which >> the parser itself doesn't need -- so I made a change to not grab >> clinical-pipeline and grab directly the things it was getting through that >> reference and now it runs even faster with only a 35M initial download. >> >> I'd like to check in my change -- should we keep working out of sandbox or >> can we maybe put groovy scripts somewhere alongside the projects they >> belong to? Maybe in the scripts/ directory or scripts/groovy, scripts/perl, >> etc.? Any opinions on this? >> >> Tim >> >> >> >> On 11/27/2013 12:19 PM, Chen, Pei wrote: >> >>> The sample constituency parser printer should be working now... >>> Just copy and paste the text to parser.groovy and make it executable. >>> All you should need is groovy installed on your machine. >>> http://svn.apache.org/repos/asf/ctakes/sandbox/groovy/parser.groovy >>> $ parser.groovy input >>> Reading from directory: input >>> (TOP (S (NP-SBJ (NN patient)) (VP (VBD took) (NP (NP (NNS 50mg)) (PP >>> (IN of) (NP (NP (NN aspirin)) (PP (IN for) (NP (NP (NN pain)) (PP-LOC (IN >>> in) (NP (NN knee)))))))))(. .))) >>> >>> Maybe we could create one that will output UMLS CUI/Codes... and then >>> others could easily modify to their needs. >>> >>> --Pei >>> >>>> -----Original Message----- >>>> From: William Karl Thompson [mailto:w...@northwestern.edu] >>>> Sent: Tuesday, November 26, 2013 10:46 PM >>>> To: dev@ctakes.apache.org >>>> Subject: RE: cTAKES Groovy... >>>> >>>> That is very cool! >>>> >>>> Since we're talking Groovy, I'd just like make a plug for Gradle, a >>>> fantastic >>>> build/deployment/dependency management tool that is in many ways much >>>> nicer to work with than Maven, though it plays nicely with Maven (for >>>> example, it can use Maven repositories). Gradle is also proven >>>> technology: >>>> it's the build tool for the Android operating system. >>>> ________________________________________ >>>> From: Chen, Pei [pei.c...@childrens.harvard.edu] >>>> Sent: Tuesday, November 26, 2013 4:13 PM >>>> To: dev@ctakes.apache.org >>>> Subject: cTAKES Groovy... >>>> >>>> Tim had a good end user use case: >>>> I just want to use the ctakes constituency parser and output the tree >>>> text to >>>> console. >>>> So I was inspired by Richard example of groovy... >>>> Check out: >>>> http://svn.apache.org/repos/asf/ctakes/sandbox/groovy/parser.groovy >>>> >>>> The groovy script will "Automagically" download the required >>>> classes,jars,resources and automatically runs. >>>> No longer requires the user to have any knowledge of UIMA, cTAKES, etc. >>>> Sample: >>>> $ parser.groovy input >>>> Reading from directory: input >>>> patient took 50mg of aspirin for pain in knee. >>>> begin:0 end:48 >>>> >>>> Pretty cool, 'eh... >>>> --Pei
