andrewmusselman opened a new issue, #1262: URL: https://github.com/apache/tooling-trusted-releases/issues/1262
## Summary The "Record a manual staging distribution" form (`/distribution/stage/record/<project>/<version>`) rejects any Maven groupId containing a `.` because the `owner_namespace` field is typed `safe.Alphanumeric`, which strips/rejects non-alphanumeric characters. Since Maven groupIds are dotted by convention (`org.apache.commons`, `org.apache.couchdb`, etc.), no real Maven Central staging entry can be recorded through this form as written. ## Reproduce 1. Navigate to `/distribution/stage/record/<your-project>/<your-version>` as a committer. 2. Select **Platform: Maven Central**. 3. In **Owner or Namespace** enter a real Maven groupId such as `org.apache.example`. 4. Fill in **Package** and **Version**, submit. Result: > Error: Alphanumeric 'org.apache.example' contains invalid characters: '.' The form re-renders with the error attached to the `owner_namespace` field. No record is created. ## Expected The field should accept any string that is valid as a Maven groupId per the [Maven coordinates spec](https://maven.apache.org/pom.html#Maven_Coordinates) — broadly, reverse-domain notation with dots, digits, and hyphens permitted. ## Actual The `Alphanumeric` constraint rejects the input outright. Workaround on the user side is to enter a flattened, non-conformant value (`orgapacheexample`) which then produces a 404 from RAO because the path no longer matches the staging repo layout — so the workaround is not useful in practice. ## Root cause `atr/shared/distribution.py` declares the form field as `owner_namespace: safe.Alphanumeric | None`. The `safe.Alphanumeric` type is intentionally restrictive and shared across forms where alphanumeric-only is genuinely the right constraint. Maven is the outlier among the supported platforms. The Maven staging URL template in `atr/models/sql.py` also doesn't currently translate dots to slashes: ``` https://repository.apache.org:4443/repository/maven-staging/{owner_namespace}/{package}/maven-metadata.xml ``` In real Maven repository layout, `org.apache.example` maps to the path `org/apache/example/...`. So even if the form accepted dots, the URL would still need a Maven-specific `.`-to-`/` substitution to actually hit a valid metadata path. The two issues are connected. ## Suggested directions (not prescriptive) A few approaches, each with tradeoffs: 1. **Add a Maven-specific safe type** (`safe.MavenCoordinate` or similar) that accepts dotted groupIds, and make the form use a platform-conditional type. Cleanest separation, most code. 2. **Loosen `owner_namespace` to a less restrictive shared type** (allow `.` and `-`) and rely on per-platform validation downstream. Less surgical, may have knock-on effects in non-Maven flows. 3. **Pre-process the input** in the Maven branch only — accept dots in the form, then convert to slashes when interpolating the URL template. Pairs naturally with fixing the URL template at the same time. A separate question for the maintainers: should the form even expose a free-text `owner_namespace` field for Maven, given that staging on Maven Central is normally driven by RAO with a pre-known staging-repo identifier? It may be that the right Maven UX is different from the other platforms entirely. ## Severity Moderate. Blocks the entire manual-record path for Maven Central, which is one of the three platforms with a live staging URL configured. Discovered while smoke-testing #751 (PR `Track the staging revision of a recorded distribution`) but predates that change — reproducible on `main`. ## Related - The whitelist removal in PR for #751 means this code path is more cleanly reachable now, but the form validation behaviour is unchanged. - Probably interacts with whatever the Maven Central / RAO integration story ends up being (#751 dave2wave comment: *"RAO is used for both SNAPSHOTS, Staging, and Maven Central promotion. So, we will still need to be a bridge."*) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
