Mailing-List: contact opennlp-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: opennlp-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of kottmann@gmail.com designates
 209.85.214.47 as permitted sender)
Message-ID: <4ED7C159.3050002@gmail.com>
Date: Thu, 01 Dec 2011 19:03:05 +0100
From: =?UTF-8?B?SsO2cm4gS290dG1hbm4=?= <kottmann@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: opennlp-dev@incubator.apache.org
Subject: Re: proposal to move CLI tools into separate jar
References: 
 <CAGWxipQoAsib-MO+EqCd_N7qGbgT=2mX2ihyqMqfEHBGc0Wa_g@mail.gmail.com>
 <4ECCE0BE.7020406@gmail.com>
 <CAGWxipQVp8H8LSxtR4nFwAU8zeUVpx-FiTQmjC+1W3cJ7tuDJQ@mail.gmail.com>
 <4ECCF5D4.9010303@gmail.com>
 <CAGWxipQwgmhuzprjZAyeL76AmnfYccTx4b-FvzyhkVjp0pQavA@mail.gmail.com>
 <4ECD0833.1080104@gmail.com>
 <CAGWxipRQxnn8+47GbFJRLLWaNTboV8hMyRMOCrcwWV20U54EDA@mail.gmail.com>
 <4ECD1653.9030201@gmail.com>
 <CAGWxipQCrTtbmCtPS5ybsbfcT2=m4L0Dkr5ytEa1FbQteHEKkg@mail.gmail.com>
 <4ECD58A2.4010302@gmail.com> <4ECDC543.1090705@gmail.com>
 <CAGWxipQ5Gai5KNctr1tghf+w-LQ9jWsWc_xc0f=QHn-XDx+o6g@mail.gmail.com>
 <4ECE43CA.6060206@gmail.com>
 <CAGWxipT0i7DUzOuzPu8U-E9NmZda4KeJWRoTS8pCR9U1Fw+wHA@mail.gmail.com>
In-Reply-To: 
 <CAGWxipT0i7DUzOuzPu8U-E9NmZda4KeJWRoTS8pCR9U1Fw+wHA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 12/1/11 6:32 PM, Aliaksandr Autayeu wrote:
>> Do you have a sample here? As far as I know we almost don't have
>> dependencies
>> on the CLI package from other classes, expect for the formats package.
>>
> Yes. POSTaggerCrossValidator.java
>
> import opennlp.tools.cmdline.CmdLineUtil;
> import opennlp.tools.cmdline.TerminateToolException;
>
> Why it does that? To throw a TerminateToolException it does not need to
> throw anyway. If it is easy to make a dependency, they will creep in.


Nice that you fixed that one :)

>> Having three separate jar files (maxent, tools, cli) can cause issues when
>> the
>> versions are incompatible (maybe someone forget to update maxent),
>> you need to put it three times on your class path, you can get issues
>> with inter-module code changes, an additional step in the build which can
>> go wrong, etc.
>>
>> Additionally I once in a while use the cli stuff to do testing in my
>> UIMA-AS system.
>> There it is just handy that the cli stuff is on my server by default.
>>
> OK, so that's one more inconvenience. By the way, is it a good practice to
> do this way? I would install a proper binary installation which is provided
> and use a script. Own dog food kind of thing.
>
> I do not think that deploying commad-line utilities in a web application
> lib folder is a good idea. It's like having an executable script in a
> webapp, and hoping nobody will never discover and use it. That might seems
> difficult to exploit, because you don't know how, but if you don't have
> such tools on the classpath, there will not be even a potential exploit.

I don't see the security issue here. If you are able to inject code into 
a JVM,
you probably do other things than using our command line tools, e.g.
stealing something which gets processed by OpenNLP, reading/writing files,
trying to get root rights on that machine, etc.

>
> Well, we are still missing a few commands I wish to have on my server, e.g.
>> show me the version of a model.
> I just go inside and look into the description, but I use Far and its
> transparent handling of archives makes this easy to do, but using a console
> that might be less convenient. Again, differences in tools and development
> practices. By the way, why not creating a JIRA for this idea? :)
>

+1
>
>> We don't have any examples, but if we would have some, they should be
>> distributed as source files. Because the whole point of having them is
>> that people can read and copy them.
> Yes, I understand this. And in addition it could be helpful to have a
> script, which executes them and does a demo.

Yes, but for demo we have the tools which can load a model and read
text from the console.

Anyway are really missing a web demo, which we can add to our website 
(jira already exist).

Jörn