https://github.com/apache/opennlp-addons/actions/runs/34887444149
It works. I created a follow-up task to implement this in opennlp. The addons already work- they're reachable from sandbox. I'll add it to opennlp next and open a PR. Since it works for addons, I won't test the opennlp main until the team approves the PR (there's no way to test beforehand). Opened the OpenNLP ticket - I will leave the addons ticket open for review. https://issues.apache.org/jira/browse/OPENNLP-1945 I'll submit the PR for this today. Once our issues are enabled, let's start a discussion thread on how we can define a new promotion process for new features. There's alot to discuss for that, and look forward to seeing how much more activity we get in Jira from this.. *Lastly, should we enable issues for addons too?* I'm conflicted, but I say not for now and we should direct people to the core NLP issue tracker. We can tag it and you can filter if you find it annoying, but having two places can cause more confusion. If we see too much noise in main from it that bothers people, we can enable it on addons when it becomes (a very good) problem to have. Kristian On Sun, Sep 13, 2026 at 4:01 PM Kristian Rickert <[email protected]> wrote: > No problem. > > I have the snapshot CICD setup for addons, just need to have > https://issues.apache.org/jira/browse/INFRA-28399 completed and it should > work. > > Once the addons build change is in place, we're not done; we'll still need > to align on the email, operational process, etc. We'll also port this to > OpenNLP once it's ironed out. > > Here is how it works: > > You click on "deploy snapshot build" > > It will let you choose a branch. Leave it blank and the branch name will > be the feature name (after some script fu linting). But you can enter a > custom name if you feel brave. > > It will *only* work on a snapshot so we'll need to get the JAR only if you > have access to the apache repo. For volunteers who cannot access the repo, > we should probably provide detailed instructions for your feature so they > can build local Maven artifacts. > > Glad we're doing this. Once snapshots are figured out, we'll plan how to > publish a hardened version to m2 Sonatype. > > Open to any suggestions or collaboration. > > Kristian > > On Fri, Sep 11, 2026 at 12:37 AM Richard Zowalla <[email protected]> > wrote: > >> No branch hell please (just same as in core) ;-) >> If something is done, it should go into the main branch. >> >> Naturally, dependsbot should only target main to avoid noise. >> >> > Am 11.09.2026 um 03:45 schrieb Kristian Rickert <[email protected]>: >> > >> > https://issues.apache.org/jira/browse/INFRA-28389 >> > >> > I sent out the INFRA ticket for addons. I'll set up the CICD once it is >> > approved and create a PR for it. Nothing will be merged to main without >> a >> > PR. >> > >> > Does anyone have thoughts on whether these addons should move to the >> > sandbox or become separate branches? I think they should all go to the >> > sandbox if no one claims them, since they haven't been touched in a long >> > time, but creating separate branches for each is also fine with me. >> > >> > Some questions to discuss: >> > >> > - Repository & Branch Strategy: Sandbox vs. separate branches for >> > unclaimed add-ons >> > - Stale Work & Retirement Rules: Guidelines for marking work as stale >> or >> > retiring defunct code >> > - Graduation to Core: Rules and thresholds (e.g., high >> > adoption/downloads) for moving an add-on into core >> > - Tasks & Ownership: Assigning tasks and build/release management (I'll >> > be glad to take on builds) >> > - Version Matrix & API Compatibility: Maintaining a 3.x core >> > compatibility matrix and defining API compatibility promises (my vote: >> keep >> > up with latest, new versions of opennlp and we cut a branch and focus on >> > the latest. Dependabot updates on supported branches that we retire >> with >> > Opennlp core) >> > - CICD & Workflow Setup: Aligning CI/CD, test setups, build triggers, >> and >> > manual/automated workflow dispatch with core >> > - GitHub Issues & Governance: When to enable GitHub Issues, >> establishing >> > PR review thresholds (e.g., required approvals), and PR template >> > requirements >> > - Security Model: Defining how add-ons align with the existing OpenNLP >> > security policy, particularly for native code, data downloads, or >> > third-party dependencies (most of this is defined but we'll formalize >> it in >> > the repo) >> > >> > Kristian >> > >> > >> >> On Wed, Sep 9, 2026 at 4:48 PM Kristian Rickert <[email protected]> >> wrote: >> >> >> >> I meant for local development. But just poking at the maven plug in, I >> >> don't think that'll be needed either :) >> >> >> >> For cicd I'll put something up tonight. Assuming the expected failure, >> >> I'll full out the infra ticket >> >> >> >>> On Wed, Sep 9, 2026, 3:32 PM Richard Zowalla <[email protected]> wrote: >> >>> >> >>> No need for scripts. GH action can due that (via action view you can >> >>> select the branch to run from… cf. >> >>> >> https://github.com/apache/stormcrawler-site/blob/main/.github/workflows/publish-staging.yml >> >>> You just trigger it for a branch from the action view in GitHub. >> >>> >> >>> If you go with scripts, you don’t need credentials or INFRA issues. It >> >>> works with your normal ASF ldap credentials... >> >>> >> >>> >> >>> >> >>>> Am 09.09.2026 um 21:25 schrieb Kristian Rickert <[email protected] >> >: >> >>>> >> >>>> rzo1: >> >>>> >> >>>> Thanks for the feedback. >> >>>> >> >>>> Keeping it fully manual. We can create a dev script to trigger it >> from >> >>> the >> >>>> CLI to avoid click-ops. Nexus also supports grace periods and >> snapshot >> >>>> retention days, which we may have access to, but I will keep >> everything >> >>>> manual for now. >> >>>> >> >>>> Pretty sure you're right about the password requirement, so I will >> test >> >>> it >> >>>> first before submitting an INFRA ticket to avoid crowding their >> queue. >> >>>> >> >>>> I will create a JIRA issue for this. Acceptance testing should be >> >>>> straightforward.. it just needs to create the JAR in the branch. >> >>>> >> >>>> Load-bearing, >> >>>> Kristian Rickert >> >>>> >> >>>> >> >>>> On Wed, Sep 9, 2026 at 3:15 PM Richard Zowalla <[email protected]> >> wrote: >> >>>> >> >>>>> I wouldn’t deploy each commit on a branch. Perhaps a manual workflow >> >>>>> (similar to website staging in for example StormCrawler) would do >> the >> >>> job? >> >>>>> You can even select from which branch to run, etc. - that seems to >> be >> >>> the >> >>>>> easiest way and avoids bloating ASF infrastructure with throw away >> >>>>> snapshots. >> >>>>> >> >>>>> For the credentials to be set into the repo: it requires an infra >> >>> ticket >> >>>>> afair. >> >>>>> >> >>>>> Rungs >> >>>>> Richard >> >>>>> >> >>>>>> Am 09.09.2026 um 21:12 schrieb Kristian Rickert < >> [email protected]>: >> >>>>>> >> >>>>>> Hi Jeff, >> >>>>>> >> >>>>>> Yep, that naming convention is exactly right, and these will only >> go >> >>> to >> >>>>>> SNAPSHOTS on repository.apache.org. >> >>>>>> >> >>>>>> I'll test this using the Maven Release Plugin, which I believe >> handles >> >>>>> this >> >>>>>> convention out of the box. Since it is on an add-ons branch, it >> will >> >>> just >> >>>>>> error out if it fails, but our existing Nexus account should cover >> >>> it. If >> >>>>>> needed, I will submit an INFRA ticket to complete the setup. We >> can >> >>>>> always >> >>>>>> change it too :) >> >>>>>> >> >>>>>> Best, >> >>>>>> Kristian >> >>>>>> >> >>>>>> >> >>>>>> On Wed, Sep 9, 2026 at 8:53 AM Jeff Zemerick <[email protected] >> > >> >>>>> wrote: >> >>>>>> >> >>>>>>> I don't think I have any objections. Would you make the version >> >>>>>>> something like `<version>2.0.0-FEATURE-XYZ-SNAPSHOT</version>` >> when >> >>> on >> >>>>>>> the branches to indicate it's from a non-main branch? >> >>>>>>> >> >>>>>>> I know the snapshot repository is already in the core pom.xml. I >> >>> think >> >>>>>>> the CI would need updated to deploy those snapshots from a >> non-main >> >>>>>>> branch? I think we can put a condition on that CI workflow to >> only do >> >>>>>>> that if the branch (or pom.xml version) is named in a certain way >> to >> >>>>>>> prevent all branches from being deployed. >> >>>>>>> >> >>>>>>> Thanks, >> >>>>>>> Jeff >> >>>>>>> >> >>>>>>> On Tue, Sep 8, 2026 at 9:17 PM Kristian Rickert < >> [email protected] >> >>>> >> >>>>>>> wrote: >> >>>>>>>> >> >>>>>>>> Hi team, >> >>>>>>>> >> >>>>>>>> Can we use Nexus for internal development >> >>>>>>>> <https://infra.apache.org/repository-faq.html>? Specifically, >> does >> >>>>>>> anyone >> >>>>>>>> object to using it for builds that are not yet merged into main? >> >>>>>>>> >> >>>>>>>> I would like to establish a build train between core, add-ons, >> and >> >>>>>>> sandbox >> >>>>>>>> (where core and add-ons deploy, but sandbox does not). Currently, >> >>> there >> >>>>>>> is >> >>>>>>>> no easy way to deploy dependencies until they are released to >> main. >> >>>>> While >> >>>>>>>> Maven handles this well, it requires deployment capabilities. >> >>> Writing >> >>>>>>>> custom scripts to bypass this defeats the purpose of our existing >> >>>>> tools. >> >>>>>>>> >> >>>>>>>> Here is what I am proposing: >> >>>>>>>> >> >>>>>>>> 1. Create a branch between core and add-ons. >> >>>>>>>> 2. Allow both to be published as snapshots to local Apache. >> >>>>>>>> 3. Ensure these JARs are available in GitHub CI/CD to keep core >> and >> >>>>>>>> add-ons in sync during development. >> >>>>>>>> 4. Make the JARs accessible in sandbox CI/CD so all >> authenticated >> >>>>>>>> committers can sync builds without manually downloading core or >> >>>>> add-ons. >> >>>>>>>> >> >>>>>>>> This workflow will allow us to test dependent services, such as >> >>>>> deploying >> >>>>>>>> the gRPC server internally, without reverting to a pre-Maven >> style >> >>> of >> >>>>>>>> development. >> >>>>>>>> >> >>>>>>>> I am happy to set this up, though I would appreciate pairing with >> >>>>> someone >> >>>>>>>> via Slack to navigate any system limits and serve as a second >> set of >> >>>>>>> eyes. >> >>>>>>>> >> >>>>>>>> Please let me know your thoughts on this. >> >>>>>>>> >> >>>>>>>> Load-bearing email rung, >> >>>>>>>> >> >>>>>>>> Kristian Rickert >> >>>>>>> >> >>>>> >> >>>>> >> >>> >> >>> >> >
