Return-Path: X-Original-To: apmail-ctakes-dev-archive@www.apache.org Delivered-To: apmail-ctakes-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 12915F65B for ; Wed, 1 May 2013 13:56:26 +0000 (UTC) Received: (qmail 41061 invoked by uid 500); 1 May 2013 13:45:21 -0000 Delivered-To: apmail-ctakes-dev-archive@ctakes.apache.org Received: (qmail 40847 invoked by uid 500); 1 May 2013 13:45:11 -0000 Mailing-List: contact dev-help@ctakes.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ctakes.apache.org Delivered-To: mailing list dev@ctakes.apache.org Received: (qmail 40759 invoked by uid 99); 1 May 2013 13:45:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 May 2013 13:45:07 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of Dmitriy.Dligach@childrens.harvard.edu designates 134.174.20.73 as permitted sender) Received: from [134.174.20.73] (HELO mailsmtp3.childrenshospital.org) (134.174.20.73) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 May 2013 13:45:00 +0000 Received: from pps.filterd (mailsmtp3.childrenshospital.org [127.0.0.1]) by mailsmtp3.childrenshospital.org (8.14.5/8.14.5) with SMTP id r41Dfvam026252 for ; Wed, 1 May 2013 09:44:38 -0400 Received: from smtpndc1.chboston.org (smtpndc1.chboston.org [10.20.50.104]) by mailsmtp3.childrenshospital.org with ESMTP id 1c345ag0x0-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 01 May 2013 09:44:38 -0400 Received: from pps.filterd (smtpndc1.chboston.org [127.0.0.1]) by smtpndc1.chboston.org (8.14.5/8.14.5) with SMTP id r41DfAti019336 for ; Wed, 1 May 2013 09:42:37 -0400 Received: from chexhubcas2.chboston.org (internal-ndc-nat-v1260.tch.harvard.edu [10.20.50.4]) by smtpndc1.chboston.org with ESMTP id 1buyg3bafd-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 01 May 2013 09:42:37 -0400 Received: from [10.7.2.244] (10.7.2.244) by email.tch.harvard.edu (10.20.50.93) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 1 May 2013 09:42:37 -0400 Message-ID: <51811BC8.1000005@childrens.harvard.edu> Date: Wed, 1 May 2013 09:42:32 -0400 From: Dmitriy Dligach Organization: Children's Hospital Boston User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Subject: Re: better place for umls credentials References: <518115EB.6070805@childrens.harvard.edu> In-Reply-To: <518115EB.6070805@childrens.harvard.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.2.244] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-05-01_05:2013-04-30,2013-05-01,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-05-01_05:2013-04-30,2013-05-01,1970-01-01 signatures=0 X-Virus-Checked: Checked by ClamAV on apache.org 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