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 >
