On Sep 23, 2026, at 3:19 PM, Sebastian Reitenbach <[email protected]> wrote: > > Hi, > > my /usr/local/share/java looks alike: > > total 5344 > drwxr-xr-x 8 root wheel 512 Sep 22 16:58 . > drwxr-xr-x 246 root wheel 4608 Sep 22 16:58 .. > drwxr-xr-x 10 root wheel 512 Sep 15 13:43 ghidra > drwxr-xr-x 5 root wheel 512 Sep 15 14:59 gradle > drwxr-xr-x 2 root wheel 512 Sep 15 14:59 opencv4 > drwxr-xr-x 2 root wheel 1024 Sep 22 16:51 openjfx > drwxr-xr-x 2 root wheel 512 Sep 15 21:28 sevenzipjbinding > -rw-r--r-- 1 root bin 2543583 Sep 22 16:57 sleuthkit-4.15.0.jar > -rw-r--r-- 1 root bin 142214 Sep 22 16:57 sleuthkit-caseuco-4.15.0.jar > drwxr-xr-x 2 root wheel 512 Sep 18 21:45 sqlite-jdbc > > > because of examples of ghidra, gradle, opencv4, I did create port dependent > subdirs, i.e. openjfx, sevenzipjbinding, sqlite-jdbc. > Sleuthkit is a bit alienating, but that was where it ended up by default, > probably should move it into a sleuthkit subdir as well. > > > Your sqlite-jdbc, puts it into the more general /usr/local/share/java/classes. > Don't know what's the "standard", but I my gut likes the independent > subdirectories by port, but I could also update all my new ports, to store > jars in /usr/local/share/java/classes like sqlite-jdbc does. > > Any objection to rename it to sqlite-jdbc?
Yes, the convention on OpenBSD for jar’s like this is to install it in MODJAVA_JAR_DIR unversioned. See jna, protobuf-java, tanukiwrapper, etc. > > Also your version seems to be newer, that the one I picked from the > dependencies off of sleuthkit. > > In any case, it fails to build: I have updated it to the latest version, fixed the build errors and rerolled the maven dependancies. See attached v2. I have tested this on aarch64/amd64/i386/sparc64 they all report: [INFO] Tests run: 465, Failures: 0, Errors: 0, Skipped: 8 > But then in autopsy, there's the version hardcoded many times: You can patch all those places to the unversion jar or copy the unversioned jar into the version that it expects in a post-extract makefile target. If the api is stable this will work, if not you will need to update to the new api with patches. I would try the copy approach to reduce the set of patches you need to maintain first. > With the build.xml It's basically injecting the sqlite-jdbc.jar into the > autopsy.jar. And the other xml files are there to tell autopsy, where to find > it (If I understand correctly) > I've no idea, if there would be a switch to tell it to not embed > sqlite-jdbc.jar (maybe patch the Core/build.xml to stop copying in the first > place?) and rather to include > the sqlite-jdbc.jar that's available via the port? You can allow it to embed the sqlite-jdbc.jar into autopsy.jar. The java ecosystem does not conform with BSD build practices and forcing it to will spiral into a set of patches you may not want to maintain. Best, -Kurt
sqlite-jdbc_v2.tgz
Description: Binary data
