Also - my thoughts on the open pieces: 1. *(Core) Annotation layers* heavily strengthen the API and allow for add-ons. This strengthens the add-ons argument as it's 100% an API feature. Almost no PRs are useful without this landing. (OPENNLP-1888) 2. *(Core) SentencePiece inference*: OPENNLP-1885 (#1165) - same as annotations. Without it, sentence features don't have a good home. Embeddings become weakened. Cascades into the other embedding features. It's an interface, so a good home and like annotations, strengthens the argument for add-ons. 3. *(Core) Dependency parser* - because why rely on python? It's always bothered me that when I used OpenNLP to hybrid java and python. it's confusing, and makes me want to just use Python. This removed that dependency ( OPENNLP-547 (#1236) ). 4. *(Should be core - can be add-on - better off core) CJK dictionary tokenization*: OPENNLP-1894 (#1191) - I focused so hard on UTF as a precursor for this. 1/2 the world works in the CJK space, as an Apache project I'd imagine we want that reach. Not only would we be more popular - it widens the language market and will attract CJK native programmers to help us. We need that help - and this is how we can attract contributors. Not just a good feature, but a popularity and recruitment tool. 5. *(Separate jar) Verified resource installer*: OPENNLP-1909 (#1211) - core but maybe it's own entity. It's not even an NLP feature. Add-on or separate JAR. Interface in core, downloaders in add-ons.
Add on considerations: CJK can be an add-on, but why limit support only to English/Euro languages? Document analysis falls apart early in the parsing stages - you can't analyze what's going on if tokens are noisy. This can help so many fields and feels more like a first-class feature than an add-on. This can help LLM translations and search engines alike. On Tue, Aug 25, 2026 at 7:22 PM Kristian Rickert <[email protected]> wrote: > Great points all around. I'd like to address them and get some clarity > regarding dependencies. > > *Dependencies* > > Currently, none of the open or draft PRs introduce new dependencies. For > core, this leaves us with just ONNX and Lucene, which makes total sense. > That won't change. > > I agree that addons *could* be a good place to allow new dependencies, > provided we use them sparingly. When they are necessary, we should use an > SPI service loader over an interface so that accepting them becomes a > startup-pluggable decision. Since none of the current open PRs require new > dependencies, I am completely fine with a rule allowing zero new > dependencies for now. > > *gRPC PR* > > The gRPC PR does bring in netty, and I think early on we all agreed to > make it a separate build anyway. It is currently in a Proof of Concept > (PoC) status, it does not belong in core. > > For the server dependencies, I chose vanilla Netty because it is fast, > reference-standard, and widely adopted. > > Whenever I introduce a new dependency, I follow the SPI loading approach > used by Quarkus and Micronaut: create a service interface with a pure JDK > default implementation (e.g., saving to disk instead of S3), but provide > interfaces for optional storage layers like S3 or Azure. I would eventually > like to offer the ability to save trained models from the server to S3, > Azure, or Google Cloud via a thin repository service layer, keeping > everything dependent on gRPC interfaces to avoid other dependencies. > > > *Downloads & Hosting Models* > LEGAL-732 <https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-732> > cleared up our current limitations, and none of the PRs are breaking so > far, so we should use that as our guideline. For new models, as long as we > follow those rules, we can use the downloader > <https://github.com/apache/opennlp/pull/1211> or host models that we > train. Since that PR is open, we can address any downloader concerns > directly there. > > Regarding hosting models, I have a dozen or so ideas for new models we > could host, but I would love some guidance on how we should go about that. > > I am a big fan of the addons approach as long as the jars are pushed to > Maven Central so they are actually usable. > > Thoughts? > > Best regards, > Kristian > >
