Alex, I forgot to add: thanks for all your work on these changes and improvements.
regarding your email Sean, I think a small non-umls custom dictionary for a pipeline test would be great. And test(s) with combined hsql and bsv would also be great. I don't know they necessarily need to be outside a full pipeline, though that would be a good start. And I like the idea of using something like $JENKINS_HOME and/or $BUILD_ID, if it can be done, to determine whether to run tests using UMLS credentials if someone wants to look into it or knows how offhand. On Fri, Oct 6, 2017 at 11:23 AM, Finan, Sean < sean.fi...@childrens.harvard.edu> wrote: > Hi Alex, > > I think that it goes against the umls license to have credentials > available to the public. That might be what you were saying in a previous > email: > > Exporting the ctakes_umlsuser, ctakes_umlspw makes the whole build > > succeed. But having some credentials in the Jenkins job (official) > > doesn't make much sense. > > This might be a dumb question, but is it possible to disable a single test > in Jenkins depending upon the run environment? Can something like > $JENKINS_HOME and/or $BUILD_ID be used? If they are in the environment > then it should be easy to check in a unit test and log a warning instead of > running the test. > > One thing that we can do is use a small non-umls custom dictionary for a > pipeline test. > > One thing that has long been on my plate is smaller hsql, bsv and combined > component tests. They should be tests outside a full pipeline; just simple > segment, sentence, pos and dictionary, and a created cas. > > What do you think? Anybody else? > > Sean > > -----Original Message----- > From: Alexandru Zbarcea [mailto:al...@apache.org] > Sent: Friday, October 06, 2017 10:41 AM > To: Apache cTAKES Dev > Subject: Re: building cTAKES (discussion transferred from CTAKES-445 > [EXTERNAL] > > I started to look for ways to make the build stable. After applying patch > for CTAKES-334, the only issue remains with: > > testCPE(org.apache.ctakes.regression.test.RegressionPipelineTest): > Initialization of CAS Processor with name "RegressionPipelineAggregateTes > t" > failed. > > which is caused by: > > ERROR UmlsUserApprover - User CHANGE_ME not allowed. It is a placeholder > reminder. > > The first thought was to implement 2 profiles (in pom.xml), one *with* > UMLS account and one *without*. A successful release would have to pass a > test execution for both profiles though. That means, in the official > Jenkins would have to be a reference for the UMLS credentials. > > What do you think? > > Alex > > On Thu, Oct 5, 2017 at 1:47 PM, Alexandru Zbarcea <al...@apache.org> > wrote: > > > Hi James, > > > > I have been working on stabilizing the build for 4.0.0, and I > > discovered the following: > > * CTAKES-445 (commited) > > * CTAKES-334 (patch provided - NOT committed by the community, but > > ready, > > tested) > > * UMLS credential UTest (work-in-progress) > > > > Exporting the ctakes_umlsuser, ctakes_umlspw makes the whole build > > succeed. But having some credentials in the Jenkins job (official) > > doesn't make much sense. > > > > With all these patches, cTAKES would have a stable build, making it > > closer to be releasable from official Apache repository. > > > > I also started cleaning up some WARNING(s): see CTAKES-463, > > CTAKES-465, issues that would improve the quality of the binaries. > > > > I look forward to your feedback, > > Alex > > > > > > > > > > > > On Tue, Oct 3, 2017 at 5:56 PM, James Masanz <masanz.ja...@gmail.com> > > wrote: > > > >> A question was asked within JIRA issue CTAKES-445 > >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.o > >> rg_jira_browse_CTAKES-2D445&d=DwIBaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZ > >> MSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=bvLXDfh > >> 0IADeKEvPAs2FfCE5JjPSwZ32r8Fw3DNV5FM&s=3Z-jEPHYenjA6JszcDCLhiymi7al8J > >> 5RcFbZTyy3XVY&e= > about building cTAKES that is more general than > >> the topic of CTAKES-445, so I'm transferring that to this mailing > >> list. It started with the following question > >> > >> how someone is able to provide complete Apache cTakes 4.0 binaries @ > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__archive.apache.or > >> g_dist_ctakes_ctakes-2D4.0.0_apache-2D&d=DwIBaQ&c=qS4goWBT7poplM69zy_ > >> 3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTa > >> o&m=bvLXDfh0IADeKEvPAs2FfCE5JjPSwZ32r8Fw3DNV5FM&s=oc8UopbX3fwk1z3oFmP > >> UPyzdTYW5QW35NSfpB2T2rDA&e= > >> ctakes-4.0.0-bin.tar.gz > >> while > >> we struggle to build it from official Apache repository because of > >> issues like this one [CTAKES-445 > >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.o > >> rg_jir&d=DwIBaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67G > >> vlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=bvLXDfh0IADeKEvPAs2FfCE5JjPS > >> wZ32r8Fw3DNV5FM&s=CXhGNBxrs_S7CFBpQMbtQ7ygcylD9lIq1bwElNx9BHA&e= >> > >> a/browse/CTAKES-445> ] > >> > >> > >> If you are trying to build a binary of cTAKES, I suggest you follow > >> instructions from the cTAKES 4.0 Developer Install Guide > >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.or > >> g_confluence_display_CTAKES_cTAKES-2B&d=DwIBaQ&c=qS4goWBT7poplM69zy_3 > >> xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao > >> &m=bvLXDfh0IADeKEvPAs2FfCE5JjPSwZ32r8Fw3DNV5FM&s=RchFgtJIDpmC-PAgEW4z > >> xd0a5hNtt8Yo3US-XtU5tiA&e= >> 4.0+Developer+Install+Guide> to get a > copy of cTAKES from trunk, but when checking out the source, be sure to > specify the revision you are interested in. By checking out from trunk, you > will get pom files that have a SNAPSHOT version. > >> > >> Then use the command line version of maven to do something like the > >> following mvn clean install -DskipTests=true You should find the > >> binaries have been built somewhere under ctakes-distribution > >> > >> -- James > >> > > > > >
