feature: Publish Java beta and RC releases to an R2-backed Maven repository

[Xuanwo]

Publish future org.lance:lance-core beta and RC versions to a public Maven repository backed by Cloudflare R2. Stable versions would continue to be published to Maven Central.

Motivation

Lance's Java package bundles native libraries for Linux x86-64, Linux ARM64, and macOS ARM64. Version 13.1.0-beta.2 totals approximately 210 MB across its JARs, POM, signatures, and checksums.

A count of the public Maven Central files for July–September 2026 shows:

Month	All versions	Beta + RC versions	Total size	Beta + RC size
July	36	34	7.20 GB	6.80 GB
August	47	39	9.02 GB	7.53 GB
September	34	33	6.92 GB	6.72 GB

These are public repository totals, including signatures and checksums, rather than Portal usage figures; GB denotes decimal gigabytes. Beta and RC versions account for approximately 91% of the bytes. Hosting them separately would reduce average monthly Central publishing volume from 7.71 GB to 0.70 GB at this cadence, while preserving the existing distribution path for stable releases.

Proposed behavior

• Provide anonymous HTTPS downloads through a project-owned domain, proposed as https://maven.lance.org.
• Preserve the existing coordinates and numbered beta and RC versions, such as org.lance:lance-core:13.1.0-beta.2 and org.lance:lance-core:13.0.0-rc.1. Published versions remain immutable and are retained long term.
• Beta and RC consumers add the repository to their Maven or Gradle configuration. Maven must enable releases for this repository because numbered beta and RC versions are not SNAPSHOT versions. No download credentials are required.
• Existing versions on Central remain available there. The change applies to beta and RC versions published after the cutover; stable consumers retain their current configuration.

Publishing

Extend the existing Java publishing workflow to route numbered beta and RC versions to R2. The build continues to produce the same artifacts and signatures.

During the transition, #9757 keeps stable, beta, and RC publication on Maven Central and adds one R2 upload step after it succeeds. The step extracts the same signed Central bundle and uploads its POM, JARs, signatures, and checksums with the AWS CLI. R2 serves those files through the custom domain using the standard Maven HTTP file layout. No custom publishing script or repository manager is needed.

Consumers specify an exact published version, including the full beta or RC suffix. This supports our preview testing workflow without generating maven-metadata.xml; version discovery and version ranges are outside this proposal.

Release maintainers own the bucket and domain. CI receives Object Read & Write access scoped to the publishing bucket; consumers download anonymously. A failed R2 upload fails the existing publish job after Central publication has already succeeded. Re-running that job also repeats Central publication; this change does not add an independent R2 retry or a content-conflict check.

Cost and tradeoffs

At roughly 35 beta and RC versions per month and today's package size, storage grows by approximately 7.4 GB per month, or 89 GB per year. At R2 Standard pricing, retaining one year's output costs approximately $1.34 per month in storage before free allowances. Direct R2 egress is free; request and domain costs are additional.

Lance would maintain the upload step, bucket, domain, and CI credentials. Beta and RC consumers would configure an additional repository, and organizations restricting dependency sources would need to allow it. This extra responsibility buys predictable hosting costs and control over artifact retention.

[wjones127]

We use fury.io for Python. They also support Maven. What's the reason to not re-use that?

[Xuanwo]

Cool! Just don't know about this. I think it's a better choice.

[Xuanwo]

fury seems to have limit on push: https://gemfury.com/help/limits/

Will try to validate this.

[Xuanwo]

I tried to upload our 208MiB jar to fury, but failed for HTTP 413 error:

HTTP/2 100

HTTP/2 413
content-type: text/plain; charset=utf-8
date: Tue, 06 Oct 2026 17:22:51 GMT
nel: {"report_to":"heroku-nel","response_headers":["Via"],"max_age":3600,"success_fraction":0.01,"failure_fraction":0.1}
report-to: {"group":"heroku-nel","endpoints":[{"url":"https://nel.heroku.com/reports?s=I5zphRdqTTCrQlDHn4VWEbaTdTlfVGIv7cB95YEnIjs%3D\u0026sid=929419e7-33ea-4e2f-85f0-7d8b7cd5cbd6\u0026ts=1791307365"}],"max_age":3600}
reporting-endpoints: heroku-nel="https://nel.heroku.com/reports?s=I5zphRdqTTCrQlDHn4VWEbaTdTlfVGIv7cB95YEnIjs%3D&sid=929419e7-33ea-4e2f-85f0-7d8b7cd5cbd6&ts=1791307365"
server: Heroku
strict-transport-security: max-age=2592000; includeSubDomains
via: 2.0 heroku-router
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 1; mode=block
content-length: 163


ERROR: Request too large for this endpoint.
Please ensure the upload is within limits:
https://gemfury.com/help/upload-packages
https://gemfury.com/help/limits