> That is true for all our components. Someone use only the name finder, > then he > don't needs the parser. > Yes, might be the case.
> Lets say for a moment we do it as proposed. > Then we break with our current separation strategy which relies on java > packages. > Why should we break with this for only the cli stuff? > Yes. It's a fairly common practice, like "gzip" (cli tool) and "zlib" (library). > Wouldn't that be an inconsistent decision? > No. Having more or less modularization does not make it inconsistent. One does not have to extreme. To me, inconsistent here would be breaking a single package in two jars. Or mixing independent things into one jar (e.g. maxent). But even this sometimes is fine: unit tests are in the same package, but separate dirs and jars. > Only java package separation, modules > only for strong reasons: > opennlp-tools (contains ml code also) > opennlp-uima > ML code seems strong enough reason to me :) It might be replaced\augmented later on, as was already mentioned. Or as proposed: > opennlp-maxent > opennlp-tools > opennlp-cli (depends on the former) > opennlp-uima > +1 :) > With the same arguments to create the cli module > we could end up with something like this: > opennlp-maxent > opennlp-tokenizer > opennlp-sentdetect > opennlp-namefind > opennlp-parser > Might. But one does not have to go to the extreme. Again, take a look at the common practice of "gzip" (cli tool) and "zlib" (library). Aliaksandr
