You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ctakes.apache.org by Tim Miller <ti...@childrens.harvard.edu> on 2013/05/01 15:17:31 UTC

better place for umls credentials

The developer guide lists 3 options for umls credentials, and they all 
have issues:
1) environment variable
     -- tried this one, got errors in .bashrc for illegal variable 
names, maybe it works in windows only
2) vm arguments in run configuration
     -- works, but then you have to add it for every new run configuration
3) edit the descriptor file
     -- runs the risk of accidentally checking in your credentials to svn

I tried setting the values in eclipse.ini, that does not work.

I think now I have stumbled on a decent solution, better than the 
options we've had up till now. If you open windows->preferences in 
eclipse, then select Installed JREs, and select the jre you use and 
click edit. Now a window pops up that lets you put in default VM 
arguments. I put in my UMLS credentials here and that seemed to work. In 
theory this should then work for all run configurations, you shouldn't 
have to re-do it for new run configurations.

Can someone else please verify that this works? And if so should we make 
this the default way to do it in developer setup? Any downsides I'm missing?

Tim

RE: better place for umls credentials

Posted by "Chen, Pei" <Pe...@childrens.harvard.edu>.
I believe there was a patch to also allow underscore in the variable name to avoid bash env name issue: i.e. ctakes_umlsuser instead of ctakes.umlsuser.
I think it would be nice to actually have it reference a secured file.
--Pei

> -----Original Message-----
> From: Tim Miller [mailto:timothy.miller@childrens.harvard.edu]
> Sent: Wednesday, May 01, 2013 9:19 AM
> To: dev@ctakes.apache.org
> Subject: better place for umls credentials
> 
> The developer guide lists 3 options for umls credentials, and they all have
> issues:
> 1) environment variable
>      -- tried this one, got errors in .bashrc for illegal variable names, maybe it
> works in windows only
> 2) vm arguments in run configuration
>      -- works, but then you have to add it for every new run configuration
> 3) edit the descriptor file
>      -- runs the risk of accidentally checking in your credentials to svn
> 
> I tried setting the values in eclipse.ini, that does not work.
> 
> I think now I have stumbled on a decent solution, better than the options
> we've had up till now. If you open windows->preferences in eclipse, then
> select Installed JREs, and select the jre you use and click edit. Now a window
> pops up that lets you put in default VM arguments. I put in my UMLS
> credentials here and that seemed to work. In theory this should then work
> for all run configurations, you shouldn't have to re-do it for new run
> configurations.
> 
> Can someone else please verify that this works? And if so should we make
> this the default way to do it in developer setup? Any downsides I'm missing?
> 
> Tim

Re: better place for umls credentials

Posted by Dmitriy Dligach <dm...@childrens.harvard.edu>.
it worked for me. Thanks!

Dima

On 05/01/2013 09:17 AM, Tim Miller wrote:
> The developer guide lists 3 options for umls credentials, and they all 
> have issues:
> 1) environment variable
>     -- tried this one, got errors in .bashrc for illegal variable 
> names, maybe it works in windows only
> 2) vm arguments in run configuration
>     -- works, but then you have to add it for every new run configuration
> 3) edit the descriptor file
>     -- runs the risk of accidentally checking in your credentials to svn
>
> I tried setting the values in eclipse.ini, that does not work.
>
> I think now I have stumbled on a decent solution, better than the 
> options we've had up till now. If you open windows->preferences in 
> eclipse, then select Installed JREs, and select the jre you use and 
> click edit. Now a window pops up that lets you put in default VM 
> arguments. I put in my UMLS credentials here and that seemed to work. 
> In theory this should then work for all run configurations, you 
> shouldn't have to re-do it for new run configurations.
>
> Can someone else please verify that this works? And if so should we 
> make this the default way to do it in developer setup? Any downsides 
> I'm missing?
>
> Tim