Hi,
On Fri, Sep 25, 2026 at 1:16 AM Kurt Miller <[email protected]> wrote: > 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. > that indeed seems to be the way of least resistant. Embedded into sleuthkit and autopsy that way worked. The only thing I wonder: you install in /usr/local/share/java/classes, whereas there are other ports, that install in /usr/local/share/java/<portname>, i.e. opencv4. For openjfx and sevenzipjbinding, I chose the <PORTNAME> subdirectory, but could put them into classes as well. For autopsy then I have this in the config file: -J-Djava.library.path=/usr/local/lib/sevenzipjbinding:/usr/local/share/java/opencv4:/usr/local/lib with everything in classes, it would make it shorter here, but I don't know, would it pick up stuff it won't need? cheers, Sebastian > > Best, > -Kurt > > > > > -- https://buzzdeee.reitenba.ch
