Hi Alex, It all sounds fine to me – you obviously have more hard (as opposed to soft) devops experience than I.
I like the external source (your enum UmlsEnvironmentConfiguration) to replace 4 local string constants – they did start to pop up all over the place. For that matter, great boy scouting all over the place! This reminds me … ThreadedUmls* is dead-end code that I should deprecate and then remove. By eye I like what you’ve done. Can I assume that the apache-release change is working for you? If so then it would be a more universally applicable fix than a simple check for Jenkins. It just means that people need would need to compile/test with that profile every once in a while – which I think kind of comes down to using something like @category and profile “regression”, except with very different inferences. What do you think about making another profile? Or am I just muddying the waters? Many thanks, Sean From: Alexandru Zbarcea [mailto:zbarce...@gmail.com] Sent: Wednesday, November 15, 2017 10:36 PM To: Apache cTAKES Dev Subject: Re: Disable yTEX and Regression tests on Jenkins [EXTERNAL] Hi Sean, You're right. Most of the time, the community doesn't have their own Jenkins for a cTAKES build. I just find the Jenkins "hardcoding" solution a little bit unusual for builds.apache.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__builds.apache.org&d=DwMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=Nub-VURn12Fe1c6GYlv6GQNbttfAph_JWwFVGFFHa0Q&s=Ghhop-jqb9iexmWLPitFFRl10NhVig3lsTYy_n3PozM&e=>. However, the solution I was working on, I decided to get your feedback and not just commit-ing it. You can find the patch attached [1], or on github for more convenience [2]. Together with the Assume.assumeTrue, I also removed duplicates for the environment variables usage: "ctakes.uml*". I have also added to the pom.xml the enforcement for the ctakes.umlsuser to CHANGE_ME. That means, the one who makes the releases would have to build with something like: -Dctakes_umlsuser=<his-user> -Dctakes_umlspw=<his-password> Committing this patch would make the Jenkins build succeed. I would like to know what the community thinks about making the changes to the official [3] Jenkins job to be the same as the cTAKES-trunk-Java-1.8 [4]. The later job has Sonar integration, runs all tests and: --fail-at-end --errors --update-snapshots clean install vs clean compile test Getting back to your solution, Sean, I am curious how the community is using cTAKES (integrated or as a dependency) and building cTAKES solutions. I look forward to your feedback, Alex [1] - testCPE.CTAKES-479.svn.patch (see attachment) [2] - https://github.com/azbarcea/ctakes/commit/1f460a0e2bc2463d87ca3072a8fa0a3cf2eab69a<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_azbarcea_ctakes_commit_1f460a0e2bc2463d87ca3072a8fa0a3cf2eab69a&d=DwMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=Nub-VURn12Fe1c6GYlv6GQNbttfAph_JWwFVGFFHa0Q&s=Tm1df47_xb_wWcvAmJ0ItaaJFYmtHrioiT9q39vHWXQ&e=> [3] - https://builds.apache.org/view/C/view/Apache%20cTAKES/job/ctakes-trunk-compiletest/<https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_view_C_view_Apache-2520cTAKES_job_ctakes-2Dtrunk-2Dcompiletest_&d=DwMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=Nub-VURn12Fe1c6GYlv6GQNbttfAph_JWwFVGFFHa0Q&s=XC6SlR_CtFI6kwQtpu39T-lNbW4yesCs7EdOkpzDiJw&e=> [4] - https://builds.apache.org/view/C/view/Apache%20cTAKES/job/cTAKES-trunk-Java-1.8/<https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_view_C_view_Apache-2520cTAKES_job_cTAKES-2Dtrunk-2DJava-2D1.8_&d=DwMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=Nub-VURn12Fe1c6GYlv6GQNbttfAph_JWwFVGFFHa0Q&s=25NM-JgVwOu3EfTDMgRNPJa6QOsvlt9CK06rB2OsxtA&e=> On Wed, Nov 15, 2017 at 5:10 PM, Finan, Sean <sean.fi...@childrens.harvard.edu<mailto:sean.fi...@childrens.harvard.edu>> wrote: Hi Alex, I don't know what you mean about making it less portable. Basically, the test would run unless it is on Jenkins. I don't know how many people are mirroring all of ctakes and running their own Jenkins builds, but all it means is that the regression test would not run for them. People that are mirroring and running automated builds on something other than Jenkins will face the problem that we have now, but in their own environment they can set the umls parameters. Unless it is public ... As I see it, our problem right now is with Jenkins, so I think that should be our focus. If we (or apache) move to another build/test system then we fix it again at that time. If some other party uses another system then they can handle the problem as they see fit. All that said, you should feel free to tackle this in any manner that you like. I am just offering some thoughts. Sean -----Original Message----- From: Alexandru Zbarcea [mailto:zbarce...@gmail.com<mailto:zbarce...@gmail.com>] Sent: Wednesday, November 15, 2017 4:54 PM To: Apache cTAKES Dev Subject: Re: Disable yTEX and Regression tests on Jenkins [EXTERNAL] Hi Sean, Glad I'm on the right path with assumeTrue, I will come back shortly with a patch for it. Checking for a buildID, would make cTAKES dependent on the Apache build service (Jenkins), making it less portable. I think it would impact adoption for community. What do you think? Alex On Wed, Nov 15, 2017 at 1:36 PM, Finan, Sean < sean.fi...@childrens.harvard.edu<mailto:sean.fi...@childrens.harvard.edu>> wrote: > Hi Alex, > > I like your assumeTrue idea. I think that you wrote about it earlier? > The only problem that I can think of right now is the different ways > that the umls credentials can be supplied. It may be difficult to > check them all. However, maybe just one being available is all that is > needed. > > What about using assumeTrue to check for a Jenkins environment instead > of checking for umls credentials? We could check for a $BUILD_TAG > that starts with "jenkins-" and/or $JENKINS_URL. > > https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.jenkins.io_d > isplay_JENKINS_Building-2Ba-2Bsoftware-2Bproject&d=DwIBaQ&c=qS4goWBT7p > oplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd > 4f7d4gTao&m=BqBNyzBBwKSqP3UmlCFHwNAZDxCKhKoPnfSAzfjbGzI&s=_g-gnJ2P16ag > tG71SgyhcRItc6p_nRgCzSa1UPdWFXM&e= > > > Don't follow my lead ... we'll both get lost. > > Sean > > > -----Original Message----- > From: Alexandru Zbarcea > [mailto:zbarce...@gmail.com<mailto:zbarce...@gmail.com>] > Sent: Wednesday, November 15, 2017 12:41 PM > To: Apache cTAKES Dev > Subject: Re: Disable yTEX and Regression tests on Jenkins [EXTERNAL] > > Hi Sean, > > Your links are very informative. I think using Categories is a great idea. > Categories can also be used to differentiate between tests that require: > DB (MySQL, Oracle, HSQLDB etc) vs non-DB, slow vs fast, UMLS vs non-UMLS. > > In the solution you propose, if I understand right, the discriminator > between running or not running UMLSs tests would be if the category > has been added to the default profile. I wonder if it might not create > the behavior, for the community, to not run some categories of tests. > > What I was thinking is to use Assume.assumeTrue [1] (as a side note, > it can be used together with Categories ) and ignore the execution of > the test if UMLSs account is not setup and enforce to use UMLS if the > realease profile is being used. The reason I say this is because when > the release is going to be built, the owner will be forced to certify that > all tests run. > Just my $0.02. What we can also do, is to create a PR, and upload the > patch, and based on a consensus to apply the patch. > > I will follow your lead on this. What do you think? > Alex > > [1] - > https://urldefense.proofpoint.com/v2/url?u=http-3A__junit. > sourceforge.net_javadoc_org_junit_Assume.html-23assumeTrue-28boolean-2 > 9&d= DwIBaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r= > fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=K0KP_ > M1BTpGUsPOHy6q6q78mS9FKvIj6-B7UEjVOUmc&s=K1pRo0hnemAlUChvke7CvCFXgl7z9 > u > zTgm-oVgSUV6k&e= > > On Wed, Nov 15, 2017 at 10:05 AM, Finan, Sean < > sean.fi...@childrens.harvard.edu<mailto:sean.fi...@childrens.harvard.edu>> > wrote: > > > Hi Alex, > > > > That might work, but I don't know that playing with the release > > profile is the best course of action. I have found a few other > > possibilities. I am leaning toward #3 (@Category) > > > > This approach separates tests into two different directories and > > profiles. It requires a good number of pom changes.: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.testwithspr > > in > > g.com_lesson_running-2D&d=DwIBaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSd > > io > > CoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=K0KP_M1BTpG > > Us > > POHy6q6q78mS9FKvIj6-B7UEjVOUmc&s=IER3aq60g2KOYhWTLp_kCyZBvd4bYMJG0ho > > in > > OcDAKM&e= > > integration-tests-with-maven/ > > which is an update of this: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.petrikainul > > ai > > nen.net_programming_maven_&d=DwIBaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZ > > MS > > dioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=K0KP_M1B > > Tp > > GUsPOHy6q6q78mS9FKvIj6-B7UEjVOUmc&s=99_M-9YUyTCzKBrV5A62i_csb1_NgNlS > > In > > r4UHz1UTQ&e= > > integration-testing-with-maven/ > > > > Another approach looks simpler and more straightforward, using > > filenames for tests and a profile: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__semaphoreci.com > > _c > > ommunity_tutorials_how-2Dto-2Dsplit-2Djunit-2Dtests-2Din-2Da-2D&d=Dw > > IB > > aQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIis > > CY > > NYmQCP6r0bcpKGd4f7d4gTao&m=K0KP_M1BTpGUsPOHy6q6q78mS9FKvIj6-B7UEjVOU > > mc &s=RYlK-TTW_2rK8ckOLjw6rhog5KuCPIr6Obe_h523eXg&e= > > continuous-integration-environment > > Since this could be done with the -regression module alone we > > wouldn't need to rename all unit test files in other modules. > > > > That being said, it looks like junit 4.8 (or earlier?) has @Category > > annotations that can be used: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_juni > > t- > > 2Dteam_junit4_wiki_categories&d=DwIBaQ&c=qS4goWBT7poplM69zy_3xhKwEW1 > > 4J > > ZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=K0KP_ > > M1 > > BTpGUsPOHy6q6q78mS9FKvIj6-B7UEjVOUmc&s=1WDCmSYL50NCHMSCi6nEYXfYnOoUD > > cX > > VfWXY89luqaY&e= > > slightly reworded ...: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__dzone.com_artic > > le > > s_closer-2Dlook-2Djunit-2Dcategories&d=DwIBaQ&c=qS4goWBT7poplM69zy_3 > > xh > > KwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao& > > m= > > K0KP_M1BTpGUsPOHy6q6q78mS9FKvIj6-B7UEjVOUmc&s=nSAIYioeUSIi17JHmiluKl > > q9 > > aqOZ7g1mKNF-bhpr_UQ&e= > > > > Any thoughts on these approaches? > > > > I think that the regression test should be rewritten. It is pretty > > old and doesn't actually test the default clinical pipeline as > > executed by bin/ scripts anymore. > > > > Sean > > > > -----Original Message----- > > From: Alexandru Zbarcea > > [mailto:zbarce...@gmail.com<mailto:zbarce...@gmail.com>] > > Sent: Tuesday, November 14, 2017 7:47 PM > > To: Apache cTAKES Dev > > Subject: Re: Disable yTEX and Regression tests on Jenkins [EXTERNAL] > > > > Hi, > > > > It seems that the patch for the > > org.apache.ctakes.ytex.ConceptDaoTest > > was already provided on CTAKES-334. > > > > Applying the fix passes the test. > > > > The only test that needs to be fixed seems to be: > > RegressionPipelineTest:testCPE. For this, the fix is to export the > > UMLS credentials. > > > > I am currently working on enabling the the test based on the umls > > credentials being available and enforcing the execution on a release > > profile, which now seems to be disabled: > > useReleaseProfile>false</useReleaseProfile > > > > Any feedback? > > Alex > > > > [1] - > > https://urldefense.proofpoint.com/v2/url?u=https-3A__builds. > > apache.org_view_C_view_Apache-2520cTAKES_job_ctakes-2Dtrunk- > > 2Dcompiletest_1124_org.apache.ctakes-24ctakes-2Dregression- > > 2Dtest_testReport_org.apache.ctakes.regression.test_ > > RegressionPipelineTest_testCPE_&d=DwIBaQ&c=qS4goWBT7poplM69zy_ > > 3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gT > > ao > > &m= > > zeyWc75KvsxXPw3cJmG6oF2TBpxrlbOGRwQyh3CZ-eY&s=kgBJTLtXcwxSXuviL2BBBT > > - > > j5xGFN4uLHQbEkzPeww0&e= > > > > > > On Tue, Nov 14, 2017 at 9:47 AM, Gandhi Rajan Natarajan < > > gandhi.natara...@arisglobal.com<mailto:gandhi.natara...@arisglobal.com>> > > wrote: > > > > > Hi Alex, > > > > > > The error we got in ConceptDaoTest is different from yours. We got > > > the > > > following: > > > > > > testCreateConceptGraph(org.apache.ctakes.ytex.ConceptDaoTest): > > > Unable to initialize group definition. Group resource name > > > [classpath*:org/apache/ctakes/ytex/kernelBeanRefContext.xml], > > > factory key [kernelApplicationContext]; nested exception is > > > org.springframework.beans.factory.BeanCreationException: Error > > > creating bean with name 'kernelApplicationContext' defined in URL > > > [file:/D:/Gandhi/ArisG/cTAKES/ctakes_src_new%20-%20Copy/ctak > > > es-ytex-res/src/main/resources/org/apache/ctakes/ > > ytex/kernelBeanRefContext.xml]: > > > Instantiation of bean failed; nested exception is > > > org.springframework.beans.BeanInstantiationException: Could not > > > instantiate bean class [org.springframework.context.s > > > upport.ClassPathXmlApplicationContext]: Constructor threw > > > exception; nested exception is org.springframework.beans. > > factory.BeanCreationException: > > > Error creating bean with name 'gramMatrixExporter' defined in > > > class path resource [org/apache/ctakes/ytex/beans-kernel.xml]: > > > Initialization of bean failed; nested exception is > > org.springframework.beans.FatalBeanException: > > > Failed to obtain BeanInfo for class > > > [org.apache.ctakes.ytex.weka.GramMatrixExporterImpl]; > > > nested exception is java.beans.IntrospectionException: type > > > mismatch between read and write methods > > > > > > Can you do a full build once and try? > > > > > > Regards, > > > Gandhi > > > > > > > > > -----Original Message----- > > > From: Finan, Sean > > > [mailto:sean.fi...@childrens.harvard.edu<mailto:sean.fi...@childrens.harvard.edu>] > > > Sent: Tuesday, November 14, 2017 7:36 PM > > > To: dev@ctakes.apache.org<mailto:dev@ctakes.apache.org> > > > Subject: RE: Disable yTEX and Regression tests on Jenkins > > > [EXTERNAL] > > > > > > Hi Alex, > > > > > > Major kudos for trying to track this down. > > > > > > I am not sure why you are seeing that particular problem. > > > Metadata class should be auto-generated from the type system, and > > > it does have the > > > getPatientIdentifier() method. > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__svn.apache.or > > > g_ > > > re > > > pos_asf_ctakes_trunk_ctakes-2Dtype-2Dsy&d=DwIBaQ&c=qS4goWBT7poplM6 > > > 9z > > > y_ > > > 3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4 > > > gT > > > ao > > > &m=zeyWc75KvsxXPw3cJmG6oF2TBpxrlbOGRwQyh3CZ-eY&s=kWkYEuKO59NQE3OMh > > > tI > > > Yc > > > dGfi0U_56Szw8fxzngfm_0&e= > > > stem/src/main/resources/org/apache/ctakes/typesystem/types/TypeSystem. > > > xml > > > > > > Do you think that it is possible that the jcasgen is not being run > > > before the test? I think that it is run for ctakes-util, which is > > > a dependency for all modules. > > > > > > Regardless, I cannot see where getPatientIdentifier() is used in > > > ConceptDaoTest. I can't see where the class Metadata is used in > > > ConceptDaoTest. From a quick code search, Metadata is only used > > > by the class SourceMetadataUtil in core. SourceMetadataUtil is > > > only used by two classes, both in core. I think that the change > > > in test status is actually unrelated to the Metadata checkin. > > > That being said, I don't have any good idea about what is causing it. > > > > > > Thanks, > > > Sean > > > > > > -----Original Message----- > > > From: Alexandru Zbarcea > > > [mailto:zbarce...@gmail.com<mailto:zbarce...@gmail.com>] > > > Sent: Monday, November 13, 2017 6:24 PM > > > To: Apache cTAKES Dev > > > Subject: RE: Disable yTEX and Regression tests on Jenkins > > > [EXTERNAL] > > > > > > Hi, > > > > > > The official Jenkins job (referenced in the pom.xml) is: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__builds. > > > apache.org_job_ctakes-2Dtrunk_&d=DwIBaQ&c=qS4goWBT7poplM69zy > > > _3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpK > > > Gd4f7d4gTao&m=l0_Tnqk6P-iMIhPUpRO8RiW-eImTKvJDGishYy1Jk-o&s= > > > ul6gCHWXUReDCZccgemrhL9EEFs0Id7WilYITMNr5yw&e=. As one may notice, > > > the status is Unstable. I was working on the cTAKES-trunk-Java-1.8 > > > Jenkins job [1] to try to fix the issues there. As such the tests > > > failed can be found here [2]. > > > > > > So trying to fix one by one, I discovered that for > > > ctakes-ytex:ConceptDaoTest.java:testCreateConceptGraph: > > > > > > There is the construction: > > > metadata.getPatientIdentifier() > > > (where metadata:org.apache.ctakes.typesystem.type.structured. > Metadata). > > > > > > Researching where this comes (because it seems it is a new issue), > > > I realized that is related to: > > > ctakes-type-system/target/generated-sources/jcasgen/org/apac > > > he/ctakes/typesystem/type/structured/Metadata.java > > > :75: public String getPatientIdentifier() { > > > > > > more: > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github. > > > com_apache_ctakes_commit_bcdc25420eede623a0889b1db26e1307a2b > > > 193bf&d=DwIBaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU > > > &r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=l0_Tnqk6P-i > > > MIhPUpRO8RiW-eImTKvJDGishYy1Jk-o&s=c2oayQ5_G3YgHT5iX9AJw9kuh > > > Ir94bFRZ7nxj3ebpuw&e= > > > (10 Oct 2017) > > > > > > I thought that it will be a quick fix just replacing: > > > > > > metadata.getPatientIdentifier() > > > > > > with > > > > > > String.format("%d", metadata.getPatientID()); > > > > > > > > > Any feedback? > > > Alex > > > > > > [1] - > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__builds. > > > apache.org_view_C_view_Apache-2520cTAKES_job_cTAKES-2Dtrunk- > > > 2DJava-2D1.8_&d=DwIBaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdio > > > CoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=l0_ > > > Tnqk6P-iMIhPUpRO8RiW-eImTKvJDGishYy1Jk-o&s=aRH4KLtGndnC-b7UT > > > dMqjej6vTDKxavocQwUokE6EHw&e= > > > [2] - > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__builds. > > > apache.org_view_C_view_Apache-2520cTAKES_job_cTAKES-2Dtrunk- > > > 2DJava-2D1.8_25_testReport_&d=DwIBaQ&c=qS4goWBT7poplM69zy_3x > > > hKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4 > > > f7d4gTao&m=l0_Tnqk6P-iMIhPUpRO8RiW-eImTKvJDGishYy1Jk-o&s=-Pw > > > jGWv5MEFT_1Jui9b27fdgkKfFRa29hts-FMalo8I&e= > > > > > > > > > On Nov 13, 2017 10:41, "Finan, Sean" > > > <sean.fi...@childrens.harvard.edu<mailto:sean.fi...@childrens.harvard.edu>> > > > wrote: > > > > > > > Thanks Gandhi! > > > > > > > > -----Original Message----- > > > > From: Gandhi Rajan Natarajan > > > > [mailto:gandhi.natara...@arisglobal.com<mailto:gandhi.natara...@arisglobal.com>] > > > > Sent: Monday, November 13, 2017 10:40 AM > > > > To: dev@ctakes.apache.org<mailto:dev@ctakes.apache.org> > > > > Subject: RE: Disable yTEX and Regression tests on Jenkins > > > > [EXTERNAL] > > > > > > > > Hi All, > > > > > > > > We had a look at ctakes-Ytex module's failing test cases and > > > > looks like it will not have an impact once we upgrade Spring 4x in > > > > cTAKES. > > > > > > > > We will have a run through at other modules and check the > > > > failing test cases if any. > > > > > > > > Regards, > > > > Gandhi > > > > > > > > > > > > -----Original Message----- > > > > From: Sandeep Byatha Gururaja rao > > > > [mailto:sandeep...@arisglobal.com<mailto:sandeep...@arisglobal.com>] > > > > Sent: Monday, November 13, 2017 6:50 PM > > > > To: dev@ctakes.apache.org<mailto:dev@ctakes.apache.org> > > > > Subject: RE: Disable yTEX and Regression tests on Jenkins > > > > [EXTERNAL] > > > > > > > > Hi Sean, > > > > > > > > Myself and Gandhi will work on this and try to fix the issues. > > > > > > > > Regards, > > > > Sandeep > > > > > > > > ------------------------------------ > > > > > > > > Hi Gandhi, > > > > > > > > Many thanks for volunteering. I am slammed with work right now, > > > > but if anybody else can also help out ... > > > > > > > > Sean > > > > > > > > -----Original Message----- > > > > From: Gandhi Rajan Natarajan > > > > [mailto:gandhi.natara...@arisglobal.com<mailto:gandhi.natara...@arisglobal.com>] > > > > Sent: Thursday, November 09, 2017 12:43 AM > > > > To: dev@ctakes.apache.org<mailto:dev@ctakes.apache.org> > > > > Subject: RE: Disable yTEX and Regression tests on Jenkins > > > > [EXTERNAL] > > > > > > > > Hi Sean, > > > > > > > > I can take it up if someone is willing to guide me on this. > > > > > > > > Regards, > > > > Gandhi > > > > > > > > > > > > -----Original Message----- > > > > From: Finan, Sean > > > > [mailto:sean.fi...@childrens.harvard.edu<mailto:sean.fi...@childrens.harvard.edu>] > > > > Sent: Wednesday, November 08, 2017 9:45 PM > > > > To: dev@ctakes.apache.org<mailto:dev@ctakes.apache.org> > > > > Subject: Disable yTEX and Regression tests on Jenkins > > > > > > > > Hi all, > > > > > > > > The Jenkins builds have been failing for about a month now > > > > because of internal Jenkins changes and 'unit' tests in the > > > > ctakes-Regression and ctakes-yTEX modules. This is holding up > > > > the build for all of our primary clinical-pipeline modules. > > > > > > > > If anybody can take a look at the problems and fix them please > > > > respond to this email. Otherwise I would like to create a jira > > > > issue and disable them until somebody does have the time to take > > > > care > > of them. > > > > If you have a good reason for these tests not being disabled (e.g. > > > > we might forget to fix > > > > them) please state a case. I do not intend to act unilaterally > > > > on this issue. > > > > > > > > Please respond by midnight Friday, November 10. > > > > > > > > Thank you, > > > > > > > > Sean > > > > This email and any files transmitted with it are confidential > > > > and intended solely for the use of the individual or entity to > > > > whom they are > > > addressed. > > > > If you are not the named addressee you should not disseminate, > > > > distribute or copy this e-mail. Please notify the sender or > > > > system manager by email immediately if you have received this > > > > e-mail by mistake and delete this e-mail from your system. If > > > > you are not the intended recipient you are notified that > > > > disclosing, copying, distributing or taking any action in > > > > reliance on the contents of this information is strictly prohibited and > > > > against the law. > > > > > > > > This email and any files transmitted with it are confidential > > > > and intended solely for the use of the individual or entity to > > > > whom they are > > > addressed. > > > > If you are not the named addressee you should not disseminate, > > > > distribute or copy this e-mail. Please notify the sender or > > > > system manager by email immediately if you have received this > > > > e-mail by mistake and delete this e-mail from your system. If > > > > you are not the intended recipient you are notified that > > > > disclosing, copying, distributing or taking any action in > > > > reliance on the contents of this information is strictly prohibited and > > > > against the law. > > > > This email and any files transmitted with it are confidential > > > > and intended solely for the use of the individual or entity to > > > > whom they are > > > addressed. > > > > If you are not the named addressee you should not disseminate, > > > > distribute or copy this e-mail. Please notify the sender or > > > > system manager by email immediately if you have received this > > > > e-mail by mistake and delete this e-mail from your system. If > > > > you are not the intended recipient you are notified that > > > > disclosing, copying, distributing or taking any action in > > > > reliance on the contents of this information is strictly prohibited and > > > > against the law. > > > > > > > This email and any files transmitted with it are confidential and > > > intended solely for the use of the individual or entity to whom > > > they are > > addressed. > > > If you are not the named addressee you should not disseminate, > > > distribute or copy this e-mail. Please notify the sender or system > > > manager by email immediately if you have received this e-mail by > > > mistake and delete this e-mail from your system. If you are not > > > the intended recipient you are notified that disclosing, copying, > > > distributing or taking any action in reliance on the contents of > > > this information is strictly prohibited and against the law. > > > > > >
