Personally, I would prefer Sean's idea and I think it'd be easy to implement using org.junit.Assume [1]. The drawback is that one *must* remember to setup the umls credentials to run the tests during a release, whereas the maven profiles enforce that. But either is fine.

My $0.02,
Hadrian

[1] http://junit.org/junit4/javadoc/4.12/org/junit/Assume.html

On 10/06/2017 02:47 PM, James Masanz wrote:
Alex, I like the idea of "*2 profiles (in pom.xml), one *with* UMLS **account
and one *without**".  However, I would have just the one without the
credentials be part of the Jenkins job and someone would manually run the
other one as part of the release process (or whenever someone felt it was
warranted).


On Fri, Oct 6, 2017 at 11:23 AM, Finan, Sean <
[email protected]> 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:[email protected]]
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 <[email protected]>
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 <[email protected]>
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





Reply via email to