Fix icon resolution in app bundling by using jdeploy-bundle jar#442
Merged
Fix icon resolution in app bundling by using jdeploy-bundle jar#442
Conversation
The Bundler resolves icon.png relative to the app URL (jar path). When jdeploy.jar points to target/myapp.jar, the Bundler looked for target/icon.png which doesn't exist (icon.png is in the project root). This caused all platform bundle builds to fail silently, resulting in no bundle JARs uploaded and no url/sha256 fields in published artifacts. Fix: use the jar from jdeploy-bundle/ directory (created by makePackage) which already has icon.png co-located. Falls back to copying icon.png from the project root to the jar's directory when jdeploy-bundle is unavailable. https://claude.ai/code/session_01AfV1do5j6ChgV2nA5BePer
The JSONParser (codename1) parses JSON `true` as the String "true" by default, not as Boolean.TRUE. This caused `Boolean.TRUE.equals(enabled)` to always return false, so no artifact platforms were ever detected as enabled and no bundles were built at publish time. https://claude.ai/code/session_01AfV1do5j6ChgV2nA5BePer
Adds a direct unit test proving that com.codename1.io.JSONParser
returns String "true" (not Boolean.TRUE) for JSON boolean values.
This confirms the root cause of the bundle publishing bug where
Boolean.TRUE.equals("true") silently returned false.
https://claude.ai/code/session_01AfV1do5j6ChgV2nA5BePer
The bundle download URLs were constructed using the bare version (e.g. "1.0.4") but the GitHub release tag includes a "v" prefix (e.g. "v1.0.4"), causing 404 errors when downloading bundles. Changed maybePublishBundles() to use getRefName() which returns the actual release tag (from GITHUB_REF_NAME) instead of getVersion(). Also added a wiremock integration test that verifies bundle URLs use the git tag (with v-prefix) when githubRefName is set, and strengthened the existing URL assertions to verify the complete download path. https://claude.ai/code/session_01AfV1do5j6ChgV2nA5BePer
PublishBundleService.loadAppInfo() was not setting the jdeployRegistryUrl on AppInfo, causing app.xml in native bundles to contain registry-url='null'. This broke the auto-update mechanism in installed apps. Added PackagingConfig dependency to PublishBundleService and set the registry URL from the jdeploy section of package.json (or fallback to the default https://www.jdeploy.com/), matching the logic in PackageService.loadAppInfo(). Added unit tests verifying both default and custom registry URL values are correctly passed through to Bundler.runit() via AppInfo. https://claude.ai/code/session_01AfV1do5j6ChgV2nA5BePer
JAR (ZIP-based) format does not preserve POSIX file permissions, causing the Client4JLauncher binary in macOS .app bundles to lose its executable bit. This resulted in "permission denied" errors when opening installed apps. - PublishBundleService: Mac/Linux bundles now use tar.gz with permission preservation; Windows bundles continue using JAR - PrebuiltBundleDownloader: detects archive format by URL extension and uses appropriate extraction (tar.gz with permission restore, or JAR) - BundleArtifact: renamed jarFile->file and getJarFile()->getFile() since artifacts are no longer always JARs - Old JAR-format Mac bundles still work (backward compatible URL detection) https://claude.ai/code/session_01AfV1do5j6ChgV2nA5BePer
Use tar.gz consistently for all bundle artifacts (Windows, Mac, Linux) instead of only Mac/Linux. Removes the now-unused wrapInJar and addDirectoryToJar methods and JAR-related imports. https://claude.ai/code/session_01AfV1do5j6ChgV2nA5BePer
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.
Summary
This change improves icon resolution during app bundling by preferring the jar file from the
jdeploy-bundledirectory, which has the icon.png file co-located alongside it. This ensures the Bundler can correctly resolve icon resources relative to the app URL.Key Changes
Modified
loadAppInfo()in PublishBundleService: Updated jar URL resolution logic to:jdeploy-bundledirectory and use it if availableAdded comprehensive test coverage:
buildBundles_usesJdeployBundleJar_whenAvailable(): Verifies that the bundled jar fromjdeploy-bundleis used for icon resolution when availablebuildBundles_copiesIcon_whenNoJdeployBundle(): Verifies that icon.png is copied next to the jar when the bundled version doesn't existImplementation Details
The change implements a two-tier approach:
jdeploy-bundle(created byPackageService.bundleIconduringmakePackage), which already has icon.png co-locatedThis ensures icon resources are always accessible relative to the app URL, regardless of whether the bundled version is available.
https://claude.ai/code/session_01AfV1do5j6ChgV2nA5BePer