> > The primary reason is to have proper modularity, out of which follow other >> things. The CLI does not belong to the library, and this should be >> reflected in the structure, to avoid, for example that CLI classes are by >> chance used somewhere in the library. For example, while working in this, >> I >> found the duplicated procedure. Proper code modularization makes one aware >> of such things. >> >> James, thank you for input! >> > > 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. > I usually go to opennlp-tools, do a "mvn clean install" after a code change > there and then type "bin/opennlp ..." to run the cli tools. > With an additional module I need to build it as well, or I have the risk > that > things are out of sync. This out of sync happens once in a while with > maxent. OK, for you this is not comfortable. However, you are a developer, while this refactoring will mostly benefit users, in terms of smaller dependencies. > > and cause more issues; >>> >> Please, can you elaborate on this too? May be there is something I don't >> know. Which issues this can cause? >> > > 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. 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. Aliaksandr
