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