Resolution and publication were both pointed at one hardcoded registry URL. Against Nexus 3
that single address cannot serve both roles:
Resolution must use the maven-public group, which is read-only and answers 403 to
any write.
Publication must target a hosted repo, and the two hosted repos enforce mutually
exclusive version policies: a SNAPSHOT arriving at maven-releases is rejected with 400, and a release arriving at maven-snapshots likewise.
So the publish target has to follow the artifact version, not a fixed variable.
What changed
gradle.properties
mavenPublishUrl now carries the organisation default base instead of a hardcoded
registry path. It stays a plain Gradle property so it can be overridden (see below).
build.gradle
Endpoints are derived from that base:
resolution → $base/repository/maven-public
publication → $base/repository/maven-releases or maven-snapshots, by version
The repository name in the configured value is stripped, so .../maven-releases, .../maven-public or a bare host all normalise to the same base. A mis-filled repository
name therefore cannot send a snapshot to the release repo.
Inline MAVEN_URL / credential blocks are replaced; MAVEN_URL no longer appears.
Runner override - no bespoke variable
mavenPublishUrl is an ordinary Gradle property, so Gradle's own mechanism covers the
"runner on a slow network uses the accelerator" case:
exportORG_GRADLE_PROJECT_mavenPublishUrl=https://<accelerator>/repository/maven-public
# or
./gradlew -PmavenPublishUrl=https://<accelerator>/repository/maven-public publish
One variable moves both endpoints; the repository itself is untouched. Precedence is
simply: command line / env > gradle.properties.
Deliberately no TDLM_MAVEN_* variables were introduced - a separate resolve or publish
override can only be misconfigured, and a fixed publish URL is the bug this change removes.
Verification
Verified with the real GTNH plugin (2.0.29) on Gradle 9.4 / JDK 25, using this repo's actual
patched build script (a local file:///sentinel target, no external service touched):
Only the host:port of the injected value survives; whatever repository path is written there
is discarded and recomputed. The accelerator therefore has to expose the same /repository/<name> paths as Nexus - a bare DNS alias or any proxy that passes that path
through unchanged works, a proxy that demands its own path prefix does not.
Also confirmed on the plugin itself: a publishing repository only exists when MAVEN_USER/MAVEN_PASSWORD are set, and -PmavenPublishUrl= / ORG_GRADLE_PROJECT_mavenPublishUrl really do override the file value.
## Why
Resolution and publication were both pointed at one hardcoded registry URL. Against Nexus 3
that single address cannot serve both roles:
- **Resolution** must use the `maven-public` group, which is read-only and answers `403` to
any write.
- **Publication** must target a hosted repo, and the two hosted repos enforce mutually
exclusive version policies: a `SNAPSHOT` arriving at `maven-releases` is rejected with
`400`, and a release arriving at `maven-snapshots` likewise.
So the publish target has to follow the artifact version, not a fixed variable.
## What changed
`gradle.properties`
- `mavenPublishUrl` now carries the **organisation default base** instead of a hardcoded
registry path. It stays a plain Gradle property so it can be overridden (see below).
`build.gradle`
- Endpoints are derived from that base:
- resolution → `$base/repository/maven-public`
- publication → `$base/repository/maven-releases` or `maven-snapshots`, by version
- The repository name in the configured value is stripped, so `.../maven-releases`,
`.../maven-public` or a bare host all normalise to the same base. A mis-filled repository
name therefore cannot send a snapshot to the release repo.
- Inline `MAVEN_URL` / credential blocks are replaced; `MAVEN_URL` no longer appears.
## Runner override - no bespoke variable
`mavenPublishUrl` is an ordinary Gradle property, so Gradle's own mechanism covers the
"runner on a slow network uses the accelerator" case:
```bash
export ORG_GRADLE_PROJECT_mavenPublishUrl=https://<accelerator>/repository/maven-public
# or
./gradlew -PmavenPublishUrl=https://<accelerator>/repository/maven-public publish
```
One variable moves **both** endpoints; the repository itself is untouched. Precedence is
simply: command line / env > `gradle.properties`.
Deliberately no `TDLM_MAVEN_*` variables were introduced - a separate resolve or publish
override can only be misconfigured, and a fixed publish URL is the bug this change removes.
## Verification
Verified with the real GTNH plugin (2.0.29) on Gradle 9.4 / JDK 25, using this repo's actual
patched build script (a local `file://`/sentinel target, no external service touched):
| scenario | resolution | publication |
|---|---|---|
| repo default | `maven.nest.potatolab.uk:8443/repository/maven-public` | `.../repository/maven-releases` |
| injected host | `cdn.example.org/repository/maven-public` | `cdn.example.org/repository/maven-releases` |
Only the host:port of the injected value survives; whatever repository path is written there
is discarded and recomputed. The accelerator therefore has to expose the same
`/repository/<name>` paths as Nexus - a bare DNS alias or any proxy that passes that path
through unchanged works, a proxy that demands its own path prefix does not.
Also confirmed on the plugin itself: a publishing repository only exists when
`MAVEN_USER`/`MAVEN_PASSWORD` are set, and `-PmavenPublishUrl=` /
`ORG_GRADLE_PROJECT_mavenPublishUrl` really do override the file value.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Why
Resolution and publication were both pointed at one hardcoded registry URL. Against Nexus 3
that single address cannot serve both roles:
maven-publicgroup, which is read-only and answers403toany write.
exclusive version policies: a
SNAPSHOTarriving atmaven-releasesis rejected with400, and a release arriving atmaven-snapshotslikewise.So the publish target has to follow the artifact version, not a fixed variable.
What changed
gradle.propertiesmavenPublishUrlnow carries the organisation default base instead of a hardcodedregistry path. It stays a plain Gradle property so it can be overridden (see below).
build.gradle$base/repository/maven-public$base/repository/maven-releasesormaven-snapshots, by version.../maven-releases,.../maven-publicor a bare host all normalise to the same base. A mis-filled repositoryname therefore cannot send a snapshot to the release repo.
MAVEN_URL/ credential blocks are replaced;MAVEN_URLno longer appears.Runner override - no bespoke variable
mavenPublishUrlis an ordinary Gradle property, so Gradle's own mechanism covers the"runner on a slow network uses the accelerator" case:
One variable moves both endpoints; the repository itself is untouched. Precedence is
simply: command line / env >
gradle.properties.Deliberately no
TDLM_MAVEN_*variables were introduced - a separate resolve or publishoverride can only be misconfigured, and a fixed publish URL is the bug this change removes.
Verification
Verified with the real GTNH plugin (2.0.29) on Gradle 9.4 / JDK 25, using this repo's actual
patched build script (a local
file:///sentinel target, no external service touched):maven.nest.potatolab.uk:8443/repository/maven-public.../repository/maven-releasescdn.example.org/repository/maven-publiccdn.example.org/repository/maven-releasesOnly the host:port of the injected value survives; whatever repository path is written there
is discarded and recomputed. The accelerator therefore has to expose the same
/repository/<name>paths as Nexus - a bare DNS alias or any proxy that passes that paththrough unchanged works, a proxy that demands its own path prefix does not.
Also confirmed on the plugin itself: a publishing repository only exists when
MAVEN_USER/MAVEN_PASSWORDare set, and-PmavenPublishUrl=/ORG_GRADLE_PROJECT_mavenPublishUrlreally do override the file value.Pull request closed