Inline cn1app/cn1lib archetypes; bring to initializr parity#4953
Merged
Conversation
…zr parity Move the cn1app-archetype and cn1lib-archetype modules in from https://github.com/shannah/cn1-maven-archetypes so the main repo owns and releases them alongside the framework. Update the templates so generated projects match what start.codenameone.com currently produces, including the Java 17 defaults and the Codename One authoring skill. * maven/cn1app-archetype/ and maven/cn1lib-archetype/ added as Maven modules under maven/pom.xml. Parent switched to `codenameone` so they inherit central-publishing, sign-artifacts, and version policy from the main reactor. maven-resources-plugin pinned to 3.3.1 in both pom files (replaces the inline sed hack the release workflow used to inject at deploy time). * CI rewired to the in-tree modules: - .github/workflows/release-on-maven-central.yml — collapsed from 6 steps into 3 (single `mvn deploy` covers core + archetypes since they're one reactor; Central-poll safety net keeps protecting against central-publishing-maven-plugin false-positive failures). - .github/workflows/archetype-smoke.yml — drop the external-zip fetch, install the in-tree archetypes via the main build, then refresh the local archetype catalog. - .github/workflows/ant.yml — same cleanup. - scripts/setup-workspace.sh — replace the 35-line clone-and-install block with a 2-line catalog refresh. - maven/README.adoc + README.md — updated build docs. - maven/update-version.sh — also bump the embedded `<defaultValue>`s in archetype-metadata.xml and `cn1Version` / `cn1PluginVersion` in the IT archetype.properties fixtures (guards against missing files so cn1lib's basic-only fixtures don't break the loop). * Java version handling matches the initializr exactly: - cn1app-archetype already shipped `javaVersion=auto` (resolves to 17 on JDK >= 17, otherwise 8); cn1lib-archetype is brought up to the same scaffold. - Velocity templates `${javaVersion}` into common pom `<source>` / `<target>` and codenameone_settings.properties; the archetype-post-generate.groovy rewrites the literal "auto" to the resolved value after the maven-archetype-plugin's velocity pass. - `-DjavaVersion=8` and `-DjavaVersion=17` overrides still win and are read back by the groovy so the conditional transforms below branch correctly. * Java-17-only transforms applied by the post-generate groovy (mirrors the initializr's per-template logic): - drop the `win/` UWP source tree (the legacy Windows / UWP cloud target is retired for Java 17 builds) - strip the `<profile><id>win</id></profile>` block from the cn1app root pom and the `<module>win</module>` line from the cn1lib root pom (different shapes — the lib archetype uses default modules rather than per-platform profiles) - set IntelliJ `languageLevel` to `JDK_17` (vs `JDK_1_8` on Java 8) - keep `.claude/skills/codename-one/**` for Java 17 projects, strip it for Java 8 (apps only — libraries don't ship the skill) * Codename One authoring skill bundled into the cn1app-archetype JAR from `scripts/initializr/common/src/main/resources/skill/**` (the initializr's source of truth). The cn1app-archetype/pom.xml adds an extra `<resource>` entry that stages the skill files into `archetype-resources/.claude/skills/codename-one/` at build time, so the skill stays single-source-of-truth and doesn't get duplicated in git. `.claude/**` is added as a fileSet in archetype-metadata.xml so the maven-archetype-plugin actually extracts it. * Universal (non-Java-17-specific) initializr improvements baked into the cn1app-archetype templates so generated projects no longer drift from initializr output: - `hardenPlatformModulePomAgainstDoubleJarAttach` parity: added the `maven-jar-plugin` 3.4.1 / default-jar phase=none block to android/ios/javascript pom.xml. - `normalizeJavasePom` parity: removed the top-level provided-scope `codenameone-core` and `codenameone-javase` dependencies from javase/pom.xml (the profile-scoped provided deps in `desktop_build` etc. stay — they're the legitimate ones). - `normalizeIntellijMiscXml` parity: stripped `project-jdk-name` and `project-jdk-type` from `.idea/misc.xml`; `languageLevel` is rewritten in the groovy as noted above. - `applySimulatorJvmExportToIdeaWorkspace` parity: pre-filled the `Run in Simulator` configuration's `vmOptions` with `--add-exports=java.desktop/com.apple.eawt=ALL-UNNAMED` in `.idea/workspace.xml`. The cn1lib-archetype's platform poms have a different shape (no codenameone-maven-plugin build invocation, antrun-based JAR build) so the JAR-attach and javase normalization don't apply; the misc.xml cleanup does. * cn1lib-archetype modernization (separately required for parity): - cn1Version defaultValue 7.0.26 → 8.0-SNAPSHOT. - Added `cn1PluginVersion` requiredProperty (previously shared a single `cn1Version` for both — wrong when plugin and framework diverge during release transitions). - Added `javaVersion=auto` requiredProperty. - ${javaVersion} velocity placeholders in root pom, common pom, javase pom, lib pom, javadoc-plugin <source>, and `codenameone_library_required.properties`. Verified locally with 16 archetype:generate runs (cn1app × cn1lib × JDK17/JDK8 × auto/explicit-override): win/ behavior correct, .claude/skills/ kept only for Java 17 apps, languageLevel matches the resolved JDK, project-jdk-name/-type absent, jar-plugin phase=none present in platform poms, top-level provided-scope deps stripped from javase pom, cn1Version and cn1PluginVersion separate. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
Two regressions in the previous commit: * tests/core.sh failed with `cannot access com.codename1.system.NativeInterface` during cn1lib stub generation. The Phase 3b strip of the top-level provided-scope codenameone-core / codenameone-javase from the generated javase/pom.xml was too aggressive — those deps are how `mvn package -Dcodename1.platform=javase` (the invocation tests/core.sh uses) gets the simulator runtime on the compile classpath. None of the profiles that supply them as compile-scope auto-activates on just the codename1.platform property, so removing the top-level deps broke standalone javase builds. The initializr's normalizeJavasePom must work on a different invocation path; for the archetype we restore the historical deps and accept the divergence. * scripts/setup-workspace.sh and tests/all.sh ran `mvn install` without -Darchetype.test.skip=true and the maven-archetype-plugin integration-test phase fired against both archetypes. The ITs generate sub-projects pinned to cn1Version=8.0-SNAPSHOT and invoke the codenameone-maven-plugin against them — but that plugin is built in this same reactor and isn't on Central yet, so the nested mvn fails. Set <archetype.test.skip>true</archetype.test.skip> as a default property in both archetype poms; the dedicated archetype-smoke workflow (and ad-hoc invocations) can opt back in with -Darchetype.test.skip=false. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
Compared 17 screenshots: 17 matched. |
Collaborator
Author
|
Compared 107 screenshots: 107 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
Collaborator
Author
|
Compared 107 screenshots: 107 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Collaborator
Author
|
Compared 107 screenshots: 107 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
1 participant
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.
Summary
cn1app-archetypeandcn1lib-archetypefrom shannah/cn1-maven-archetypes into this repo as Maven modules undermaven/. They now share the main reactor's parent pom, central-publishing config, sign-artifacts profile, and version policy.release-on-maven-central.yml,archetype-smoke.yml,ant.yml) andscripts/setup-workspace.shto use the in-tree archetypes — removed thegit clone https://github.com/shannah/cn1-maven-archetypesstep and the inlinesedhack that injected themaven-resources-pluginpin at deploy time. The pin is now a real<pluginManagement>entry in each archetype pom (3.3.1, keeps the Java 17 / Maven 4-only 4.0.0-beta-1 out of the JDK 8 release runner).hardenPlatformModulePomAgainstDoubleJarAttach,normalizeJavasePom,normalizeIntellijMiscXml,applySimulatorJvmExportToIdeaWorkspace).cn1lib-archetype(was on the pre-javaVersion=autoscaffold withcn1Version=7.0.26): addedcn1PluginVersionandjavaVersion=autorequired properties, velocity-templated${javaVersion}into all four poms (root/common/javase/lib) and the library required-properties file.How it works
javaVersion=auto(default)archetype-metadata.xmlrequiredPropertyautointo the templates;archetype-post-generate.groovyresolves it to17when running on JDK >= 17 and8otherwise.-DjavaVersion=8/-DjavaVersion=17mvn archetype:generateflagwin/dropwin/source tree + strip the<profile><id>win</id></profile>block from cn1app's root pom or the<module>win</module>line from cn1lib's root pom.cn1app-archetype/pom.xml<resource>entryscripts/initializr/common/src/main/resources/skill/**intoarchetype-resources/.claude/skills/codename-one/**. Skill files stay single-source-of-truth in the initializr; the post-generate groovy strips them when resolved Java version is 8. Libraries don't ship the skill.languageLevelJDK_17orJDK_1_8.project-jdk-name/project-jdk-typeare stripped in the template directly.phase=noneon android/ios/javascript pomshardenPlatformModulePomAgainstDoubleJarAttachwas inserting at generation time.codenameone-core+codenameone-javasein cn1app'sjavase/pom.xmldesktop_buildprovided deps stay (they're legitimately conditional).--add-exports=java.desktop/com.apple.eawt=ALL-UNNAMEDin.idea/workspace.xmlRun-in-Simulator vmOptionsapplySimulatorJvmExportToIdeaWorkspace.Test plan
Verified locally with 16
mvn archetype:generateruns (cn1app × cn1lib × JDK 17 / JDK 8 ×auto/ explicit override):cn1app:
win/.claude/skills/<source>languageLevelautoJDK_17=8JDK_1_8autoJDK_1_8=17JDK_17cn1lib:
win/<module>win><source>(all 4 poms)codename1.arg.java.versioncn1.plugin.versionlanguageLevelautoJDK_17=8JDK_1_8autoJDK_1_8=17JDK_17CI checklist:
Java CI(ant.yml) builds the new modules and refreshes the archetype catalogArchetype simulator smokeresolves the in-tree archetype (no external zip fetch)Release on Maven Centralworkflow change tested on next tag — singlemvn deployshould publish core + plugin + both archetypes in one pass; the Central-poll safety net still covers central-publishing-maven-plugin false-positive failuresNotes for reviewers
<resource>entry inmaven/cn1app-archetype/pom.xmlthat targetsarchetype-resources/.claude/skills/codename-one. The skill markdown lives only underscripts/initializr/common/src/main/resources/skill/**; the archetype JAR embeds a copy at build time. No file duplication in git.mvn install -Plocal-dev-javasebuilds them; release runs them with-Darchetype.test.skip=true -DskipTestsbecause their ITs invoke the codenameone-maven-plugin against the SNAPSHOT version being released, which isn't on Central yet at deploy time.cn1lib-archetypedoesn't bundle the skill (libraries are libraries). It also doesn't need thehardenPlatformModulePomAgainstDoubleJarAttachornormalizeJavasePomtransforms — its platform poms have a different shape (no codenameone-maven-plugin build invocation; antrun-based JAR build).🤖 Generated with Claude Code