This is an automated email from the ASF dual-hosted git repository. leginee pushed a commit to branch bazel-migration in repository https://gitbox.apache.org/repos/asf/openoffice.git
commit 846353cddf615757a2ff65962fe07d40b838246d Author: Peter Kovacs <[email protected]> AuthorDate: Fri Aug 14 06:38:00 2026 +0200 docs: record the resource-library split as a general rsc_res rule The finding generalises beyond connectivity, so it goes in CLAUDE.md as a rule rather than only in the module readme: one module's source/**/*.src is NOT necessarily one .res. A module whose makefile declares RESLIB1NAME..RESLIB3NAME needs three rsc_res targets, because the bundles are resolved BY NAME at runtime and a merged .res leaves the other names unresolvable while also risking ID collisions across what were separate namespaces. Any other module whose rsc_res globs source/**/*.src should be checked against its makefile's RESLIB<N>NAME count. Also records why upstream's fourth connectivity reslib is deliberately absent: hsqlui.src exists only to force two images into images.zip, which was a dmake necessity and is already covered here by //main/default_images:images globbing database/**/*.png. Co-Authored-By: Claude Opus 5 <[email protected]> --- CLAUDE.md | 19 ++++++++++++++++++- main/connectivity/BUILD.bazel | 9 +++++---- main/connectivity/readme.md | 19 +++++++++++++++++-- 3 files changed, 40 insertions(+), 7 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 2a2c70363c..3ee861a200 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -688,7 +688,7 @@ dbaccess hardcodes sdbc:embedded:hsqldb (dsntypes.cxx) -> hsqldb.dll -> which does NOT do the SQL but asks the driver manager for "jdbc:hsqldb:db" -> jdbc.dll -> the hsqldb.jar engine; sdbc_hsqldb.jar is what makes it a SINGLE FILE (StorageAccess/StorageFileAccess implement org.hsqldb.lib.Storage/ -FileAccess over UNO embedded storage, their native methods being the 28 Java_* +FileAccess over UNO embedded storage, their native methods being the 27 Java_* exports of hsqldb.dll). Both jars MUST land in program/classes/ — not a convention, HDriver.cxx hardcodes vnd.sun.star.expand:$OOO_BASE_DIR/program/classes/<name>.jar. @@ -755,6 +755,23 @@ STILL UNMIGRATED, with what each needs (none is blocked, all are just work): • adabas — 22 srcs + odbcbase, and needs an installed Adabas D server+client. Discontinued commercial product; nothing can exercise it. Recommend leaving it unregistered permanently rather than migrating. +RESOURCE-LIBRARY SPLIT, fixed 2026-08-14 — GENERAL rsc_res LESSON: one module's +source/**/*.src is NOT necessarily one .res. connectivity/source/resource builds +THREE (cnr, sdbcl, sdberr) and the old glob merged them into cnren-US.res alone, +so two bundles simply did not exist and IDs could collide across what were meant +to be separate namespaces. They are looked up BY NAME at runtime: dbtools is +compiled with CONN_SHARED_RESOURCE_FILE=cnr, and JDriver.cxx constructs +comphelper::ResourceBasedEventLogger("sdbcl", "org.openoffice.sdbc.jdbcBridge") +where the FIRST argument is the bundle name, so the logger resolves sdbcl<lang>.res. +Latent until now because no driver was built; and sdbcl is inert while logging is +off (the level check returns before any resource lookup), while sdberr is the SQL +ERROR MESSAGES — missing, it empties the text at exactly the moment something +fails, which is part of why driver problems here are so quiet. CHECK ANY OTHER +MODULE WHOSE rsc_res GLOBS `source/**/*.src` against its makefile's RESLIB<N>NAME +count. Upstream's fourth reslib here (hsqldb, from hsqlui.src) is deliberately +NOT built: its own comment says the .res is never installed and it exists only to +force two images into images.zip, a dmake necessity that +//main/default_images:images already covers by globbing `database/**/*.png`. See main/connectivity/readme.md. NOTE: rules_java 8.11.0 IS now wired (MODULE.bazel) and the core Java UNO runtime is migrated & green — ridljar/jurt/jvmaccess/javaunohelper/jvmfwk/ diff --git a/main/connectivity/BUILD.bazel b/main/connectivity/BUILD.bazel index 7ff7ddeea6..98ac8c7736 100644 --- a/main/connectivity/BUILD.bazel +++ b/main/connectivity/BUILD.bazel @@ -21,10 +21,11 @@ _COPTS = [ "/Zc:wchar_t-", ] -# Shared by the four rsc_res targets below. source/resource/makefile.mk builds -# THREE separate resource libraries (cnr, sdbcl, sdberr) and the hsqldb driver -# a fourth (hsqldb) -- they are separate bundles looked up by NAME at runtime, -# so they must not be globbed into one .res. +# Shared by the three rsc_res targets below. source/resource/makefile.mk builds +# THREE separate resource libraries (cnr, sdbcl, sdberr) -- separate bundles, +# looked up by NAME at runtime, so they must not be globbed into one .res. +# (Upstream has a fourth, hsqldb, which is deliberately not built here; see the +# note where it would otherwise go.) _RES_INCLUDES = [ "main/connectivity/source/resource", "main/connectivity/source/drivers/hsqldb", diff --git a/main/connectivity/readme.md b/main/connectivity/readme.md index 7559c9390d..185805126f 100644 --- a/main/connectivity/readme.md +++ b/main/connectivity/readme.md @@ -48,7 +48,7 @@ above at once: 4. `sdbc_hsqldb.jar` is what makes the database a *single file*: `StorageAccess` / `StorageFileAccess` implement `org.hsqldb.lib.Storage` / `FileAccess` over UNO's embedded storage, and their native methods are the - 28 `Java_*` exports of `hsqldb.dll`. + 27 `Java_*` exports of `hsqldb.dll`. Both jars are staged to `program/classes/` — not by convention but because `HDriver.cxx` builds the classpath as the literal string @@ -167,7 +167,7 @@ files as textual fragments (declared via `_parse_generated` cc_library). - `SOLAR_JAVA` is load-bearing for `jdbc` and `hsqldb`, not a feature switch: `jvmaccess/virtualmachine.hxx` includes the real `<jni.h>` only under it and otherwise declares stubs, so without it every `JNIEnv->` call is C2027 -- `hsqldb.dll` carries 28 undecorated `Java_*` exports in its DEF alongside the two +- `hsqldb.dll` carries 27 undecorated `Java_*` exports in its DEF alongside the two `component_*` ones (JNICALL is `__stdcall` on Win32, so without the DEF they would be `_Java_…@N` and the JVM could not find them) — same trick as `jurt`'s `jpipe.def`. It does NOT need the RT_MANIFEST id 2 embedded manifest that @@ -175,4 +175,19 @@ files as textual fragments (declared via `_parse_generated` cc_library). activation context, whereas this JVM runs in-process inside `soffice.exe` - `hsqldb.dll` takes no DLLPOSTFIX (version.mk sets `HSQLDB_TARGET=hsqldb` bare) because the Java side hardcodes `System.loadLibrary("hsqldb")` +- `source/resource/` builds **three separate resource libraries**, not one, and they + are looked up by NAME at runtime so they must not be globbed together: + `cnr` (shared driver strings — dbtools compiles with + `CONN_SHARED_RESOURCE_FILE=cnr`), `sdbcl` (the connection logger's messages; + `JDriver.cxx` constructs `ResourceBasedEventLogger("sdbcl", + "org.openoffice.sdbc.jdbcBridge")`, and the first argument IS the bundle name) + and `sdberr` (SQL error messages). A single merged `.res` leaves two of the + three unresolvable and can collide IDs across what were meant to be separate + bundles. `sdbcl` is inert while logging is off — the level check returns before + any resource lookup — which is why its absence went unnoticed until a driver was + actually built; `sdberr` hollows out error text at exactly the wrong moment. +- upstream's fourth reslib, `hsqldb` (from `hsqlui.src`), is deliberately NOT built: + its own comment says the `.res` is never installed and it exists only to force two + images into `images.zip`, which was a dmake necessity. `//main/default_images:images` + globs `database/**/*.png` directly, so it would be a dead target here - Drivers still unmigrated: ado, odbc/odbcbase, mysql, adabas (see above)
