Eclipse does have built-in Maven support, which (at least in the Kepler build) works fine for me.
..Michael On May 2, 2014, at 8:47 PM, Debbie Zhang <debbie.d.zh...@gmail.com> wrote: > Thanks Alexandre for your reply! > > I will try extJWNL as suggested. As I have never used maven, may I ask which > maven Eclipse plugin you use? > > Thanks again for your help! > > Regards, > > Debbie > > >> -----Original Message----- >> From: Alexandre Patry [mailto:alexandre.pa...@keatext.com] >> Sent: Saturday, 3 May 2014 12:13 AM >> To: user@uima.apache.org >> Subject: Re: RandomAccessFile problem in UIMA >> >> Hi Debbie, >> >> I recommend you to use extJWNL (https://github.com/extjwnl/extjwnl) >> instead of JWNL. We made the switch from JWNL and never looked back. >> >> For your path problems, extJWNL distribute WordNet dictionaries as >> maven dependencies. It should become a non-issue. >> >> Hope this help, >> >> Alexandre >> >> On 02/05/2014 03:36, Debbie Zhang wrote: >>> Hi, >>> >>> >>> >>> I am having problems to use JWNL wordnet in UIMA. >>> >>> >>> >>> JWNL uses RandomAccessFile to read wordnet dictionary files. In order >>> to create a PEAR file, wordnet dictionary files are put in >>> resources/wordnet folder under project. As resources is in my Build >>> Path, I have no problem to run the application I created in Eclipse. >>> Therefore, I am certain the dictionary files can be read. However, >>> when I use UIMA Document Analyzer or UIMA CAS Visual Debugger to run >> the annotation, I get the following error: >>> >>> >>> >>> java.io.FileNotFoundException: resources/wordnet/data.noun (No such >>> file or >>> directory) >>> >>> >>> >>> The error comes from the following code: >>> >>> >>> >>> RandomAccess _file = new RandomAccessFile(path, _permissions); >>> >>> >>> >>> I use the following code to check the current working directory of >> the >>> class: >>> >>> >>> >>> URL location = >>> >> PrincetonRandomAccessDictionaryFile.class.getProtectionDomain().getCod >>> eSourc >>> e().getLocation(); >>> >>> System.out.println(location.getFile()); >>> >>> >>> >>> It seems both situation have the same location: /project/bin/ >>> >>> >>> >>> Did anyone encounter a similar problem before? Any suggestion is >> welcome. >>> Thank you! >>> >>> >>> >>> Regards, >>> >>> >>> >>> Debbie >>> >>> >>> >>> >> >> >> -- >> Alexandre Patry, Ph.D >> Chercheur / Researcher >> http://KeaText.com > >
