Hijacking this thread a bit and feel free to tell me this belongs in a new thread --- HJow do we feel about docbook today? The docbook-xml 5.0-all artifact that opennlp-docs depends on was released on Jul 20, 2009. I find editing the XML to be difficult and error prone compared to something like markdown files. docbook does integrate well into the build and website though.
I think the project put off moving to a newer docs system over the years due to the amount of manual re-writing required, but perhaps today an AI agent could help make that an easier transition. I don't know what newer documentation systems are out there or what's the "standard" for a Java library like OpenNLP but I'm open to learning. Thanks, Jeff On Thu, Sep 17, 2026 at 8:26 AM Kristian Rickert <[email protected]> wrote: > > I'll make all the changes in one branch, each commit will become a PR. No > more than 2 PRs at a time. If anyone wants to add to the branch, feel > free. The branch itself won't become a PR. > > On Thu, Sep 17, 2026 at 6:33 AM Richard Zowalla <[email protected]> wrote: > > > Hi, > > > > would go for small units and PRs. > > Much easier to review, imho. > > > > Gruß > > Richard > > > > > Am 17.09.2026 um 11:30 schrieb Kristian Rickert <[email protected]>: > > > > > > Hi Team, > > > > > > I plan to make a controlled set of updates to the DocBook. To avoid > > > flooding our communication channels, I propose the following approach: > > > > > > - I have created a single branch for all DocBook updates. > > > < > > https://github.com/apache/opennlp/tree/OPENNLP-1958-docbook-branch-epic> > > > - We will create a separate examples module specifically for the > > DocBook > > > examples. > > > - I am currently working out of a branch on my own fork for each > > chapter > > > (though I am happy to move this to the main repository if preferred). > > > - Each chapter will have a single focused commit that we can submit as > > a > > > PR. I just don't want to flood the PR list. > > > > > > I can either submit each chapter as an individual PR or combine them > > into a > > > single ongoing branch/PR - whichever the team prefers I have no strong > > > feelings about the workflow. > > > > > > We will determine how to merge them based on this thread. > > > > > > I have no strong feelings on the approach. I'll defer to the rest of the > > > team regarding how you want the updates merged. > > > > > > I was an editor for my college paper :) So I promise to edit everything > > > well before creating any PR or merging into this branch. I'll have a > > > separate branch per PR in my fork. > > > > > > My motivation stems from renaming a class awhile back. 'Twas good > > > refactor, but the book example was stale. Whenever that happens to me on > > > the receiving end, I get annoyed. So I'm fixing it. > > > > > > Doc-bearing, > > > > > > Kristian > >
