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://wiki.jenkins.io/display/JENKINS/Building+a+software+project Don't follow my lead ... we'll both get lost. Sean -----Original Message----- From: Alexandru Zbarcea [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-29&d=DwIBaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=K0KP_M1BTpGUsPOHy6q6q78mS9FKvIj6-B7UEjVOUmc&s=K1pRo0hnemAlUChvke7CvCFXgl7z9uzTgm-oVgSUV6k&e= On Wed, Nov 15, 2017 at 10:05 AM, Finan, Sean < 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.testwithsprin > g.com_lesson_running-2D&d=DwIBaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdio > CoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=K0KP_M1BTpGUs > POHy6q6q78mS9FKvIj6-B7UEjVOUmc&s=IER3aq60g2KOYhWTLp_kCyZBvd4bYMJG0hoin > OcDAKM&e= > integration-tests-with-maven/ > which is an update of this: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.petrikainulai > nen.net_programming_maven_&d=DwIBaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMS > dioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=K0KP_M1BTp > GUsPOHy6q6q78mS9FKvIj6-B7UEjVOUmc&s=99_M-9YUyTCzKBrV5A62i_csb1_NgNlSIn > 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=DwIB > aQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCY > NYmQCP6r0bcpKGd4f7d4gTao&m=K0KP_M1BTpGUsPOHy6q6q78mS9FKvIj6-B7UEjVOUmc > &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_junit- > 2Dteam_junit4_wiki_categories&d=DwIBaQ&c=qS4goWBT7poplM69zy_3xhKwEW14J > ZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m=K0KP_M1 > BTpGUsPOHy6q6q78mS9FKvIj6-B7UEjVOUmc&s=1WDCmSYL50NCHMSCi6nEYXfYnOoUDcX > VfWXY89luqaY&e= > slightly reworded ...: > https://urldefense.proofpoint.com/v2/url?u=https-3A__dzone.com_article > s_closer-2Dlook-2Djunit-2Dcategories&d=DwIBaQ&c=qS4goWBT7poplM69zy_3xh > KwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao&m= > K0KP_M1BTpGUsPOHy6q6q78mS9FKvIj6-B7UEjVOUmc&s=nSAIYioeUSIi17JHmiluKlq9 > 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] > 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=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gTao > &m= > zeyWc75KvsxXPw3cJmG6oF2TBpxrlbOGRwQyh3CZ-eY&s=kgBJTLtXcwxSXuviL2BBBT- > j5xGFN4uLHQbEkzPeww0&e= > > > On Tue, Nov 14, 2017 at 9:47 AM, Gandhi Rajan Natarajan < > 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] > > Sent: Tuesday, November 14, 2017 7:36 PM > > To: 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.org_ > > re > > pos_asf_ctakes_trunk_ctakes-2Dtype-2Dsy&d=DwIBaQ&c=qS4goWBT7poplM69z > > y_ > > 3xhKwEW14JZMSdioCoppxeFU&r=fs67GvlGZstTpyIisCYNYmQCP6r0bcpKGd4f7d4gT > > ao > > &m=zeyWc75KvsxXPw3cJmG6oF2TBpxrlbOGRwQyh3CZ-eY&s=kWkYEuKO59NQE3OMhtI > > 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] > > 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> > > wrote: > > > > > Thanks Gandhi! > > > > > > -----Original Message----- > > > From: Gandhi Rajan Natarajan > > > [mailto:gandhi.natara...@arisglobal.com] > > > Sent: Monday, November 13, 2017 10:40 AM > > > To: 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] > > > Sent: Monday, November 13, 2017 6:50 PM > > > To: 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] > > > Sent: Thursday, November 09, 2017 12:43 AM > > > To: 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] > > > Sent: Wednesday, November 08, 2017 9:45 PM > > > To: 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. > > >
