Issue Description: SQLite data storage setting chokes on Fabric 1.17.1 despite sqlite jar being present

I understand the version I am using a snapshot version so if this issue isn't appropriate I understand.

• Dynmap Version: core=3.2-SNAPSHOT-493, plugin=3.2-SNAPSHOT
• Server Version: Fabric 1.17.1
• Pastebin of Configuration.txt: https://pastebin.com/thAS9KLq
• Server Host (if applicable): Local
• Pastebin of crashlogs or other relevant logs: https://pastebin.com/vLVrCEbr
• Other Relevant Data/Screenshots: N/A
• Steps to Replicate: Fresh fabric install, add dynmap, set config to use sqlite, try to start server

[x] I have looked at all other issues and this is not a duplicate
[x] I have been able to replicate this

This is a complex problem. Specifically: we can't just bundle (shadow) sqlite jar, as other mods might do it as well, and that would cause version conflicts (it's not possible to load multiple versions of a C library). The best solution would be to talk to Fabric devs about creating an "official" Fabric sqlite mod - that every mod out there could use without fear of version conflicts. AFAIK "just" dropping the sqlite driver jar in the mods folder won't work - it needs a valid fabric.mod.json to be loaded.

Quick update, using jij for it should work fine without any compatibility issues. Fabric 's build system can convert any non mod library into valid mod (if you use include that is) which should have good compatibility

@Patbox - is that a tip for the dev, or for OP?

@20BBrown14 - this might come under 'known problem/cant solve' - have you got yourself a different option and sorted yourself?

For dev ofc, as it's something that should be done by mod

I've gone ahead and packaged the SQLite JDBC in the form of a Fabric/Forge mod:

https://www.curseforge.com/minecraft/mc-mods/sqlite-jdbc
https://github.com/kosma/sqlite-jdbc

It's an early release, but if you're brave, try grabbing a jar from the Releases section on Github and see if it works for you.

Quick update, using jij for it should work fine without any compatibility issues. Fabric 's build system can convert any non mod library into valid mod (if you use include that is) which should have good compatibility

It's not safe to jij or shadow a JNI library because the linker symbols can't be relocated. This is prone to creating latent errors and we will not support it.

JiJ should be fine, as it only changes path of the jar, everything should load from it fine (as no class names/packages change). Tested with BanHammer and no one reported issues yet

JIJ will be fine as long as all mods bundle the same version. If multiple mods bundle different versions, one will be loaded, and you won't have much control over which one.
Shadowing is definitely not safe - you'll end up loading JNI symbols from two sources, and I don't have a clue if this will even work (and collide in unpredictable ways) or just flat out cause things to explode.

Bundling different versions should be fine as long as there is no breaking change, which has rather low probability for that library. Fabric by default always loads latest which shouldn't cause issues

This problem is still kinda there with versions:

• Dynmap 3.4-828
• Minecraft 1.19.2
• Fabric Loader 0.14.9

Dynmap notes the missing SQLite-JDBC ...

[22:02:58] [Server thread/INFO]: [Dynmap] Opening SQLite file ---snip---\dynmap.db as map store
[22:02:58] [Server thread/FATAL]: [Dynmap] SQLite-JDBC classes not found - sqlite data source not usable
[22:02:58] [Server thread/FATAL]: [Dynmap] Map storage initialization failure

... but continues starting anyway for no reasons - even starting the webserver - and distracting the user/admin with a failure-trace(?) that doesn't really hint at the actual missing class noted earlier.

[22:03:02] [Server thread/FATAL]: [Dynmap] Error loading maptype
java.lang.reflect.InvocationTargetException: null
	at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77) ~[?:?]
---snip---
Caused by: java.lang.NullPointerException: Cannot invoke "org.dynmap.markers.MarkerAPI.getMarkerIcon(String)" because "this.api" is null
	at org.dynmap.MarkersComponent.<init>(MarkersComponent.java:56) ~[Dynmap-3.4-fabric-1.19.1.jar:?]
	... 17 more
---snip---
[22:03:03] [Server thread/INFO]: [Dynmap] Web server started on address 0.0.0.0:8123`

It took me way longer than expected to find @kosma's solution (thx btw., seems to work fine) and the configuration.txt is different from the spiggot one - # All paths ... are relative to Dynmap's data-folder: <different paths depending on Fabric/Spigot> (so it's not entirely hard coded) - but contains no warning regarding the use of SQLite on Fabric. :-/

OT: And after backing up my ~3,4GiB Dynmap SQLite DB with 7Zip I noticed the very good compression rate.
-> Activated NTFS's transparent otf file compression (C-attribute) on the db-file and now it occupies only ~2,1GiB.
Maybe useful for others running their server on Window$.