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