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
