opennlp-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aliaksandr Autayeu <>
Subject Re: proposal to move CLI tools into separate jar
Date Wed, 23 Nov 2011 15:40:57 GMT
> 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"

> 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"


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message