opennlp-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörn Kottmann <>
Subject Re: proposal to move CLI tools into separate jar
Date Thu, 01 Dec 2011 18:03:05 GMT
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.
> import;
> import;
> 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? :)

>> 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).


View raw message