feat: ship sqlite-jdbc + framework source to fix fresh-install cliffs - #11
Closed
bpamiri wants to merge 2 commits into
Closed
feat: ship sqlite-jdbc + framework source to fix fresh-install cliffs#11bpamiri wants to merge 2 commits into
bpamiri wants to merge 2 commits into
Conversation
Adds a second Homebrew resource (wheels_core) that pulls the Wheels framework-source zip from each GitHub release and stages it into share/wheels/framework/. The wrapper script syncs it into ~/.wheels/modules/wheels/vendor/wheels/ on version change, mirroring how wheels-module is already propagated. This unblocks the new-user Homebrew onboarding path: previously `brew install wheels` landed only the CLI, so `wheels new myapp` dead-ended at "Could not locate the Wheels framework source" — the first command of the Getting Started tutorial. Extends the auto-update workflow to fetch and substitute the wheels-core sha256 the same way wheels-module is handled. wheels-core is now required on every release (snapshots included); see wheels-dev/wheels PR 2294 for the release-workflow change that started publishing it. Blocked on: wheels-dev/wheels PR 2294 merging and the next snapshot release cutting with the wheels-core-*.zip asset. Until then this formula has a PLACEHOLDER_CORE_SHA sentinel that auto-update will replace on its first nightly run after those prereqs land.
Bundles the SQLite JDBC driver (org.xerial.sqlite-jdbc 3.49.1.0) with
the bottle and seeds it into Lucee Express's lib/ext/ on each wrapper
invocation so the default zero-config SQLite datasource works on first
use.
Without this, fresh `brew install wheels` users hit a hard cliff at
the very first `wheels migrate latest`: the command exits 0 with
"Migration latest completed." in green, but no schema is actually
created. The root cause is in the runtime — Lucee 7's BundleProvider
tries to resolve `org.xerial.sqlite-jdbc` from update.lucee.org at
runtime, which (a) does not host the bundle and (b) currently fails
its S3-listing fallback on a malformed entry. Until upstream Lucee
makes the bundle available, the cleanest fix is to ship the JAR
locally and put it on the classpath.
Why this is safe:
- The JAR is downloaded from Maven Central with a verified sha256
(5c8609d2ca341deb8c6f71778974b5ba4995c7d32d7c7c89d9392a3e72c39291)
- Verified to be a real OSGi bundle:
Bundle-SymbolicName: org.xerial.sqlite-jdbc;singleton:=true
Bundle-Version: 3.49.1.0
- The wrapper's seeding step is idempotent — it only copies into
lib/ext if no sqlite-jdbc*.jar is already there, so users who
already manually installed a different version aren't disturbed.
- The seed loop walks ~/.wheels/express/*/lib/ext/, so users with
multiple Lucee Express versions all get covered.
Companion to the in-flight wheels-side PRs that close the rest of
the cliff:
wheels#2304 — strips bundleName hint from new-app sqlite datasource
template (the prereq for classpath fallback to work)
wheels#2307 — fixes `migrateToLatest` command name (was sending
migrateTo with no version, which silently no-ops)
wheels#2308 — local fresh-install harness for verifying the cliff
stays closed
With all of these merged, the tutorial works end-to-end on a fresh
macOS Homebrew install.
Contributor
Author
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
Fixes the two onboarding cliffs that fresh-VM testing surfaced:
Missing SQLite JDBC driver — Lucee 7's BundleProvider can't fetch
org.xerial.sqlite-jdbcfromupdate.lucee.org, so the documented zero-config SQLite datasource fails on firstwheels migrate latest. Symptom: migrations exit 0 butdb/development.sqlitestays 0 bytes; every controller action that touches a model returnsWheels.DataSourceNotFound.Missing framework source —
wheels newemits an app that depends onvendor/wheels/, but Homebrew installs only ship the CLI module. Without a companionwheels-coreresource, scaffolded apps can't boot at all.What changed
wheels_coreresource pulls the framework-source zip from the matching wheels release.sqlite_jdbcresource pullssqlite-jdbc-3.49.1.0.jarfrom Maven Central with a pinned SHA.~/.wheels/express/<version>/lib/ext/directory on first run (idempotent — skipped once present).wheels_coreSHA per release; thePLACEHOLDER_CORE_SHAsentinel will be replaced on the next auto-update tick.assert_predicatetest additions confirm both new resources land at the expected paths after install.Verification
brew audit --strict wheels-dev/wheels/wheels— cleanbrew fetch --retry wheels-dev/wheels/wheels— all four resource URLs resolvetools/test-onboarding.shin wheels-dev/wheels — phase 4 (migration cliff) passes with the JAR shimmed inTest plan
PLACEHOLDER_CORE_SHAto the real valuebrew install wheelsafter rollout boots the scaffolded app withoutBundleExceptionwheels migrate latestproduces a non-emptydb/development.sqlitefile🤖 Generated with Claude Code