Thanks,
Once it's accepted in main, I'd like to have its first (and perhaps many)
PRs open - not to start the process, but to help figure out how we would
work together for the new process. A get-your-feet-wet approach...
In the meantime, for an initial run as each add-on is implemented, I was
thinking we could use this directory structure:
embeddings/ static, model2vec, quantized, index
lexical/ wordnet, jwnl, expansion
morphology/ morfologik, hunspell, stemmers
geo/ gazetteer, entitylinker
lang/ japanese, cjk
parse/ dependency, annotations, relations
tokenize/ sentencepiece
ml/ liblinear
tools/ modelbuilder
... and more over time
Each directory (static, model2vec, etc) would be a separate PR and add-on
for opennlp. But what you see above is how I'd imagine we update this.
We can always refactor this structure before launch, but it's a good start.
So, the packaging would look like this:
*group id*: org.apache.opennlp.addons
*artifact examples*: embeddings-static, embeddings-model2vec, ml-liblinear,
tools-modelbuilder
So the artifact will follow the {category}-{project} structure.
Regarding the approval process -
- I'll volunteer to help with any buiilds / lead builds for it
- We would want 2 commiters approvals then we can merge?
- High test coverage + manual updates + clean standards
- What happened to our copilot reviews? That would be useful especially
for first time PRs.
Version / release cadence:
- Must be compatible with the latest release.
- Since this isn't always possible, we'll keep a compatibility matrix
on the README (I can offer to maintain it)
- We'll generally keep up with core
- Releases should be more regular for point releases - since it's based
off of core and the addons are independent, we can assume a more regular
schedule
- Mark all new jars as experimental. Untag it after at least some
acceptance (we can track downloads). Once it's accepted, we can remove the
tag. I look forward to this being a problem - it typically never is.
Let me know if there's anything I can do to help.
Kristian
On Tue, Sep 8, 2026 at 2:07 PM Richard Zowalla <[email protected]> wrote:
> Had a quick look. Applied some changes in the current draft PR.
> LGTM.
>
> > Am 08.09.2026 um 17:38 schrieb Kristian Rickert <[email protected]>:
> >
> > I'll have an update shortly - I think you mean trim the manual? The
> README
> > is already pretty small.
> >
> > I only have this here to drive the discussion, it's a big (and smart)!)
> > direction. I'll file a PR for it right after the next push and keep it in
> > draft.
> >
> > This is nowhere near complete. Once we create the PR draft, if everyone
> > agrees, we will focus the convo there. That's not to say we'll ignore
> this
> > thread, just that the system of record for updates should be the PR
> draft.
> >
> > Per Martin's suggestion regarding others and building, I can take on any
> > responsibilities or duties that arise from this.
> >
> >
> > On Tue, Sep 8, 2026 at 9:18 AM Richard Zowalla <[email protected]> wrote:
> >
> >> Can we have this in a PR view plz? So it is possible to review more
> >> cleanly.
> >> I suggest to trim down the README and align the wording to our main
> >> repository.
> >>
> >> In addition, we need to clarify how we handle security or how addons
> >> aligns with the current public available security model.
> >> More over, we should discuss if it needs merge request approval before
> >> pushing into the main branch.
> >>
> >>> Am 08.09.2026 um 15:08 schrieb Kristian Rickert <[email protected]>:
> >>>
> >>> Hey everyone,
> >>>
> >>>
> https://github.com/apache/opennlp-addons/tree/OPENNLP-1924-canary-addon
> >>>
> >>> This is the proposed add-on shape:
> >>>
> >>> * org.apache.opennlp.addons package name for the dependencies
> >>> * separate manual, same format
> >>> * initial cleanup
> >>> * Added a summary of our conversation so far on how we should handle
> it.
> >>> I'll remove it before release...
> >>>
> >>> I'd love to get this going so I can start moving the current branches
> >> into
> >>> addons. I'd have each feature be its own PR. It'll significantly
> clean
> >> up
> >>> the open PRs in the core.
> >>>
> >>> Last, we may want one small PR in core: a consistent way to load SPI
> >>> loaders. Nothing complex, just a simple generic setup.
> >>>
> >>> Kristian
> >>
> >>
>
>
