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 >> >>>> >> >> >> >> >> >>
