Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL]
Hi Peter, Thank you for testing! I will see if I can get the mastif-zoner in the distribution and push a 5.1.1 candidate. From: Peter Abramowitsch Sent: Saturday, April 27, 2024 1:48 AM To: dev@ctakes.apache.org Subject: Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] * External Email - Caution * Hi again Sean Perfect Compile Within our context and our pipeline, it runs well. Tried with simple and complex pipelines. I have not used most of the piperRunner/Creator/ scripts. I haven't exercised any of the PBJ stuff yet. I don't use the REST projects or the YTEX DB stuff - we have our own Apart from the missing project I mentioned in the previous email that does need to be fixed, I would give 5.1.0 a plus for release. Peter On Fri, Apr 26, 2024 at 8:41 PM Peter Abramowitsch wrote: > Hi Sean, > > It all compiles, but one of the jars is missing from the distribution. > It's the one I added: ctakes-mastif-zoner which is required if you're > going to use the Zone Annotator. > > It's in the master pom, and in the pom of ctakes-distribution, and the jar > got built in its projecte, but it's not scooped up into the distribution. > I'm not sure where else to look.Can you fix it? > > Peter > > > On Fri, Apr 26, 2024 at 8:59 AM Finan, Sean > wrote: > >> Hi all, >> >> There is a candidate for version 5.1.0 of Apache cTAKES source code in a >> staging repository: >> >> https://urldefense.com/v3/__https://repository.apache.org/content/repositories/staging/org/apache/ctakes/ctakes/5.1.0/__;!!NZvER7FxgEiBAiR_!otrJcgURLIeDrSgLjElYcfJXYPS7d0mMiE8_4tzF072l9casDyG4p1GpjTe3piQ4w3ONCm1ycaUtHLQ5jhEQ3wLwVFpBqoBA6Q$ >> >> The code is contained within the file: >> ctakes-5.1.0-source-release.zip< >> https://urldefense.com/v3/__https://repository.apache.org/content/repositories/staging/org/apache/ctakes/ctakes/5.1.0/ctakes-5.1.0-source-release.zip__;!!NZvER7FxgEiBAiR_!otrJcgURLIeDrSgLjElYcfJXYPS7d0mMiE8_4tzF072l9casDyG4p1GpjTe3piQ4w3ONCm1ycaUtHLQ5jhEQ3wLwVFpmZx3omA$ >> > >> >> I welcome you all to test your favorite pipeline(s) and report any issues. >> I am calling a vote from the PMC to finish by 12:nn Eastern time, next >> Wednesday May 1. Please report any issues before that time. If any >> 'road-block' issues are found they will need to be addressed before a >> release. >> >> Thank you, >> Sean >> >> >> p.s. >> >> The 5.1.0 candidate is based upon the source code in the ctakes-5.1.0 tag: >> https://urldefense.com/v3/__https://github.com/apache/ctakes/releases/tag/ctakes-5.1.0__;!!NZvER7FxgEiBAiR_!otrJcgURLIeDrSgLjElYcfJXYPS7d0mMiE8_4tzF072l9casDyG4p1GpjTe3piQ4w3ONCm1ycaUtHLQ5jhEQ3wLwVFqRzUqi_A$ >> >> The ctakes-5.1.0 tag was made from the 5.1.0 branch: >> https://urldefense.com/v3/__https://github.com/apache/ctakes/tree/5.1.0__;!!NZvER7FxgEiBAiR_!otrJcgURLIeDrSgLjElYcfJXYPS7d0mMiE8_4tzF072l9casDyG4p1GpjTe3piQ4w3ONCm1ycaUtHLQ5jhEQ3wLwVFqL1XNqbA$ >> >> The 5.1.0 branch is a copy of the main branch: >> https://urldefense.com/v3/__https://github.com/apache/ctakes/tree/main__;!!NZvER7FxgEiBAiR_!otrJcgURLIeDrSgLjElYcfJXYPS7d0mMiE8_4tzF072l9casDyG4p1GpjTe3piQ4w3ONCm1ycaUtHLQ5jhEQ3wLwVFrvD9mPJw$ >> The version number in the 5.1.0 branch is different, but there are no >> code differences between the two branches. >> >> >>
Re: Remaining Maven errors visible in Eclipse [EXTERNAL]
Hi Peter,
Thanks again for testing. I didn't have a problem with that ctakes.version in
ytex-web, but I stuck a definition of it in just in case. It does
the same thing as using parent.version, but just in case we ever change the
parent I went with a definition of ctakes.version in the ytex-web pom.
Do you have a listing of the rest of the errors reported by eclipse? I use
Intellij and while I do get a bunch of version warnings I don't get any errors.
I think that ytex-web would need a fair amount of code overhaul to get rid of
them, and unless there is a major demand from the community I don't know that
it is worth doing. Personally, I'd like to put ytex-web in the attic and refer
to ctakes-web-rest as a replacement. Perhaps we can do that in ctakes 6 ?
Thanks,
Sean
From: Peter Abramowitsch
Sent: Sunday, May 5, 2024 4:48 PM
To: dev@ctakes.apache.org
Subject: Remaining Maven errors visible in Eclipse [EXTERNAL]
* External Email - Caution *
Hi Sean, there are some minor 5.1.0 Maven glitches picked up by Eclipse,
one of which I can fix and others not.
in ctakes-ytex-web's pom.xml, I changed *ctakes*.version to *parent*.version.
I have not checked it in, it case it wasn't the right thing to do, but it
made the error go away.
org.apache.ctakes
ctakes-user-resources
${parent.version}
But every pom except the master pom, shows this error:
"Cannot parse lifecycle mapping for maven project Maven Project"
In fact there is no lifecycle mapping file.
I looked at various solutions online and none of them worked, including
creating a dummy mapping and including it in the project - all it did was
insert a blank line between every line of the master pom! *Che palle*, as
they say in Italian
I'm pretty sure it's not my Eclipse installation because my own Maven
projects (admittedly smaller) don't show this error.
Is anyone else seeing a red 'x' error next to every pom in the source tree
in Eclipse?
Eclipse Version: 2023-12 (4.30.0)
M2E - Maven Integration for Eclipse 2.6.0.20240220-1109
org.eclipse.m2e.feature.feature.group Eclipse.org - m2e
Peter
Re: Resending without attachments., [EXTERNAL]
Hi all, I don't think that I have any of the original communications, but just picking up here: * From your dump, it looks as if the main concept dictionary is missing. If you just need the standard dictionary, you can use the information on this ctakes wiki page: https://github.com/apache/ctakes/wiki/cTAKES+UMLS+Package+Fetcher The beginning of that page briefly outlines the UMLS key requirement. If you don't want to build a binary distributable to run the script in bin/ you can execute the class org.apache.ctakes.gui.dictionary.DictionaryDownloader * The dictionary in question is rather dated and intended to be a sample. I found it here: That dictionary is pretty old, and though it contains a lot of standard terms it is not "complete" for every purpose. The dictionary on that github page is a copy of the ctakes dictionary. We had to get specific permission to distribute any part of the umls, so by copying our dictionary in a public repo for redistribution this github group is doing a -bad thing-. Please use the * There are also models you may need, but not have. Models for ctakes are in separate repositories. When you build ctakes from the source obtained on github the models will automatically be downloaded from maven central. Just for an example reference https://central.sonatype.com/artifact/org.apache.ctakes/ctakes-assertion-models * *But first I recommend you get your license key and follow the instructions about how to configure it into the WAR file.* I think that I missed this part of the original communication. I concur with what Peter said: "you will continue to get a rather cryptic resource initialization error until you've passed the API key correctly." For a quick "my first ctakes run", use the piper file submitter gui. https://github.com/apache/ctakes/wiki/Piper+File+Submitter As you can see from the images on the wiki page, the default clinical pipeline does demand a key for the umls. It can be entered on line 4 of the parameter table. You'll notice that the value in the "Option" column, line 4, is "--key". When you run ctakes through a command line, you can add the parameter --key followed by your umls key. This older wiki page has a little information on the key https://cwiki.apache.org/confluence/display/CTAKES/cTAKES+4.0.0.1 Sean From: Peter Abramowitsch Sent: Thursday, May 9, 2024 5:07 PM To: dev@ctakes.apache.org ; joel-paul.jeripoth...@achalahealth.com Subject: Resending without attachments., [EXTERNAL] * External Email - Caution * Shifting this thread back to the main ctakes thread where it belongs... Hi Joel, >From your dump, it looks as if the main concept dictionary is missing. *"No Resource at resources/org/apache/ctakes/dictionary/lookup/fast/sno_rx_16ab/sno_rx_16ab.script"* It's currently configured to run with a standard but older dictionary. But first we need to establish whether you have a UMLS api-key that gives you access to use that vocabulary resource. If not, here's where to begin https://urldefense.com/v3/__https://documentation.uts.nlm.nih.gov/rest/authentication.html__;!!NZvER7FxgEiBAiR_!urKhCyJIGdr9FsV1dFNY3SP-VPO7Yh5yl-4bxLGt8UhOTSuGRzDH3r7uKnMcHT2PLgLFXXjJiV-nntNYRZIDb3yckvI7_OO62A$ The dictionary in question is rather dated and intended to be a sample. I found it here: https://urldefense.com/v3/__https://github.com/CDCgov/NLPWorkbench/blob/master/ctakes-patch/resources/org/apache/ctakes/dictionary/lookup/fast/sno_rx_16ab/sno_rx_16ab.script__;!!NZvER7FxgEiBAiR_!urKhCyJIGdr9FsV1dFNY3SP-VPO7Yh5yl-4bxLGt8UhOTSuGRzDH3r7uKnMcHT2PLgLFXXjJiV-nntNYRZIDb3yckvJQR3Zu_A$ . Once you have your UMLS license you can also download the entire UMLS vocabulary resource onto your machine, then run the cTakes Dictionary Creator application to build the vocabulary you need. It selectively fetches the parts you want from the UMLS files and builds a database for use in cTakes. I think most cTakes users build their own dictionaries after they've become familiar with the application. There are also models you may need, but not have.These large binary objects got shifted when the source was transferred onto GitHub and I'm not sure where they are stored now.Others on this thread will know. *But first I recommend you get your license key and follow the instructions about how to configure it into the WAR file.*I haven't used that module before and it's probably been a decade since I last used apache tomcat. In any case, you will continue to get a rather cryptic resource initialization error until you've passed the API key correctly. I'm about to head off to Europe, so you may need to lean on another resource to get started. That's why I've cc'd the ctakes thread and you can take it from there. Peter
Fw: Please test the Apache cTAKES 5.1.0 release candidate
Hi all, As you may have seen, the last 5.1.0 candidate had some issues. I have created a new 5.1.0 candidate, available here: https://repository.apache.org/content/repositories/staging/org/apache/ctakes/ctakes/5.1.0/ As before, individual module jars up two levels and in associated subdirectories. Hopefully this candidate fares better. Please report any findings before next Monday, May 6th. Thank you, Sean p.s. If you test build any of the rest projects (e.g. ctakes-web-rest) or build an installation with Dockhand, you must first run mvn install. Those builds require ctakes module jars to exist where they can be fetched, and as ctakes 5.1.0 will not be available through maven central before a release, the jars must be in your .m2 directory. From: Finan, Sean Sent: Friday, April 26, 2024 11:58 AM To: dev@ctakes.apache.org Subject: Please test the Apache cTAKES 5.1.0 release candidate Hi all, There is a candidate for version 5.1.0 of Apache cTAKES source code in a staging repository: https://repository.apache.org/content/repositories/staging/org/apache/ctakes/ctakes/5.1.0/ The code is contained within the file: ctakes-5.1.0-source-release.zip<https://repository.apache.org/content/repositories/staging/org/apache/ctakes/ctakes/5.1.0/ctakes-5.1.0-source-release.zip> I welcome you all to test your favorite pipeline(s) and report any issues. I am calling a vote from the PMC to finish by 12:nn Eastern time, next Wednesday May 1. Please report any issues before that time. If any 'road-block' issues are found they will need to be addressed before a release. Thank you, Sean p.s. The 5.1.0 candidate is based upon the source code in the ctakes-5.1.0 tag: https://github.com/apache/ctakes/releases/tag/ctakes-5.1.0 The ctakes-5.1.0 tag was made from the 5.1.0 branch: https://github.com/apache/ctakes/tree/5.1.0 The 5.1.0 branch is a copy of the main branch: https://github.com/apache/ctakes/tree/main The version number in the 5.1.0 branch is different, but there are no code differences between the two branches.
Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL]
; > without tests. > > > > > > > > However, check my previous email about your issue. Whereas you'd > > > narrowed > > > > it down to a script, I found a line in your email which showed the > > error > > > > within that script's execution: A java program: jdl running as > > App.Main > > > > threw an assertion on one of the tasks connected with the mysql > > database > > > it > > > > was trying to configure. You could put some debugging statements in > > > there > > > > to see which one. > > > > > > > > Peter > > > > > > > > On Mon, Apr 29, 2024 at 4:55 AM gandhi rajan < > gandhiraja...@gmail.com> > > > > wrote: > > > > > > > >> Thanks for the insights Peter. I dint make it clear that I did ran > the > > > >> install on ytex module with test case execution toggled off. I used > > the > > > >> following command - "mvn -e clean install -Dmaven.test.skip=true" > and > > I > > > >> still hit the same error. > > > >> > > > >> On digging deep, I could find that the build process is trying to > > > execute > > > >> "" > in > > > >> build-main.xml which in turn is trying to invoke the following > target > > in > > > >> build.setup.xml: > > > >> > > > >> > > >> depends="generateTestYtexProperties,templateToConfig,deleteTestDb"> > > > >> > > > >> > > > >> > > > >> Did you try running this on a fresh setup Peter? > > > >> > > > >> On Sun, 28 Apr 2024 at 01:17, Peter Abramowitsch < > > > pabramowit...@gmail.com > > > >> > > > > >> wrote: > > > >> > > > >> > Hi Gandhi > > > >> > Your error appears to be at this line > > > >> > > > > >> > > > C:\Gandhi\Project\ctakes-5.1.0\ctakes-ytex\scripts\data\build.xml:456: > > > >> Java > > > >> > returned: 1 > > > >> > > > > >> > A test application being run here: AppMain is in charge of > loading > > a > > > >> > temporary mysqldb that is used to test that part of ytex. For me > > it > > > is > > > >> > working, but if you can find a way to run that surefire test in > the > > > >> > debugger, you can find out why it's failing on one of the > > assertions. > > > >> > Otherwise you can take this shortcut > > > >> > > > > >> > mvn -Dmaven.test.skip=true > > > >> > > > > >> > To build the project without running any tests. > > > >> > > > > >> > On Sat, Apr 27, 2024 at 7:35 AM gandhi rajan < > > gandhiraja...@gmail.com > > > > > > > >> > wrote: > > > >> > > > > >> > > Hi Sean, > > > >> > > > > > >> > > When I tried to build the complete ctakes suite, i get build > > failure > > > >> for > > > >> > > ctakes-ytex module with the following error: > > > >> > > > > > >> > > [ERROR] Failed to execute goal > > > >> > > org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run > > > >> > > (generate-test-config) on project ctakes-ytex: An Ant > > BuildException > > > >> has > > > >> > > occured: The following error occurred while executing this line: > > > >> > > [ERROR] > > > >> > > > > > >> > > C:\Gandhi\Project\ctakes-5.1.0\ctakes-ytex\scripts\build-setup.xml:149: > > > >> > The > > > >> > > following error occurred while executing this line: > > > >> > > [ERROR] > > > >> > > > > > C:\Gandhi\Project\ctakes-5.1.0\ctakes-ytex\scripts\data\build.xml:148: > > > >> > The > > > >> > > following error occurred while executing this line: > > > >> > > [ERROR] > > > >> > > > > > C:\Gandhi\Project\ctakes-5.1.0\ctakes-ytex\scripts\data\build.xml:295: > > > >> > The > > > >> > > following error occurred while executing this line: > > > >> > > [ERROR] >
Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL]
Hi Peter, I think that I have the ctakes-mastif-zoner module behavior as desired. Let me know if you have any problems with the new candidate. Sean From: Peter Abramowitsch Sent: Friday, April 26, 2024 11:41 PM To: dev@ctakes.apache.org Subject: Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] * External Email - Caution * Hi Sean, It all compiles, but one of the jars is missing from the distribution. It's the one I added: ctakes-mastif-zoner which is required if you're going to use the Zone Annotator. It's in the master pom, and in the pom of ctakes-distribution, and the jar got built in its projecte, but it's not scooped up into the distribution. I'm not sure where else to look.Can you fix it? Peter On Fri, Apr 26, 2024 at 8:59 AM Finan, Sean wrote: > Hi all, > > There is a candidate for version 5.1.0 of Apache cTAKES source code in a > staging repository: > > https://urldefense.com/v3/__https://repository.apache.org/content/repositories/staging/org/apache/ctakes/ctakes/5.1.0/__;!!NZvER7FxgEiBAiR_!oamc_hHAvz2fBQkEZj8-lyh6rre52BxodrPgl8rcF3RzuF2yd5wK6jstb2HvAuElskKXRnpFZryui_jct7-SQsoWbGZJnsDvVQ$ > > The code is contained within the file: > ctakes-5.1.0-source-release.zip< > https://urldefense.com/v3/__https://repository.apache.org/content/repositories/staging/org/apache/ctakes/ctakes/5.1.0/ctakes-5.1.0-source-release.zip__;!!NZvER7FxgEiBAiR_!oamc_hHAvz2fBQkEZj8-lyh6rre52BxodrPgl8rcF3RzuF2yd5wK6jstb2HvAuElskKXRnpFZryui_jct7-SQsoWbGbgcnIf3Q$ > > > > I welcome you all to test your favorite pipeline(s) and report any issues. > I am calling a vote from the PMC to finish by 12:nn Eastern time, next > Wednesday May 1. Please report any issues before that time. If any > 'road-block' issues are found they will need to be addressed before a > release. > > Thank you, > Sean > > > p.s. > > The 5.1.0 candidate is based upon the source code in the ctakes-5.1.0 tag: > https://urldefense.com/v3/__https://github.com/apache/ctakes/releases/tag/ctakes-5.1.0__;!!NZvER7FxgEiBAiR_!oamc_hHAvz2fBQkEZj8-lyh6rre52BxodrPgl8rcF3RzuF2yd5wK6jstb2HvAuElskKXRnpFZryui_jct7-SQsoWbGYS7mfi0g$ > > The ctakes-5.1.0 tag was made from the 5.1.0 branch: > https://urldefense.com/v3/__https://github.com/apache/ctakes/tree/5.1.0__;!!NZvER7FxgEiBAiR_!oamc_hHAvz2fBQkEZj8-lyh6rre52BxodrPgl8rcF3RzuF2yd5wK6jstb2HvAuElskKXRnpFZryui_jct7-SQsoWbGZACCHJkw$ > > The 5.1.0 branch is a copy of the main branch: > https://urldefense.com/v3/__https://github.com/apache/ctakes/tree/main__;!!NZvER7FxgEiBAiR_!oamc_hHAvz2fBQkEZj8-lyh6rre52BxodrPgl8rcF3RzuF2yd5wK6jstb2HvAuElskKXRnpFZryui_jct7-SQsoWbGaoZVS80g$ > The version number in the 5.1.0 branch is different, but there are no code > differences between the two branches. > > >
Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL]
Hi Gandhi, * So post release I would be able to run mvn clean install on web rest module rather than relying on resources in .m2 folder The opposite. Pre-release there are no jars on maven central, post-release there are. Running 'mvn package' directly on the ctakes-web-rest project (in its directory) or running 'mvn package' on the ctakes -main- project (in the main ctakes root directory) with the web-rest-build profile enabled '-Pweb-rest-build' will build the ctakes-web-rest.war web package. That profile is defined in the main ctakes pom. https://github.com/apache/ctakes/blob/main/pom.xml#L1074 I added a little bit to your instructions in the ctakes-web-rest README https://github.com/apache/ctakes/blob/main/ctakes-web-rest/README The lines here indirectly applies to pre-release builds: https://github.com/apache/ctakes/blob/main/ctakes-web-rest/README#L22 The 5.1.0-SNAPSHOT version of ctakes-web-rest has a dependency on the 5.1.0 version of ctakes modules (not the SNAPSHOT). https://github.com/apache/ctakes/blob/main/ctakes-web-rest/pom.xml#L14 The pre-release basically contains an equivalent to "changed code or resources" in that the code and resources in the pre-release do not exist on maven central, which is where a maven build would normally get them. When maven builds the pre-release it will not be able to find version 5.1.0 of any jars through maven central, so it will look for them in your local .m2 directory. Maven puts the 5.1.0 jars in your .m2 directory when you run 'mvn install' on the main ctakes project. In summary, To build ctakes-web-rest to test the pre-release war, one must run 'mvn install' on the ctakes main project before they run 'mvn package' on the ctakes-web-rest project (or on the main project's web-rest-build profile). To build ctakes-web-rest once ctakes 5.1.0 has been released, the extra preliminary step of running 'mvn install' will not be necessary. * If you have some time this week, we can connect to understand what exactly is the problem. I can meet you tomorrow evening your time (4-7 pm IST) to work with you in the SQL problem. If you'd rather keep your Friday night to yourself, I can work with the same time slot any time through next Monday evening. Before the 6.0.0 release I will put some Release Manager information in the wiki. The maven release process using a GitHub repo requires a little trick that took me a long time to figure out, and the pre-release testing deserves some recorded documentation. Sean From: gandhi rajan Sent: Thursday, May 2, 2024 1:42 AM To: dev@ctakes.apache.org Subject: Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] * External Email - Caution * Hi Sean, Thanks for the update. So post release I would be able to run mvn clean install on web rest module rather than relying on resources in .m2 folder you mean? Infact I was trying to build them on a machine which doesnt have any historic jars in the .m2 folder and thats why it was failing. And ytex issue still remains a mystery to me. If you have some time this week, we can connect to understand what exactly is the problem. On Thu, 2 May 2024 at 02:32, Finan, Sean wrote: > Hi Gandhi, > > I can build the web-rest module. I should have mentioned that to build > any of the rest projects you need to run mvn install. As the rest requires > 5.1.0 module jars and they don't exist externally (pre-release), maven must > be able to fetch them from your .m2 directory. > > I haven't been able to duplicate the ytex problems that you see and don't > know what might be causing them. > > Sean > > > From: gandhi rajan > Sent: Tuesday, April 30, 2024 11:18 AM > To: dev@ctakes.apache.org > Subject: Re: Please test the Apache cTAKES 5.1.0 release candidate > [EXTERNAL] > > * External Email - Caution * > > > Hi Peter, > > Thanks for the response. I dont think the generate test action is trying to > use mysql but hsql DB. Anyways, I am able to build other modules apart from > ytex and ytex-uima module. > > Sean, did you try building ctakes-web-rest module by any chance? It seems > to be broken in my case. > > On Tue, 30 Apr 2024 at 01:28, Peter Abramowitsch > wrote: > > > Hi Gandhi, I think the email from Jeff Painter may explain your > > situation. It's a question of your version of mysql being new. The > > crucial lines in your trace are: > > > > org.apache.ctakes.jdl.AppMain.main(AppMain.java:84) > > [INFO] [java] Caused by: > > java.lang.reflect.InaccessibleObjectException: Unable to make protected > > final java.lang.Class > > java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) throws > > java.lang.ClassFormatError accessible: module java.base does not "opens > >
Re: Mastif Zoner is there now [EXTERNAL]
Hi Peter, I am glad that mastif is now in the distrobution. Yes, testing the pre-release is a little rough, but once released everything is streamlined and -easy-. After the release there shouldn't be any of the funny business of cleaning, grabbing a tag, installing local jars, etc. Thanks again, Sean From: Peter Abramowitsch Sent: Thursday, May 2, 2024 3:11 PM To: dev@ctakes.apache.org Subject: Mastif Zoner is there now [EXTERNAL] * External Email - Caution * Hi Sean I did a clean build, also removing the mastif zoner library from my maven cache. It does get into the distribution now. My git branch got a bit confused when I tried to merge the tag into it. But by destroying my branch and using switch -c to create a new one off the 5.1.0 tag it seemed to do the right thing. I guess when 5.1.0 is merged into main, that won't be an issue Peter
Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] [SUSPICIOUS] [SUSPICIOUS] [SUSPICIOUS]
Hi Tim, Thanks for testing, I'll look into this. Sean From: Miller, Timothy Sent: Tuesday, May 14, 2024 12:55 PM To: dev@ctakes.apache.org Subject: Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] [SUSPICIOUS] [SUSPICIOUS] [SUSPICIOUS] * External Email - Caution * I can check out and build successfully with mvn from the command line. I can successfully open in intellij and run the piper file submitter. I get an error trying to run the default fast pipeline piper file: Loading Piper File DefaultTokenizerPipeline ... Error: MESSAGE LOCALIZATION FAILED: Can't find resource for bundle java.util.PropertyResourceBundle, key No Analysis Component found for ContextDependentTokenizerAnnotator It doesn’t seem to be able to find the ContextDependentTokenizerAnnotator. Tim From: Miller, Timothy Date: Tuesday, May 14, 2024 at 9:25 AM To: dev@ctakes.apache.org Subject: Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] [SUSPICIOUS] [SUSPICIOUS] * External Email - Caution * What would you recommend for testing? Download the release tag to a clean system and try to do mvn compile and run some tests? Tim From: Finan, Sean Date: Thursday, May 2, 2024 at 6:57 AM To: dev@ctakes.apache.org Subject: Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] [SUSPICIOUS] * External Email - Caution * Hi Gandhi, * So post release I would be able to run mvn clean install on web rest module rather than relying on resources in .m2 folder The opposite. Pre-release there are no jars on maven central, post-release there are. Running 'mvn package' directly on the ctakes-web-rest project (in its directory) or running 'mvn package' on the ctakes -main- project (in the main ctakes root directory) with the web-rest-build profile enabled '-Pweb-rest-build' will build the ctakes-web-rest.war web package. That profile is defined in the main ctakes pom. https://urldefense.com/v3/__https://github.com/apache/ctakes/blob/main/pom.xml*L1074__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO4jLXZJfA$<https://urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/pom.xml*L1074__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO4jLXZJfA$><https://urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/pom.xml*L1074__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO4jLXZJfA$%3chttps:/urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/pom.xml*L1074__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO4jLXZJfA$%3e> I added a little bit to your instructions in the ctakes-web-rest README https://urldefense.com/v3/__https://github.com/apache/ctakes/blob/main/ctakes-web-rest/README__;!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO7xPAX45w$<https://urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/ctakes-web-rest/README__;!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO7xPAX45w$><https://urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/ctakes-web-rest/README__;!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO7xPAX45w$%3chttps:/urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/ctakes-web-rest/README__;!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO7xPAX45w$%3e> The lines here indirectly applies to pre-release builds: https://urldefense.com/v3/__https://github.com/apache/ctakes/blob/main/ctakes-web-rest/README*L22__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO77G-Kmpw$<https://urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/ctakes-web-rest/README*L22__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO77G-Kmpw$><https://urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/ctakes-web-rest/README*L22__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO77G-Kmpw$%3chttps:/urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/ctakes-web-rest/README*L22__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO77G-Kmpw$%3e> The 5.1.0-SNAPSHOT version
Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] [SUSPICIOUS] [SUSPICIOUS] [SUSPICIOUS]
Ah - are you just running the class within intellij? If so, you need to set the classpath in the run configuration to be ctakes-examples. Otherwise the classpath doesn't contain anything from modules outside ctakes-gui and ctakes-core. Alternatively, run the maven compile step with the "runPiperGui" profile selected. That will also run the piper file submitter gui with the correct classpath. Using a binary build, after running bin/getUmlsDictionary, running bin/runPiperSubmitter also works. I don't want to do it for 5.1.0, but I should make names of the class, profile and script match. I will check the wiki instructions and make sure that -exact- details are in there. Sean From: Miller, Timothy Sent: Tuesday, May 14, 2024 12:55 PM To: dev@ctakes.apache.org Subject: Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] [SUSPICIOUS] [SUSPICIOUS] [SUSPICIOUS] * External Email - Caution * I can check out and build successfully with mvn from the command line. I can successfully open in intellij and run the piper file submitter. I get an error trying to run the default fast pipeline piper file: Loading Piper File DefaultTokenizerPipeline ... Error: MESSAGE LOCALIZATION FAILED: Can't find resource for bundle java.util.PropertyResourceBundle, key No Analysis Component found for ContextDependentTokenizerAnnotator It doesn’t seem to be able to find the ContextDependentTokenizerAnnotator. Tim From: Miller, Timothy Date: Tuesday, May 14, 2024 at 9:25 AM To: dev@ctakes.apache.org Subject: Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] [SUSPICIOUS] [SUSPICIOUS] * External Email - Caution * What would you recommend for testing? Download the release tag to a clean system and try to do mvn compile and run some tests? Tim From: Finan, Sean Date: Thursday, May 2, 2024 at 6:57 AM To: dev@ctakes.apache.org Subject: Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] [SUSPICIOUS] * External Email - Caution * Hi Gandhi, * So post release I would be able to run mvn clean install on web rest module rather than relying on resources in .m2 folder The opposite. Pre-release there are no jars on maven central, post-release there are. Running 'mvn package' directly on the ctakes-web-rest project (in its directory) or running 'mvn package' on the ctakes -main- project (in the main ctakes root directory) with the web-rest-build profile enabled '-Pweb-rest-build' will build the ctakes-web-rest.war web package. That profile is defined in the main ctakes pom. https://urldefense.com/v3/__https://github.com/apache/ctakes/blob/main/pom.xml*L1074__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO4jLXZJfA$<https://urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/pom.xml*L1074__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO4jLXZJfA$><https://urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/pom.xml*L1074__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO4jLXZJfA$%3chttps:/urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/pom.xml*L1074__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO4jLXZJfA$%3e> I added a little bit to your instructions in the ctakes-web-rest README https://urldefense.com/v3/__https://github.com/apache/ctakes/blob/main/ctakes-web-rest/README__;!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO7xPAX45w$<https://urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/ctakes-web-rest/README__;!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO7xPAX45w$><https://urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/ctakes-web-rest/README__;!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO7xPAX45w$%3chttps:/urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/ctakes-web-rest/README__;!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO7xPAX45w$%3e> The lines here indirectly applies to pre-release builds: https://urldefense.com/v3/__https://github.com/apache/ctakes/blob/main/ctakes-web-rest/README*L22__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO77G-Kmpw$<https://urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/ctakes-web-rest/README*L22__;Iw!!NZvE
Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] [SUSPICIOUS] [SUSPICIOUS] [SUSPICIOUS] [SUSPICIOUS] [SUSPICIOUS]
Thanks Tim! From: Miller, Timothy Sent: Wednesday, May 15, 2024 11:38 AM To: dev@ctakes.apache.org Subject: Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] [SUSPICIOUS] [SUSPICIOUS] [SUSPICIOUS] [SUSPICIOUS] [SUSPICIOUS] * External Email - Caution * Thanks Sean, I was able to get it working – definitely a user/documentation issue and not an issue with the code. Looks like a great release. I’m happy to vote for release +1. Tim From: Finan, Sean Date: Tuesday, May 14, 2024 at 10:35 AM To: dev@ctakes.apache.org Subject: Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] [SUSPICIOUS] [SUSPICIOUS] [SUSPICIOUS] [SUSPICIOUS] * External Email - Caution * Ah - are you just running the class within intellij? If so, you need to set the classpath in the run configuration to be ctakes-examples. Otherwise the classpath doesn't contain anything from modules outside ctakes-gui and ctakes-core. Alternatively, run the maven compile step with the "runPiperGui" profile selected. That will also run the piper file submitter gui with the correct classpath. Using a binary build, after running bin/getUmlsDictionary, running bin/runPiperSubmitter also works. I don't want to do it for 5.1.0, but I should make names of the class, profile and script match. I will check the wiki instructions and make sure that -exact- details are in there. Sean From: Miller, Timothy Sent: Tuesday, May 14, 2024 12:55 PM To: dev@ctakes.apache.org Subject: Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] [SUSPICIOUS] [SUSPICIOUS] [SUSPICIOUS] * External Email - Caution * I can check out and build successfully with mvn from the command line. I can successfully open in intellij and run the piper file submitter. I get an error trying to run the default fast pipeline piper file: Loading Piper File DefaultTokenizerPipeline ... Error: MESSAGE LOCALIZATION FAILED: Can't find resource for bundle java.util.PropertyResourceBundle, key No Analysis Component found for ContextDependentTokenizerAnnotator It doesn’t seem to be able to find the ContextDependentTokenizerAnnotator. Tim From: Miller, Timothy Date: Tuesday, May 14, 2024 at 9:25 AM To: dev@ctakes.apache.org Subject: Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] [SUSPICIOUS] [SUSPICIOUS] * External Email - Caution * What would you recommend for testing? Download the release tag to a clean system and try to do mvn compile and run some tests? Tim From: Finan, Sean Date: Thursday, May 2, 2024 at 6:57 AM To: dev@ctakes.apache.org Subject: Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] [SUSPICIOUS] * External Email - Caution * Hi Gandhi, * So post release I would be able to run mvn clean install on web rest module rather than relying on resources in .m2 folder The opposite. Pre-release there are no jars on maven central, post-release there are. Running 'mvn package' directly on the ctakes-web-rest project (in its directory) or running 'mvn package' on the ctakes -main- project (in the main ctakes root directory) with the web-rest-build profile enabled '-Pweb-rest-build' will build the ctakes-web-rest.war web package. That profile is defined in the main ctakes pom. https://urldefense.com/v3/__https://github.com/apache/ctakes/blob/main/pom.xml*L1074__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO4jLXZJfA$<https://urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/pom.xml*L1074__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO4jLXZJfA$><https://urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/pom.xml*L1074__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO4jLXZJfA$%3chttps:/urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/pom.xml*L1074__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO4jLXZJfA$%3e><https://urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/pom.xml*L1074__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO4jLXZJfA$%3chttps:/urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/pom.xml*L1074__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO4jLXZJfA$%3e%3chttps:/urldefense.com/v3/__https:/github.com/apache/ctakes/blob/main/pom.xml*L1074__;Iw!!NZvER7FxgEiBAiR_!qEC094V4WptTp0dDb8gSoucu-ATor3CRJ8D064AyK511nLCL-ngQkVe-b3Ci3xgtI2BMcKLF1VFuuZZ7Q0sAXaNzpr0cHK4p5MRW6FKEcjQdPO4jLXZJfA$%3chttps:/
Re: Fw: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL]
Hi James, That code is defunct and shouldn't be used. I will take it out for the next release. From: James Masanz Sent: Wednesday, May 15, 2024 4:05 PM To: dev@ctakes.apache.org Subject: Re: Fw: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] * External Email - Caution * Hi all, To get a clean environment, I started a new Windows Sandbox (on Windows 11), installed IntelliJ, and opened the downloaded ctakes sources as a project. Not sure if this was valid to try anymore - I tried to run HelloWorldAggregatePipeline.class directly. I haven't dug into this yet, but in case someone knows offhand - although it completed with an exit code 0 and output a value for Polarity, there is also this message included. ** Error: problem of opening/reading config file: 'file:\C:\Users\Public\cT5\ctakes-5.1.0-source-release\ctakes-5.1.0\ctakes-lvg\target\classes\org\apache\ctakes\lvg\data\config\lvg.properties'. Use -x option to specify the config file path. The lvg.properties file does exist in that directory. The context for that message is below I will do some other testing before I take a look at HelloWorldAggregatePipeline again. - James 15 May 2024 14:44:25 INFO LvgAnnotator - URL for lvg.properties =/C:/Users/Public/cT5/ctakes-5.1.0-source-release/ctakes-5.1.0/ctakes-lvg/target/classes/org/apache/ctakes/lvg/data/config/lvg.properties 15 May 2024 14:44:26 INFO SentenceDetector - Sentence detector model file: org/apache/ctakes/core/models/sentdetect/sd-med-model.zip 15 May 2024 14:44:26 INFO TokenizerAnnotatorPTB - Initializing org.apache.ctakes.core.ae.TokenizerAnnotatorPTB 15 May 2024 14:44:26 INFO LvgCmdApiResourceImpl - Loading NLM Norm and Lvg with config file = file:\C:\Users\Public\cT5\ctakes-5.1.0-source-release\ctakes-5.1.0\ctakes-lvg\target\classes\org\apache\ctakes\lvg\data\config\lvg.properties 15 May 2024 14:44:26 INFO LvgCmdApiResourceImpl - config file absolute path = C:\Users\Public\cT5\ctakes-5.1.0-source-release\ctakes-5.1.0\file:\C:\Users\Public\cT5\ctakes-5.1.0-source-release\ctakes-5.1.0\ctakes-lvg\target\classes\org\apache\ctakes\lvg\data\config\lvg.properties 15 May 2024 14:44:26 INFO LvgCmdApiResourceImpl - cwd = C:\Users\Public\cT5\ctakes-5.1.0-source-release\ctakes-5.1.0 15 May 2024 14:44:26 INFO LvgCmdApiResourceImpl - cd file:\C:\Users\Public\cT5\ctakes-5.1.0-source-release\ctakes-5.1.0\ctakes-lvg\target\classes\org\apache\ctakes\lvg\ ** Configuration Error: file:\C:\Users\Public\cT5\ctakes-5.1.0-source-release\ctakes-5.1.0\ctakes-lvg\target\classes\org\apache\ctakes\lvg\data\config\lvg.properties (The filename, directory name, or volume label syntax is incorrect) ** Error: problem of opening/reading config file: 'file:\C:\Users\Public\cT5\ctakes-5.1.0-source-release\ctakes-5.1.0\ctakes-lvg\target\classes\org\apache\ctakes\lvg\data\config\lvg.properties'. Use -x option to specify the config file path. ** Configuration Error: file:\C:\Users\Public\cT5\ctakes-5.1.0-source-release\ctakes-5.1.0\ctakes-lvg\target\classes\org\apache\ctakes\lvg\data\config\lvg.properties (The filename, directory name, or volume label syntax is incorrect) ** Error: problem of opening/reading config file: 'file:\C:\Users\Public\cT5\ctakes-5.1.0-source-release\ctakes-5.1.0\ctakes-lvg\target\classes\org\apache\ctakes\lvg\data\config\lvg.properties'. Use -x option to specify the config file path. 15 May 2024 14:44:26 INFO LvgCmdApiResourceImpl - cd C:\Users\Public\cT5\ctakes-5.1.0-source-release\ctakes-5.1.0 15 May 2024 14:44:26 INFO ContextDependentTokenizerAnnotator - Finite state machines loaded. 15 May 2024 14:44:26 INFO POSTagger - POS tagger model file: org/apache/ctakes/postagger/models/mayo-pos.zip 15 May 2024 14:44:26 INFO SentenceDetector - Starting processing. 15 May 2024 14:44:26 INFO TokenizerAnnotatorPTB - process(JCas) in org.apache.ctakes.core.ae.TokenizerAnnotatorPTB 15 May 2024 14:44:26 INFO LvgAnnotator - process(JCas) 15 May 2024 14:44:26 INFO ContextDependentTokenizerAnnotator - process(JCas) 15 May 2024 14:44:26 INFO POSTagger - process(JCas) 15 May 2024 14:44:26 INFO ConfigParameterExample - Token:Hello POS:NNP 15 May 2024 14:44:26 INFO ConfigParameterExample - Token:World POS:NNP Entity: Hello === Polarity: 0 Entity: World === Polarity: 0 Process finished with exit code 0 On Wed, May 1, 2024 at 3:55 PM Finan, Sean wrote: > Hi all, > > As you may have seen, the last 5.1.0 candidate had some issues. > > I have created a new 5.1.0 candidate, available here: > > https://urldefense.com/v3/__https://repository.apache.org/content/repositories/staging/org/apache/ctakes/ctakes/5.1.0/__;!!NZvER7FxgEiBAiR_!tLjBU3w09cUeWE4115MKOWDwD6zM9k3Nyn-PlEf6BeifISf-bW5Fe2wZs1f1X42it4dl9D0EwoYgSLc_GZjCIKOkXjw-J_TO$ > > As before, individual module jars up two levels and in associated > subdirectories. > > Hopefully this candidate fares better. Please report any findings before > next Mo
Apache cTAKES 5.1.0 has been released
Hi all, I am pleased to announce that cTAKES 5.1.0 has been officially released. Zip files containing the source code and a binary build are in the Release area on our GitHub site: https://github.com/apache/ctakes/releases/tag/ctakes-5.1.0 cTAKES 5.1.0 jars are also accessible for maven dependencies. For instance, the ctakes-clinical-pipeline: https://central.sonatype.com/artifact/org.apache.ctakes/ctakes-clinical-pipeline The main branch on the GitHub repository now contains version 6.0.0-SNAPSHOT. https://github.com/apache/ctakes Sean
Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL]
Hi Gandhi, Thank you for testing. I have not seen this error but will try to see if I can reproduce it or otherwise diagnose it. Before I build the release candidate I make sure that my build area, maven cache, temp directories, etc. are empty, but maybe I still have something left from a previous build. Sean From: gandhi rajan Sent: Monday, April 29, 2024 7:54 AM To: dev@ctakes.apache.org Subject: Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] * External Email - Caution * Thanks for the insights Peter. I dint make it clear that I did ran the install on ytex module with test case execution toggled off. I used the following command - "mvn -e clean install -Dmaven.test.skip=true" and I still hit the same error. On digging deep, I could find that the build process is trying to execute "" in build-main.xml which in turn is trying to invoke the following target in build.setup.xml: Did you try running this on a fresh setup Peter? On Sun, 28 Apr 2024 at 01:17, Peter Abramowitsch wrote: > Hi Gandhi > Your error appears to be at this line > > C:\Gandhi\Project\ctakes-5.1.0\ctakes-ytex\scripts\data\build.xml:456: Java > returned: 1 > > A test application being run here: AppMain is in charge of loading a > temporary mysqldb that is used to test that part of ytex. For me it is > working, but if you can find a way to run that surefire test in the > debugger, you can find out why it's failing on one of the assertions. > Otherwise you can take this shortcut > > mvn -Dmaven.test.skip=true > > To build the project without running any tests. > > On Sat, Apr 27, 2024 at 7:35 AM gandhi rajan > wrote: > > > Hi Sean, > > > > When I tried to build the complete ctakes suite, i get build failure for > > ctakes-ytex module with the following error: > > > > [ERROR] Failed to execute goal > > org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run > > (generate-test-config) on project ctakes-ytex: An Ant BuildException has > > occured: The following error occurred while executing this line: > > [ERROR] > > C:\Gandhi\Project\ctakes-5.1.0\ctakes-ytex\scripts\build-setup.xml:149: > The > > following error occurred while executing this line: > > [ERROR] > > C:\Gandhi\Project\ctakes-5.1.0\ctakes-ytex\scripts\data\build.xml:148: > The > > following error occurred while executing this line: > > [ERROR] > > C:\Gandhi\Project\ctakes-5.1.0\ctakes-ytex\scripts\data\build.xml:295: > The > > following error occurred while executing this line: > > [ERROR] > > C:\Gandhi\Project\ctakes-5.1.0\ctakes-ytex\scripts\data\build.xml:456: > Java > > returned: 1 > > [ERROR] around Ant part ... > target="test.setup">... @ 5:70 in > > C:\Gandhi\Project\ctakes-5.1.0\ctakes-ytex\target\antrun\build-main.xml > > > > Is this expected Sean? > > > > On Fri, 26 Apr 2024 at 21:30, Finan, Sean > > wrote: > > > > > Hi all, > > > > > > There is a candidate for version 5.1.0 of Apache cTAKES source code in > a > > > staging repository: > > > > > > > > > https://urldefense.com/v3/__https://repository.apache.org/content/repositories/staging/org/apache/ctakes/ctakes/5.1.0/__;!!NZvER7FxgEiBAiR_!o1HhLIOtrhbcq3eWO7A8MyQs9yWveCrI0nWVqT7mgYPonu6AeAo8EI3Jpj0RSGZ-cVwLwf44oOtMoJQCtSuifMhxRi5BTyzwGA$ > > > > > > The code is contained within the file: > > > ctakes-5.1.0-source-release.zip< > > > > > > https://urldefense.com/v3/__https://repository.apache.org/content/repositories/staging/org/apache/ctakes/ctakes/5.1.0/ctakes-5.1.0-source-release.zip__;!!NZvER7FxgEiBAiR_!o1HhLIOtrhbcq3eWO7A8MyQs9yWveCrI0nWVqT7mgYPonu6AeAo8EI3Jpj0RSGZ-cVwLwf44oOtMoJQCtSuifMhxRi48T86umQ$ > > > > > > > > > > I welcome you all to test your favorite pipeline(s) and report any > > issues. > > > I am calling a vote from the PMC to finish by 12:nn Eastern time, next > > > Wednesday May 1. Please report any issues before that time. If any > > > 'road-block' issues are found they will need to be addressed before a > > > release. > > > > > > Thank you, > > > Sean > > > > > > > > > p.s. > > > > > > The 5.1.0 candidate is based upon the source code in the ctakes-5.1.0 > > tag: > > > https://urldefense.com/v3/__https://github.com/apache/ctakes/releases/tag/ctakes-5.1.0__;!!NZvER7FxgEiBAiR_!o1HhLIOtrhbcq3eWO7A8MyQs9yWveCrI0nWVqT7mgYPonu6AeAo8EI3Jpj0RSGZ-cVwLwf44oOtMoJQCtSuifMhxRi7ofZf95w$ > > > > > > The ctakes-5.1.0 tag was made from the 5.1.0 branch: > > >
Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL]
Hi Gandhi, Peter, I am on Windows and the tests work fine. They must all run for the release phases. Peter, I found the problem. In the candidate the -distribution bin definition was missing mastif-zoner. I added it and all looks good except that the xml files aren't there. I am putting them in a src/user/resources/ directory to match other projects and adding all of the requisites for that paradigm. That will copy them to resources/ in a source compile / package and binary distribution zip(s). It will place them in the ctakes-user-resources.jar for use as a dependency in maven projects. --> If you would rather they be in the mastif-zoner jar then that isn't a problem, just let me know and I'll do it that way. Sean From: Peter Abramowitsch Sent: Monday, April 29, 2024 11:50 AM To: dev@ctakes.apache.org Subject: Re: Please test the Apache cTAKES 5.1.0 release candidate [EXTERNAL] * External Email - Caution * I think this is the class where Java is exiting with 1 /ctakes-ytex/src/test/java/org/apache/ctakes/jdl/AppMainTest.java btw my environment is MacOS and I notice yours is Windows, so the root cause why this class is giving you trouble is something I wouldn't be able to help you with. But some debug statements rather than asserts would tell you, I think. Peter On Mon, Apr 29, 2024 at 8:43 AM Peter Abramowitsch wrote: > Hi Gandhi > This project is an odd one in the sense that when you tell it to skip the > tests, it still goes through the effort in building up the db environment > that the tests would use. But in any case, for me it does build either > way. In the attached log, I've run a maven clean before doing the build > without tests. > > However, check my previous email about your issue. Whereas you'd narrowed > it down to a script, I found a line in your email which showed the error > within that script's execution: A java program: jdl running as App.Main > threw an assertion on one of the tasks connected with the mysql database it > was trying to configure. You could put some debugging statements in there > to see which one. > > Peter > > On Mon, Apr 29, 2024 at 4:55 AM gandhi rajan > wrote: > >> Thanks for the insights Peter. I dint make it clear that I did ran the >> install on ytex module with test case execution toggled off. I used the >> following command - "mvn -e clean install -Dmaven.test.skip=true" and I >> still hit the same error. >> >> On digging deep, I could find that the build process is trying to execute >> "" in >> build-main.xml which in turn is trying to invoke the following target in >> build.setup.xml: >> >> > depends="generateTestYtexProperties,templateToConfig,deleteTestDb"> >> >> >> >> Did you try running this on a fresh setup Peter? >> >> On Sun, 28 Apr 2024 at 01:17, Peter Abramowitsch > > >> wrote: >> >> > Hi Gandhi >> > Your error appears to be at this line >> > >> > C:\Gandhi\Project\ctakes-5.1.0\ctakes-ytex\scripts\data\build.xml:456: >> Java >> > returned: 1 >> > >> > A test application being run here: AppMain is in charge of loading a >> > temporary mysqldb that is used to test that part of ytex. For me it is >> > working, but if you can find a way to run that surefire test in the >> > debugger, you can find out why it's failing on one of the assertions. >> > Otherwise you can take this shortcut >> > >> > mvn -Dmaven.test.skip=true >> > >> > To build the project without running any tests. >> > >> > On Sat, Apr 27, 2024 at 7:35 AM gandhi rajan >> > wrote: >> > >> > > Hi Sean, >> > > >> > > When I tried to build the complete ctakes suite, i get build failure >> for >> > > ctakes-ytex module with the following error: >> > > >> > > [ERROR] Failed to execute goal >> > > org.apache.maven.plugins:maven-antrun-plugin:3.1.0:run >> > > (generate-test-config) on project ctakes-ytex: An Ant BuildException >> has >> > > occured: The following error occurred while executing this line: >> > > [ERROR] >> > > >> C:\Gandhi\Project\ctakes-5.1.0\ctakes-ytex\scripts\build-setup.xml:149: >> > The >> > > following error occurred while executing this line: >> > > [ERROR] >> > > C:\Gandhi\Project\ctakes-5.1.0\ctakes-ytex\scripts\data\build.xml:148: >> > The >> > > following error occurred while executing this line: >> > > [ERROR] >> > > C:\Gandhi\Project\ctakes-5.1.0\ctakes-ytex\scrip
Re: Upgrade to JDK 17 Inquiry [EXTERNAL]
Hi Ryan, I have recently been working on upgrades to ctakes focused around vulnerability mitigation, so your question is very timely. The current version in the github master branch https://github.com/apache/ctakes , 6.0.0-SNAPSHOT, should build and run with java 17. I don't know of any plans to upgrade ctakes to java 22 any time soon. Please try the 6.0.0-SNAPSHOT with jdk17 and let me know if you have any problems. If you can contribute to the current ctakes vulnerability mitigation effort in any way, such as by providing a list of your exceptions, please do. Thanks, Sean From: Ryan Swenson Sent: Wednesday, July 3, 2024 3:39 PM To: dev@ctakes.apache.org Subject: Upgrade to JDK 17 Inquiry [EXTERNAL] * External Email - Caution * Hello, We have a major application using Apache cTakes for standardizing clinical laboratory results which has been running on Java 8, and we have had to operate with a security exception, and are now where we will need to assess if we can migrate to Java 17 or ultimately migrate entirely to a new paradigm and approach. Has anyone assessed the effort, are there any breaking changes or compatibility issues, or dependency versioning conflicts that need to be addressed to achieve an upgrade to running under Java 17 and soon, 22? We are in favor of upgrading but we can only maintain the security exception for so long, and are now at a point where if it its either too large of an effort, or a ways out from achieving, we will need to migrate soon. Thanks, Ryan
Re: [EXTERNAL] Upgrade to JDK 17 Inquiry
Hi John, Would you be able to share some of the changes that you needed to make for 21? Thanks, Sean From: Petersam, John Contractor Sent: Wednesday, July 3, 2024 3:45 PM To: dev@ctakes.apache.org Subject: RE: [EXTERNAL] Upgrade to JDK 17 Inquiry * External Email - Caution * Hi Ryan, I'm on Java 21 and will migrate to 23 when it comes out. I upgraded it years ago, so I don't remember all the specifics of what I changed. It's not that difficult, but does require making some code modifications as well as updating some dependencies so you will definitely need to roll up your sleeves a bit. Thanks, John -Original Message- From: Ryan Swenson Sent: Wednesday, July 03, 2024 3:40 PM To: dev@ctakes.apache.org Subject: [EXTERNAL] Upgrade to JDK 17 Inquiry Hello, We have a major application using Apache cTakes for standardizing clinical laboratory results which has been running on Java 8, and we have had to operate with a security exception, and are now where we will need to assess if we can migrate to Java 17 or ultimately migrate entirely to a new paradigm and approach. Has anyone assessed the effort, are there any breaking changes or compatibility issues, or dependency versioning conflicts that need to be addressed to achieve an upgrade to running under Java 17 and soon, 22? We are in favor of upgrading but we can only maintain the security exception for so long, and are now at a point where if it its either too large of an effort, or a ways out from achieving, we will need to migrate soon. Thanks, Ryan
Re: [EXTERNAL] Upgrade to JDK 17 Inquiry
Hi John, Thank you for the information. I didn't realize that hsqldb had changed its format again. I will keep that in mind if and when another dictionary is released. Sean From: Petersam, John Contractor Sent: Friday, July 5, 2024 9:21 AM To: dev@ctakes.apache.org Subject: RE: [EXTERNAL] Upgrade to JDK 17 Inquiry * External Email - Caution * Hi Sean, I don't believe the migration from 17 to 21 required any changes at all. The big change was getting to 13, and I did that back when 13 came out. The only changes I've made to stay current since then are general library updates. The only one I haven't been able to update is hsqldb because 2.7.3 isn't compatible with the files created with 2.3.4. I'm planning on updating those in the August/September timeframe so I can check that box as well. Thanks, John -Original Message- From: Finan, Sean Sent: Wednesday, July 03, 2024 3:57 PM To: dev@ctakes.apache.org Subject: Re: [EXTERNAL] Upgrade to JDK 17 Inquiry Hi John, Would you be able to share some of the changes that you needed to make for 21? Thanks, Sean From: Petersam, John Contractor Sent: Wednesday, July 3, 2024 3:45 PM To: dev@ctakes.apache.org Subject: RE: [EXTERNAL] Upgrade to JDK 17 Inquiry * External Email - Caution * Hi Ryan, I'm on Java 21 and will migrate to 23 when it comes out. I upgraded it years ago, so I don't remember all the specifics of what I changed. It's not that difficult, but does require making some code modifications as well as updating some dependencies so you will definitely need to roll up your sleeves a bit. Thanks, John -Original Message- From: Ryan Swenson Sent: Wednesday, July 03, 2024 3:40 PM To: dev@ctakes.apache.org Subject: [EXTERNAL] Upgrade to JDK 17 Inquiry Hello, We have a major application using Apache cTakes for standardizing clinical laboratory results which has been running on Java 8, and we have had to operate with a security exception, and are now where we will need to assess if we can migrate to Java 17 or ultimately migrate entirely to a new paradigm and approach. Has anyone assessed the effort, are there any breaking changes or compatibility issues, or dependency versioning conflicts that need to be addressed to achieve an upgrade to running under Java 17 and soon, 22? We are in favor of upgrading but we can only maintain the security exception for so long, and are now at a point where if it its either too large of an effort, or a ways out from achieving, we will need to migrate soon. Thanks, Ryan
Re: SLF4J instead of Log4J at the API level? [EXTERNAL]
> The main branch still uses ContextSingletonBeanFactoryLocator
...
It looks like I had made a replacement a while ago for other instances of this
problem, but had somehow missed those two tests. Consider it done.
> For example in AssertionAnalysisEngine:
Oh, those. From the days of yor. Garbage imo. I get rid of them whenever I
find them.
>should be replaced by `getLogger().`
Right now I want to get vulnerabilities remediated and then get a release out
with that focus. After that, some "play nice, refactor" release involving
things like using uima api getLogger() as well as code consolidation, generics
(how archaic are we?), modern collections and streams ...
Cheers,
Sean
From: Richard Eckart de Castilho
Sent: Monday, July 29, 2024 4:09 PM
To: dev@ctakes.apache.org
Subject: Re: SLF4J instead of Log4J at the API level? [EXTERNAL]
* External Email - Caution *
Hi,
> On 29. Jul 2024, at 12:02, Finan, Sean
> wrote:
>
> - The main branch still uses ContextSingletonBeanFactoryLocator which is not
> part of Spring anymore and thus the Eclipse has compiler errors
> -- I can look for an appropriate replacement.
I briefly googled and I'm note sure if there is a proper direct replacement for
this. It looks like you're still using XML-based Spring configuration there.
Maybe using Spring Java-Config would be more sensible nowadays.
> - Many calls to the logging use String.format or similar means to construct
> the logged string. This can be done better using the SLF4J API,
> e.g. `debug("{} is less than {}", x, y)` or `error("This is an error, ex)`.
> I did not upgrade all these calls.
> -- Though I like to be a boy scout (and I noticed your if/then braces!), I
> don't expect anybody to make this code minty-fresh. It is nice that slf4j
> has this capability.
Maybe if I'm bored ;) Or maybe somebody else feels like it.
> - I commented out some calls to directly configure the logging system -
> instead there should be `log4j2-test.xml` files or similar configuration
> files for slf4j-simple used for testing.
> -- I couldn't find these in the modified files. Do you recall where they
> were - or for that matter, why they were?
For example in AssertionAnalysisEngine:
https://urldefense.com/v3/__https://github.com/apache/ctakes/blob/837666cc2f8d25520255886e9525feeeb9510fbd/ctakes-assertion/src/main/java/org/apache/ctakes/assertion/medfacts/AssertionAnalysisEngine.java*L287__;Iw!!NZvER7FxgEiBAiR_!qx0-fe8dC60hk-itqClF2maIsPjLQh0tOznHEcnBrbH3lwJf_fWe9Q14Y5vuUljMFP4eAk2YyBH6oTe3Cw2edQ$
> - Calls to SLF4J in UIMA components should be replaced by `getLogger().`
> - I did this in some cases
> -- Here I am ignorant. What is the advantage, and do you think that it is
> important enough to warrant a global find/replace? If so then I can give it
> a shot.
Since UIMA already supplies a logging mechanism for the components, I would
tend to using it. Internally, that is by default also routed through SLF4J.
Theoretically, a user of the components might re-configure UIMA to route the
logging differently for their particular environment. You could also argue
that you prefer using the same logging API throughout the entire code. So while
I say "should", it is arguable and you might come to a different conclusion
than I do.
> - It would IMHO be a good idea to introduce the maven-dependency-plugin to
> ensure that all packages used have direct non-transitive Maven dependencies
> and there are no unused dependencies
> -- Are you talking about the analyze goal? I suppose that we could add it
> to a phase for automatic execution.
Yep, that one exactly.
-- Richard
Re: Build cTAKES using GitHub action? [EXTERNAL]
I am pretty sure that nobody would mind ... The great thing about version control is that what has been done can always be undone. From: Richard Eckart de Castilho Sent: Monday, July 29, 2024 3:38 PM To: dev@ctakes.apache.org Subject: Re: Build cTAKES using GitHub action? [EXTERNAL] * External Email - Caution * > On 29. Jul 2024, at 12:14, Finan, Sean > wrote: > >> Btw. how about setting up a GitHub action for building cTAKES? > > I thought about that when we switched over from svn. I didn't do it myself > because I am happy with Jenkins. Right, I honestly forgot that there's Jenkins. I guess that's because I didn't see Jenkins badges on the PRs: * https://urldefense.com/v3/__https://github.com/apache/ctakes/pull/21__;!!NZvER7FxgEiBAiR_!qsgb8wTFlVoBS9VU86JKrNyrbAQfAQd4MZIEkmpDyK3h10xw0SEz1iNheVt5Z6JaJB4XtWER6vxs-6jITDLAuw$ Cf. * https://urldefense.com/v3/__https://github.com/apache/uima-uimaj/pull/370__;!!NZvER7FxgEiBAiR_!qsgb8wTFlVoBS9VU86JKrNyrbAQfAQd4MZIEkmpDyK3h10xw0SEz1iNheVt5Z6JaJB4XtWER6vxs-6id7fIEbg$ I can see you're still using "traditional" UI-configured Jenkins jobs instead of Jenkins pipelines that are managed in the version control. Would you mind if I set up a pipeline build that can handle PRs for cTAKES by copying the approach I have taken in UIMA? See also: * https://urldefense.com/v3/__https://ci-builds.apache.org/job/UIMA/job/uima-uimaj/__;!!NZvER7FxgEiBAiR_!qsgb8wTFlVoBS9VU86JKrNyrbAQfAQd4MZIEkmpDyK3h10xw0SEz1iNheVt5Z6JaJB4XtWER6vxs-6i67BviWg$ * https://urldefense.com/v3/__https://ci-builds.apache.org/job/UIMA/configure__;!!NZvER7FxgEiBAiR_!qsgb8wTFlVoBS9VU86JKrNyrbAQfAQd4MZIEkmpDyK3h10xw0SEz1iNheVt5Z6JaJB4XtWER6vxs-6hzipOuGA$ * https://urldefense.com/v3/__https://ci-builds.apache.org/job/UIMA/job/uima-uimaj/configure__;!!NZvER7FxgEiBAiR_!qsgb8wTFlVoBS9VU86JKrNyrbAQfAQd4MZIEkmpDyK3h10xw0SEz1iNheVt5Z6JaJB4XtWER6vxs-6j88KBB1w$ That approach is using a shared repo that contains the actual pipeline configuration which is used by all UIMA sub-projects. I'd probably temporarily use that for cTAKES as well but it should eventually be cloned to a separate repo for cTAKES. * https://urldefense.com/v3/__https://github.com/apache/uima-build-jenkins-shared-library/tree/main__;!!NZvER7FxgEiBAiR_!qsgb8wTFlVoBS9VU86JKrNyrbAQfAQd4MZIEkmpDyK3h10xw0SEz1iNheVt5Z6JaJB4XtWER6vxs-6iYqO2wXQ$ Cheers, -- Richard
Re: SLF4J instead of Log4J at the API level? [EXTERNAL]
Hi Richard,
Many, many thanks for doing this. I gave it a pass and don't see anything that
looks like it might cause a problem. I will run some tests. My comments on
your comments:
- The lifecycle plugin in the root POM uses "version" instead of "versionRange"
in the main branch - the PR fixes that
-- That sounds good to me.
- The main branch still uses ContextSingletonBeanFactoryLocator which is not
part of Spring anymore and thus the Eclipse has compiler errors
-- I can look for an appropriate replacement.
- Many calls to the logging use String.format or similar means to construct the
logged string. This can be done better using the SLF4J API,
e.g. `debug("{} is less than {}", x, y)` or `error("This is an error, ex)`. I
did not upgrade all these calls.
-- Though I like to be a boy scout (and I noticed your if/then braces!), I
don't expect anybody to make this code minty-fresh. It is nice that slf4j has
this capability.
- I commented out some calls to directly configure the logging system - instead
there should be `log4j2-test.xml` files or similar configuration files for
slf4j-simple used for testing.
-- I couldn't find these in the modified files. Do you recall where they were
- or for that matter, why they were?
- Calls to SLF4J in UIMA components should be replaced by `getLogger().` -
I did this in some cases
-- Here I am ignorant. What is the advantage, and do you think that it is
important enough to warrant a global find/replace? If so then I can give it a
shot.
- It would IMHO be a good idea to introduce the maven-dependency-plugin to
ensure that all packages used have direct non-transitive Maven dependencies and
there are no unused dependencies
-- Are you talking about the analyze goal? I suppose that we could add it to
a phase for automatic execution.
Cheers,
Sean
From: Richard Eckart de Castilho
Sent: Friday, July 26, 2024 8:36 PM
To: dev@ctakes.apache.org
Subject: Re: SLF4J instead of Log4J at the API level? [EXTERNAL]
* External Email - Caution *
Hi Sean,
i have set up an initial PR here:
https://urldefense.com/v3/__https://github.com/apache/ctakes/pull/21__;!!NZvER7FxgEiBAiR_!rOgnJ7H15Yz2Yhom0R9PmwVVqB8yO-_DzBI5-d-yDg0laTqSxcT1vW91vTLO1RYQk42IoHdn3V3MbcEQHKLmJw$
However, there are a few issues:
- The lifecycle plugin in the root POM uses "version" instead of "versionRange"
in the main branch - the PR fixes that
- The main branch still uses ContextSingletonBeanFactoryLocator which is not
part of Spring anymore and thus the Eclipse has compiler errors
- Many calls to the logging use String.format or similar means to construct the
logged string. This can be done better using the SLF4J API,
e.g. `debug("{} is less than {}", x, y)` or `error("This is an error, ex)`. I
did not upgrade all these calls.
- I commented out some calls to directly configure the logging system - instead
there should be `log4j2-test.xml` files or similar
configuration files for slf4j-simple used for testing.
- Calls to SLF4J in UIMA components should be replaced by `getLogger().` -
I did this in some cases
- It would IMHO be a good idea to introduce the maven-dependency-plugin to
ensure that all packages used have direct non-transitive
Maven dependencies and there are no unused dependencies
Cheers,
-- Richard
Re: Build cTAKES using GitHub action? [EXTERNAL]
> Btw. how about setting up a GitHub action for building cTAKES? I thought about that when we switched over from svn. I didn't do it myself because I am happy with Jenkins. It also seems like quite the beast to romp around in a GH action. I suppose that we could have build profiles that only compile the basic modules that are in the default clinical pipeline and things like that. Even without that, I don't think that we'd have problems with the infra rules https://infra.apache.org/github-actions-policy.html I don't place that as a high priority, but if anybody else does then I say "go for it". https://infra.apache.org/github-actions-secrets.html Sean From: Richard Eckart de Castilho Sent: Friday, July 26, 2024 8:45 PM To: dev@ctakes.apache.org Subject: Build cTAKES using GitHub action? [EXTERNAL] * External Email - Caution * Btw. how about setting up a GitHub action for building cTAKES? -- Richard
Apache cTAKES, java jdk 17 and UIMA 3
Hi all, The ctakes version 6.0.0-SNAPSHOT in the main GitHub branch https://github.com/apache/ctakes has been upgraded to be compatible with java 17 and Uima 3. Please test your favorite workflows and let me know if you have any problems. I would like to get an -update- release out soon. This would be a release with no new functionality, just updates to bring ctakes into this decade. Note: If you are using IntelliJ and already have ctakes as a project you may experience a problem with the classes in the type system not being found. To remedy this, after you update you may need to click the "Generate Sources and Update Folders for all Projects." button in the maven window (folder with circle/reload icon). Then a clean compile should allow a run to find generated types. Sean Sean Finan Research Computing Principal Engineer Computational Health Informatics Program, Natural Language Processing Lab Boston Children's Hospital sean.fi...@tch.harvard.edu
Re: SLF4J instead of Log4J at the API level? [EXTERNAL]
Hi Richard, I have thought of that, and almost did as much. I think that main pom still has a bunch of slf4j dependencies commented out from my time in the sandbox. There are only some very minor reasons that I didn't, one being the ease of the transition. I have nothing against slf4j, and using an abstraction layer does make a lot of sense. Would you be willing to do some refactoring? I have to move over and work on some other items today - mainly ctakes on apache beam (plus spark, flink ...). Something for the next 'new features' release. Sean From: Richard Eckart de Castilho Sent: Thursday, July 25, 2024 8:40 PM To: dev@ctakes.apache.org Subject: SLF4J instead of Log4J at the API level? [EXTERNAL] * External Email - Caution * Hi Sean, > On 25. Jul 2024, at 16:15, seanfi...@apache.org wrote: > > The following commit(s) were added to refs/heads/main by this push: > new 1556d13 Replaced all logging with log4j2 , including java and > commons-logging Removed or pushed back a few dependencies. If I saw it correctly, you are making direct calls to the log4j2 API. Have you considered using SLF4J 2.x as your API and log4j2 as the logging backend instead? If would facilitate embedding cTAKES in contexts that use a different logging backend than log4j2. Cheers, -- Richard
Re: SLF4J instead of Log4J at the API level? [EXTERNAL]
t; project from a former developer and now ( lol, have a task of figuring out > how to run our pipeline with correct classpath given several filesystem > located dependencies, properties, and scattered local vs maven built > libs). After building successfully, and assuming it will run fine, Java 17 > is a go, and is currently permitted by our InfoSec. > > My organization then did an OWASP Security Scan of the 6.0.0 branch with > our 1 added module inside our own Git Repo, and there was reported 1417 > vulnerabilities. I will be happy to share both the JSON files of this > report, and share a Python script ( you can modify and/or use) to review. > > Essentially, there were 41 unique packages which have a host of security > vulnerabilities. Module wise, if I remove Smoking Status, User Resources, > GUI, Tiny REST, and FHIR modules, I end up with 1190 vulnerabilities ( 227 > less from 1417). > > There were 13 "packages" libraries with 732 (135 Critical, 250 High, 0 > Low) vulnerabilities where I deemed these a lower level of effort, because > their higher library versions provide backward compatibility and they are > able to run with Java 6 or later, or wont have any issues running with Java > 17. For these, I will simply specify their later versions in the pom, and > re-build. There were another 9 libraries which I labeled medium which have > 77 (46 Critical, 20 High, 10 Medium, 1 Low), due to likely having some > potential breaking changes, which will require code changes, testing, & > regressions. Finally, there were 19 libraries with 381 vulnerabilities (10 > Critical, 178 High, 157 Medium, 36 Low) where either there was no higher > version, requiring an alternative library and requiring code changes, or > there were higher versions which offer no backward compatibility with > breaking changes. > > - Examples: guava 10 to 32, if any @beta APIs were used, and/or methods > which were used are overloaded in the later v32, we will have work cut out > for us in refactoring. > - Domj 1.61 is EOL, thus JDOM, JAXB, StAX should be considered, but now > require refactoring -log4j 1.2.17 is EOL - Log4J2 or SLF4J should be > considered, requiring refactoring > > However, its important to point out that the security report does include > a column reflecting which module/pom each package / vulnerability is being > reported so that 1) I can assess if this is with our custom code, or 2) > with cTakes distro, and 3) with my knowledge of our code, what of #2 our > module has co-dependence on - this will likely lead to some discovery of > where we rely on less than actually what we build with, to further reduce > effort, but there will still be the fact that there are issues which were > reported under #2. > > If I shared this report, is there some concerted effort I or we together > could help to address these? At present, we have a raised exception which > we have extended to now, and likely will have some leniency due to where I > can in the interim perform the Java 8 to Java 17 upgrade, address the 732 > vulnerabilities with low LOE - updating poms with higher versions with > minimal risk of breaking changes, and possibly address some of the mediums, > and now only have the subset of vulnerabilities left - 381. > > In the meantime, I am copying runnable jars & working scripts setting the > classpaths from other envs, to our dev env to get runnable code, and triage > the differences between our envs, and then I will be in a place where I can > start committing changes to our git, and test with build updates. > > Thanks, > Ryan > > > > > > > > > > > > > > > -Original Message- > From: Finan, Sean > Sent: Friday, July 26, 2024 9:35 AM > To: dev@ctakes.apache.org > Subject: Re: SLF4J instead of Log4J at the API level? [EXTERNAL] > > Hi Richard, > > I have thought of that, and almost did as much. I think that main pom > still has a bunch of slf4j dependencies commented out from my time in the > sandbox. There are only some very minor reasons that I didn't, one being > the ease of the transition. I have nothing against slf4j, and using an > abstraction layer does make a lot of sense. Would you be willing to do > some refactoring? I have to move over and work on some other items today - > mainly ctakes on apache beam (plus spark, flink ...). Something for the > next 'new features' release. > > Sean > > > From: Richard Eckart de Castilho > Sent: Thursday, July 25, 2024 8:40 PM > To: dev@ctakes.apache.org > Subject: SLF4J instead of Log4J at the API level? [EXTERNAL] > > * External Email - Caution * > > > Hi Sean, > > > On 25. Jul 2024, at 16:15
Re: SLF4J instead of Log4J at the API level? [EXTERNAL]
Stated more succinctly than my babble! From: Richard Eckart de Castilho Sent: Friday, July 26, 2024 12:06 PM To: dev@ctakes.apache.org Subject: Re: SLF4J instead of Log4J at the API level? [EXTERNAL] * External Email - Caution * Hi, > On 26. Jul 2024, at 12:42, Peter Abramowitsch wrote: > > The log4j team themselves say that bundling property files inside > distributed jars is good practice and it took a while to track this down. > Should we officially remove them from the ctakes-core build? IMHO: Logging configuration files can be bundled at the level of an application distribution but they should not be bundled in JARs that could be used as library dependencies. I'm not too familiar with the cTAKES distribution, but assuming there is a ZIP distribution with some command line or UI tools - that should have a logging configuration. The actual JARs that do the work, e.g. the UIMA components etc. - they should not have a logging configuration file. You can have test logging configurations in the `src/test/resources` folders though. -- Richard
Re: Error running Apache cTakes Pipeline [EXTERNAL]
Hi Ryan, As far as I know, none of the [xyz] code that you are referencing comes from ctakes. You probably need to find out where that code came from - hopefully your organization has a good relationship with the previous developer or there is a user in your organization who is familiar with that code and its purpose. It is possible that there are comments in the scripts and/or code under the xyz directory that can point you in the correct direction. A web search for `ctakes "xyzapp"` came up empty, but that is as far as I went. It is possible that somebody else monitoring this mailing list knows something about xyzapp. You could try writing or reposting with "What is XYZAPP" and see if it catches an eye. Good luck, Sean From: Ryan Swenson Sent: Tuesday, July 30, 2024 2:21 PM To: dev@ctakes.apache.org Subject: RE: Error running Apache cTakes Pipeline [EXTERNAL] * External Email - Caution * It appears one key differences now between Dev (code errors ) and Prod(code runs) envs is that in the CTAKES_HOME variable inside a script for the Java Class Path, there is a -cp path to: /opt/xyzapp/nlp/c-takes/nlp/apache-ctakes-src/ctakes-distribution/target/apache-ctakes-4.0.0.1/lib which is present in Prod and not in Dev... This subfolder contains a bin directory, which contains : ant, ant.bat, OpenCmd.bat, runctakesCPE.bat , and matching .sh scripts Do you know if there is some build step in which the apache 4.0.0.1 binary is supposed to be pulled down in combo with the source code, and/or what is accounting for why this is not present in our Dev system but is in Prod? Thanks, Ryan From: Ryan Swenson Sent: Tuesday, July 30, 2024 1:31 PM To: dev@ctakes.apache.org Subject: Error running Apache cTakes Pipeline Hello, I currently inherited an existing Apache cTakes Pipeline Application from a previous developer who is no longer with the parent organization I am supporting in the Molecular Genetics space. The organization has a built and runnable code, running on a scheduled basis in production. Separately, in a Development environment we are wanting to address defects, add new features, and also address security exceptions and vulnerabilities which we can later QA and roll into Production. At the moment in Development we are experiencing an error in trying to run our Apache cTakes pipeline with the same sources and binaries taken from prod. Both Dev and Prod are using Maven 3.9.8 for building and JDK 8 for build and execution. The specific error (some info redacted for sensitivity , some for brevity) is: Exception in thread "main" org.apache.uima.resource.ResourceInitializationException: Initialization of CAS Processor with name "XYZ Aggregate Engine" failed. Caused by: org.apache.uima.resource.ResourceInitializationException: Initalization of annotator class "com.xyz.XyzSetenceRegexAnnotator" failed. (Descriptor: file:/opt/xyzapp/scripts/resources/cTakes/desc/XyzSetenceRegexAnnotator.xml) ... 8 more Caused by: org.springframework.beans.factory.access.BootstrapException: Unable to initialize group definition. Group resource name [classpath* org/apache/ctakes/ytex/uima/beanRefContext.xml]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name "ytexApplicationContext" defined in URL [jar: /opt/xyzapp/nlp/nlp-c-takes/apache-ctakes-4.00.1-src/ctakes-distribution/target/apache-ctakes-4.0.0.1-jar-with-dependencies.jar!/org/apache/ytex/uima/beanRefContext.xml]: Instantiation of bean failed Unable to locate Spring NamespaceHandler for XML schema namespace [https://urldefense.com/v3/__http://www.springframework.org/schema/aop__;!!NZvER7FxgEiBAiR_!q1DN4cI8AqQiOYzffEQr625-fRyUn3ZuW9_2n4rAETRIkSMGENqaMIBQfEl4r_7OaqvNdKJygrKyc-LnobM08r-8RDQVhnqr$ ] offending resource: class path resource [org/apache/ctakes/ytex/beans-kernel.xml] ...41 more ... To execute I run: Java -cp "/opt/xyzapp/scripts/resources/*:/opt/xyzapp/nlp/nlp-c-takes/apache-ctakes-4.0.0.1-src/ctakes-distribution/target/* -Dorg.apache-ctakes.ytex.conceptGraphDir='pwd' org.xyz.pipeline.RunCPE /opt/xyzapp/scripts/resources/cTakes/CPEDescriptor.xml I experience this error, if I take the apache-ctakes-4.0.0.1-jar-with-dependencies.jar from Prod where the pipeline is successfully running and place it in the target dir, and I also experience it if I build in the development environment, and use the apache-ctakes-4.0.0.1-jar-with-dependencies.jar produced in this target directory. I am also evaluating if the Production shell scripts used for setting environment variables, paths, and the Java class path is the same ( which I suspect is not). If anyone can provide me with more clues or advice on this, I would greatly appreciate it. The cTakes portion of this application and pipeline is 1 of 4x separate applications, and if we are able to run/build cTakes we will be able to proceed with maintaining the
Re: Error running Apache cTakes Pipeline [EXTERNAL]
Hi Ryan, It sounds like you just need to unpack the distributable version of ctakes. After you run "maven package" you should have the large zip files in the ctakes-dist/target/ directory. You want one without "-src" in its name. Unzip that file into a new directory outside of the source directory. The files that come out of the zip are the ctakes installation - all of the libraries, scripts, and data that you need. Unless you are developing you can now ignore the source code directories. You can also download the zip file directly, without building through maven. Here are the instructions for installing the ctakes binary. https://cwiki.apache.org/confluence/display/CTAKES/cTAKES+4.0+User+Install+Guide If you are able, I advise that you update to ctakes 5.1.0 after you have confirmed that 4.0.0.1 works in your dev. https://github.com/apache/ctakes/releases/tag/ctakes-5.1.0 Sean From: Ryan Swenson Sent: Wednesday, July 31, 2024 1:32 PM To: dev@ctakes.apache.org Subject: RE: Error running Apache cTakes Pipeline [EXTERNAL] * External Email - Caution * Hi Sean, I was able to run the pipeline yesterday afternoon. Here is how, and still a little baffled: 1) There is a noticeable difference in the built code environments in Dev and Prod: In Prod, under the exploded apache cTakes 4.0.01 src directory, is the module ctakes-distribution with a target/ctakes-4.0.0.1/lib directory with all of the maven library jar files, and above this path directly under the target directory, are the cTakes core Jar, tar.gz, zips that were generated. In Dev, there is no /target/ctakes-4.0.0.1 sub-directory, instead only the core jar, tar gz, zips that were generated. 2) I was able to run the cTakes pipeline only after I updated the class path to include /opt/apache-ctakes-4.0.0.1-src/ctakes-distribution/target/ctakes-4.0.0.1/lib/*, in addition to a location where we store all of the desc, dictionaries, hibernate connection properties, etc, and only after I copied the /target/ctakes-4.0.0.1-core-with-dependencies.jar into the /opt/apache-ctakes-4.0.0.1-src/ctakes-distribution/target/ctakes-4.0.01/lib/ path, now, the code runs perfectly fine. If I do not copy the core jar to this location, it cannot load the primary class which begins running the CPE processing to read the CPE descriptor file. Now I need to likely create a new empty directory, expand source here, copy in our module + updated pom, and build to verify what got populated into the target sub-directory under ctakes-distribution. If I only produce the jars, then there is some missing build step, or otherwise missing details that I will need to figure out, to ensure we can build new code, and then run this code. Yes - this xyzApp is a proprietary code module we wrote, and it is dependent on the other underlying out of the box cTake modules. Thanks, Ryan -Original Message----- From: Finan, Sean Sent: Wednesday, July 31, 2024 11:39 AM To: dev@ctakes.apache.org Subject: Re: Error running Apache cTakes Pipeline [EXTERNAL] Hi Ryan, As far as I know, none of the [xyz] code that you are referencing comes from ctakes. You probably need to find out where that code came from - hopefully your organization has a good relationship with the previous developer or there is a user in your organization who is familiar with that code and its purpose. It is possible that there are comments in the scripts and/or code under the xyz directory that can point you in the correct direction. A web search for `ctakes "xyzapp"` came up empty, but that is as far as I went. It is possible that somebody else monitoring this mailing list knows something about xyzapp. You could try writing or reposting with "What is XYZAPP" and see if it catches an eye. Good luck, Sean From: Ryan Swenson Sent: Tuesday, July 30, 2024 2:21 PM To: dev@ctakes.apache.org Subject: RE: Error running Apache cTakes Pipeline [EXTERNAL] * External Email - Caution * It appears one key differences now between Dev (code errors ) and Prod(code runs) envs is that in the CTAKES_HOME variable inside a script for the Java Class Path, there is a -cp path to: /opt/xyzapp/nlp/c-takes/nlp/apache-ctakes-src/ctakes-distribution/target/apache-ctakes-4.0.0.1/lib which is present in Prod and not in Dev... This subfolder contains a bin directory, which contains : ant, ant.bat, OpenCmd.bat, runctakesCPE.bat , and matching .sh scripts Do you know if there is some build step in which the apache 4.0.0.1 binary is supposed to be pulled down in combo with the source code, and/or what is accounting for why this is not present in our Dev system but is in Prod? Thanks, Ryan From: Ryan Swenson Sent: Tuesday, July 30, 2024 1:31 PM To: dev@ctakes.apache.org Subject: Error running Apache cTakes Pipeline Hello, I currently inherited an existing Apache cTakes Pipelin
