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