Fix cn1:build on Maven 3.9+ (drop @Execute fork) + retire legacy Windows UWP/C# port#5267
Merged
Merged
Conversation
…fork The CN1 `build` goal declared @execute(phase=package) AND is bound to the package phase by every platform profile, so invoking it forked a second package lifecycle. The per-platform modules (javase/ios/android/win/linux) carry no classes of their own -- the app code lives in `common` -- so their default jar is empty. On Maven 3.9+ the forked run inherits the already attached empty main artifact and maven-jar-plugin aborts with "You have to use a classifier to attach supplemental artifacts...". This broke every build target (desktop, device, source) for freshly generated apps. The fork was redundant: `mvn package` (the only supported invocation) runs package before the build goal anyway. Removing @execute makes package run once, with no double-attach. Also fixes a latent bug surfaced while verifying every build target: the linux module could not locate common/codenameone_settings.properties because getCN1ProjectDir() omitted "linux" from its platform fast-path list, so linux-device failed before departure. Added "linux" to the list. Verified all targets after the change (fake certs): ios-device, ios-device-release, mac-os-x-native, mac-os-x-desktop, windows-desktop, javascript, android-device and linux-device all depart to the build server; jar, ios-source and android-source build locally. windows-device (local native cross-compile) runs the full lifecycle and only stops at the missing xwin Windows SDK, as expected on a non-Windows host. Adds an offline integration test (cn1app-desktop-build-test.sh) that exercises the desktop build lifecycle via the bundled Maven 3.9 wrapper and asserts the package phase runs exactly once with no double-attach. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
Compared 129 screenshots: 129 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
Collaborator
Author
|
Compared 122 screenshots: 122 matched. |
The old Windows device port was UWP/C#. It is retired: the only supported Windows targets are now win32 (native, ParparVM -> C, like the Linux target) and windows-desktop (JavaSE). This removes the C# garbage and makes the win module a C target. - StubGenerator: stop emitting C# (.cs) native-interface stubs; drop generateCSFile/javaTypeToCSharpType and the win-module C# detection. Native C stubs (win/src/main/c, like linux) are unchanged. - Archetypes (app + cn1lib): the win module fileSet is C (src/main/c, *.c/*.h) instead of C# (src/main/csharp, *.cs), mirroring linux; remove the csharp source dirs. - GenerateAppProjectMojo / GenerateCn1libProjectMojo / Cn1libMojo: copy win native sources from src/main/c (*.c/*.h) instead of src/main/csharp. - Delete Ports/WinPhone7 (legacy Windows Phone / Silverlight C# port, 36 files); confirmed unreferenced by the build. - Clean the stale "UWP"/C# wording in build.sh/build.bat, nb-configuration, .vscode, mvnconfig, common pom profile (uwp -> win), README and the archetype post-generate groovy comments. windows-device now sends a "win32" build to the server (cloud), mirroring linux-device, instead of being treated as a local-only native build. The local clang-cl cross-compile remains available as local-windows-device, and windows-source still generates a local project. The buildxml-template windows-device target dropped the certificate/certPassword attributes: the build client pairs certificate with provisioningProfile (the iOS model) which Windows has no equivalent for, so passing a cert alone failed with "attribute provisioningProfile is required". Cloud win32 builds submit unsigned (matching linux-device); Authenticode signing of cloud builds is a separate follow-up, and local-windows-device still honours codename1.windows.signing.*. Verified end to end: plugin compiles, StubGeneratorTest passes, a freshly generated app has zero csharp/.cs/uwp references, windows-device departs to the server as win32, and the @execute double-package regression test still passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
shai-almog
changed the title
Collaborator
Author
|
Compared 210 screenshots: 210 matched. |
Collaborator
Author
|
Compared 125 screenshots: 125 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Collaborator
Author
|
Compared 129 screenshots: 129 matched. Benchmark Results
Detailed Performance Metrics
|
Collaborator
Author
|
Compared 129 screenshots: 129 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
The build-linux-jdk8 CI job failed: native-interfaces.sh still asserted that migrating a legacy project produces a C# stub at win/src/main/csharp/.../HelloNativeImpl.cs. With the UWP/C# port retired, the win module is a native C target and that file is no longer produced. - GenerateAppProjectMojo / GenerateCn1libProjectMojo: the migration's win "resources" copy now also excludes *.cs, so a legacy project's C# sources are not dragged into the migrated win module (previously they would have landed in win/src/main/resources). - native-interfaces.sh: replace the "win C# impl present" check with an assertion that NO .cs is carried into the win module. Guarded on the win dir existing, since the archetype post-generate script strips the win module for Java 17 projects (kept for Java 8). Verified on JDK 8 (the CI runner's level): migrating cn1-native-interface-tests yields a win module with no .cs, and the assertion passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
2 participants
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.
1. cn1:build double-package abort on Maven 3.9+
A freshly generated app fails every
cn1:buildtarget on Maven 3.9+:CN1BuildMojodeclared@Execute(phase = PACKAGE)and is bound to thepackagephase by every platform profile, so it forked a second package lifecycle. The empty per-module jar then gets attached twice and Maven 3.9 aborts. The fork was redundant (mvn packagealready runs package first). Fix: drop@Execute— package runs once, no double-attach.Also fixes a latent bug found while verifying every target:
getCN1ProjectDir()omitted"linux"from its platform list, solinux-devicecouldn't findcommon/codenameone_settings.properties. Added"linux".2. Retire the legacy Windows UWP/C# port
The old Windows device port was UWP/C#. The only supported Windows targets are now win32 (native, ParparVM → C, like Linux) and windows-desktop (JavaSE). This removes the C# garbage and makes the
winmodule a C target:.csnative-interface stubs (dropgenerateCSFile/javaTypeToCSharpType+ the win-module C# detection). Native C stubs (win/src/main/c, like linux) unchanged.winmodule fileSet is C (src/main/c,*.c/*.h) instead of C# (src/main/csharp,*.cs), mirroring linux; csharp source dirs removed.src/main/cinstead ofsrc/main/csharp.Ports/WinPhone7(legacy Windows Phone / Silverlight C#, 36 files; confirmed unreferenced).build.sh/build.bat, nb-configuration,.vscode,mvnconfig.toml, the common-pom profile (uwp→win), README, and the post-generate groovy comments.windows-devicenow sends awin32build to the server (cloud), mirroringlinux-device, instead of being classified local-only. The local clang-cl cross-compile stays aslocal-windows-device, andwindows-sourcestill generates a local project. The buildxml-templatewindows-devicetarget droppedcertificate/certPassword: the build client pairscertificatewithprovisioningProfile(the iOS model) which Windows has no equivalent for, so a cert alone failed with "attribute provisioningProfile is required". Cloud win32 builds submit unsigned (like linux-device).Verification
Every build target was exercised end-to-end against a freshly generated app with fake certs:
Plus: plugin compiles,
StubGeneratorTestpasses, a freshly generated app has zerocsharp/.cs/uwpreferences, and the new offline@Executeregression test (cn1app-desktop-build-test.sh, wired intoall.sh) passes — it asserts the package phase runs exactly once with no double-attach.Out of scope / follow-ups
Executor.java(a.csentry in two extension allowlists + a dead Silverlight mime type), deep in the cloud build-client; left untouched as they don't affect behavior and editing the client is risky.local-windows-devicestill honourscodename1.windows.signing.*).🤖 Generated with Claude Code