Point generated projects at the Codename One R2 repository - #5524
Open
shai-almog wants to merge 1 commit into
Open
Point generated projects at the Codename One R2 repository#5524shai-almog wants to merge 1 commit into
shai-almog wants to merge 1 commit into
Conversation
Phase two of the Maven Central migration. Codename One releases are moving to the repository at https://repo.codenameone.com/maven2, and from August 28 new versions stop being published to Central. A project generated before that date resolves fine today and then silently stops seeing new releases, so the three scaffolding paths now declare the repository up front. Both lists are declared in each root pom. Maven resolves ordinary dependencies through the repositories list and build plugins through the pluginRepositories list, so a project holding only the first downloads codenameone-core and still fails to find a newer codenameone-maven-plugin -- which reads as a corrupt install rather than a missing repository. Snapshots stay disabled on the new repository: it serves releases only, and enabling them would send every local 8.0-SNAPSHOT lookup over the network. The three scaffolds are covered: - cn1app-archetype -- mvn archetype:generate / cn1:generate-app-project - cn1lib-archetype -- library projects, which had no repository block at all - common.zip -- the Initializr root pom (start.codenameone.com) Losing any one of them is invisible at generation time, because Central still serves every already-published version, so validate_generated_repositories.py gates all three in the existing scaffolding-parity workflow, and the initializr matrix test asserts it on the generated root pom. Not included: resolving the archetype ITSELF still goes through Central, so `archetype:generate` will need -DarchetypeRepository (or the R2 archetype-catalog) once Central publication stops. That belongs with the phase-three cutover. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR advances Codename One’s Maven Central → Cloudflare R2 migration by ensuring newly generated projects explicitly resolve both dependencies and build plugins from https://repo.codenameone.com/maven2, and by adding CI gates to prevent regressions across all supported scaffolding paths (both archetypes and the Initializr common.zip).
Changes:
- Adds Codename One
<repositories>and<pluginRepositories>blocks to bothcn1appandcn1libarchetype root POM templates. - Introduces a new integration test (
validate_generated_repositories.py) and wires it into the existingscaffolding-parityGitHub Actions workflow. - Adds Initializr test assertions to ensure generated root POMs include the Codename One repository for both Java 8 and Java 17 generation paths.
Reviewed changes
Copilot reviewed 5 out of 6 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| scripts/initializr/common/src/test/java/com/codename1/initializr/model/GeneratorModelMatrixTest.java | Adds assertions that generated Initializr root POMs include the Codename One repository. |
| maven/integration-tests/validate_generated_repositories.py | New gate that validates all scaffolds declare the Codename One repository in both dependency and plugin resolution lists. |
| maven/cn1lib-archetype/src/main/resources/archetype-resources/pom.xml | Adds repository and pluginRepository blocks pointing at repo.codenameone.com. |
| maven/cn1app-archetype/src/main/resources/archetype-resources/pom.xml | Fills previously empty repository/pluginRepository blocks with the Codename One repo configuration. |
| .github/workflows/scaffolding-parity.yml | Runs the new repository-validation gate and expands path filters to include the archetype POM templates. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+86
to
+102
| for list_name, entry_name in REQUIRED_LISTS: | ||
| container = project.find("m:" + list_name, NS) | ||
| if container is None: | ||
| fail(label + " has no <" + list_name + ">; generated projects stop seeing " | ||
| + "Codename One releases once publication to Maven Central ends") | ||
|
|
||
| matches = [entry for entry in container.findall("m:" + entry_name, NS) | ||
| if child_text(entry, "url") == REPOSITORY_URL] | ||
| if not matches: | ||
| fail(label + " does not declare " + REPOSITORY_URL + " in <" + list_name + ">") | ||
|
|
||
| for entry in matches: | ||
| releases = entry.find("m:releases", NS) | ||
| if releases is not None and child_text(releases, "enabled") == "false": | ||
| fail(label + " declares " + REPOSITORY_URL + " in <" + list_name | ||
| + "> with releases disabled, so no release can resolve from it") | ||
|
|
Comment on lines
+225
to
237
| private void assertCodenameOneRepository(String rootPom, String label) { | ||
| int repositories = rootPom.indexOf("<repositories>"); | ||
| int pluginRepositories = rootPom.indexOf("<pluginRepositories>"); | ||
| assertTrue(repositories >= 0, label + " root pom should declare <repositories>"); | ||
| assertTrue(pluginRepositories > repositories, | ||
| label + " root pom should declare <pluginRepositories> after <repositories>"); | ||
| assertContains(rootPom.substring(repositories, pluginRepositories), | ||
| "https://repo.codenameone.com/maven2", | ||
| label + " root pom should resolve dependencies from the Codename One repository"); | ||
| assertContains(rootPom.substring(pluginRepositories), | ||
| "https://repo.codenameone.com/maven2", | ||
| label + " root pom should resolve plugins from the Codename One repository"); | ||
| } |
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
Contributor
Cloudflare Preview
|
Collaborator
Author
|
Compared 151 screenshots: 151 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
Collaborator
Author
|
Compared 181 screenshots: 181 matched. |
Collaborator
Author
|
Compared 148 screenshots: 148 matched. Benchmark Results
Detailed Performance Metrics
|
Collaborator
Author
|
Compared 144 screenshots: 144 matched. |
Collaborator
Author
|
Compared 217 screenshots: 217 matched. |
Collaborator
Author
|
Compared 149 screenshots: 149 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Collaborator
Author
|
Compared 143 screenshots: 143 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Phase two of the Maven Central migration described in Why Codename One Is Moving Beyond Maven Central. Phase one (#5497) shrank the release payload and started dual publishing; this makes newly generated projects point at
https://repo.codenameone.com/maven2.Why this is needed before the cutover
A project generated today resolves fine without the repository, because Central still serves every published version. It then silently stops seeing new releases after August 28. The failure is invisible at generation time, which is what makes it worth gating rather than merely doing.
Both lists are declared in each root POM. Maven resolves ordinary dependencies through
<repositories>and build plugins through<pluginRepositories>, so a project holding only the first downloadscodenameone-coreand still fails to find a newercodenameone-maven-plugin-- which reads to a user as a corrupt install rather than a missing repository.Snapshots stay disabled: the repository serves releases only, and enabling them would send every local
8.0-SNAPSHOTlookup over the network.The three scaffolds
These are the only ways a user gets a new project, and all three are covered:
cn1app-archetype(archetype:generate,cn1:generate-app-project)archetype-resources/pom.xml-- filled in the empty<repositories>/<pluginRepositories>blockscn1lib-archetype(library projects)archetype-resources/pom.xml-- had no repository block at allpom.xmlinsidescripts/initializr/.../common.zipGates
maven/integration-tests/validate_generated_repositories.py(new) checks all three scaffolds declare the repository, in both lists, with releases enabled. Wired into the existingscaffolding-parityworkflow next to the coordinate and settings checks, with the two archetype POMs added to its path filters.GeneratorModelMatrixTestasserts it on the generated root POM for both the Java 8 and Java 17 paths.Verification
8.0-SNAPSHOT, installed locally) and confirmed the block lands correctly after Velocity filtering.help:evaluateon the generated project shows the effective lists resolving in the intended order:codenameonethencentralfor dependencies,codenameone-pluginsthencentralfor plugins.com.codenameone:codenameone-maven-plugin:7.0.264into a clean local repo from R2 alone, confirming the endpoint serves the artifacts the generated POM points at.GeneratorModelIntegrationBuildTestfails with a 120s timeout, but it fails identically on unmodifiedmaster-- pre-existing, unrelated.Deliberately not included
Resolving the archetype itself still goes through Central. After Central publication stops,
mvn archetype:generate -DarchetypeGroupId=com.codenameone ...will need-DarchetypeRepository=https://repo.codenameone.com/maven2or the R2archetype-catalog.xml, and the documented commands in the developer guide will need updating. That is a phase-three concern and is not in this change.🤖 Generated with Claude Code