fix: bundle sqlite-jdbc to fix wheels new on lucee 7 - #8
Merged
Conversation
Lucee 7's BundleProvider crashes when resolving sqlite-jdbc via the bundleName hint (malformed entry in upstream S3 bundle listing), so wheels-dev/wheels#2304 dropped the hint from the datasource emitted by `wheels new`. Without the hint Lucee falls back to classpath resolution, which requires the JAR to be on the Lucee lib path. This formula now: - Adds a `sqlite_jdbc` resource (3.49.1.0 from Maven Central, sha256 pinned) and stages it into share/wheels/lib/. - Drops the JAR into ~/.wheels/express/<lucee>/lib/ext/ on every run via the wrapper, idempotent — copies only if missing. The express directory only exists after the first LuCLI extraction, so the copy is a no-op on the first invocation and self-heals from the second invocation onward (which is fine — `wheels new` doesn't touch the database; `wheels migrate latest` does). - Adds a brew-test assertion that the JAR is staged into the Cellar. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced Apr 26, 2026
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
sqlite_jdbcresource (3.49.1.0 from Maven Central, sha256 verified) and stages it intoshare/wheels/lib/.~/.wheels/express/<lucee>/lib/ext/on every run, idempotent (copies only if missing).Why
Companion to wheels-dev/wheels#2304. Lucee 7's
BundleProvidercrashes when resolvingorg.xerial.sqlite-jdbcvia thebundleNamehint (malformed entryjavassist-3.9.0.GA copy.jarin the upstream S3 bundle listing). That PR dropped the hint from the SQLite datasource block emitted bywheels new. Without the hint, Lucee falls back to classpath resolution — but only if the JAR is actually on the classpath, which it isn't in any released Wheels distribution today. Without this companion change,wheels migrate latestafterwheels newwould fail withClassNotFoundException: org.sqlite.JDBCon Homebrew installs.Why the wrapper, not the install step
LuCLI extracts Lucee lazily into
$LUCLI_HOME/express/<lucee-version>/on first invocation. At brew-install time the express dir doesn't exist yet, so we can't drop the JAR straight in. Instead, the wrapper checks each invocation: if~/.wheels/express/*/lib/ext/exists and the JAR isn't there, copy it. The firstwheels newrun is a no-op for the JAR (LuCLI is extracting); the next run (typicallywheels migrate latest) sees the now-extracted express dir and lands the JAR before exec. Self-healing — also recovers if the user wipes~/.wheelsand reinstalls.Test plan
brew test wheelsafter install — new assertion verifies JAR is staged.wheels new blogtest && cd blogtest && wheels migrate lateston a clean machine — confirmdb/development.sqliteis non-zero size and tables exist (sqlite3 db/development.sqlite '.schema').~/.wheels/express/<lucee-version>/lib/ext/afterwheels migrate latestruns.🤖 Generated with Claude Code