opennlp-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aliaksandr Autayeu <aliaksa...@autayeu.com>
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"
(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

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