Looks good -- approved and ready to merge. Thanks for making these changes. I'm glad to see the addons getting some attention.
Thanks, Jeff On Tue, Sep 8, 2026 at 7:05 PM Kristian Rickert <[email protected]> wrote: > > 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 > > >> > > >> > > > >
