[gdal-dev] Advice on deploying components that use GDAL

[Even Rouault]

Barry,

I'm not totally sure to have the full picture of what you 
deploy/distribute. I'd assume the main difficulty for the end users of 
your Java component is to get the GDAL native library, and probably even 
more tricky, the libgdaljni.so/dll/dylib. If you assume they have 
managed libgdal itself, then you could distribute gdal.jar + 
libgdaljni.so/dll/dylib (possibly in several CPU architectures depending 
on what you target...) of the minimum GDAL version you want to support 
(in theory you should be able to use libgdal native 3.X against 
gdal.jar/libgdaljni 3.Y if X >= Y as it relies only on the C API which 
we normally guaranteed to be ABI backwards compatible in the 3.x 
series). If you want to support GDAL >= 3.8 and < 3.8, I'm afraid you'll 
have to provide a gdal.jar + libgdaljni combo of let's say GDAL 3.0 (or 
a later release), and another one of 3.8

By the way, I've seen use of Panama 
(https://openjdk.org/projects/panama/) to avoid the need of JNI at all: 
https://github.com/apache/sis/tree/main/optional/src/org.apache.sis.storage.gdal/main/org/apache/sis/storage/panama 
.  So in theory that could makes things simpler (at least you wouldn't 
need the libgdalalljni.so/dll/dylib native code). Haven't tried it / 
can't comment on the appropriateness of that particular code.  Perhaps 
at some point someone will need to reboot the GDAL Java bindings to be a 
Panama project if JNI is abandonned (and that would likely be totally 
disconnected from SWIG. At least 
https://github.com/search?q=repo%3Aswig%2Fswig%20panama&type=code 
doesn't show any sign)

Even

Le 07/11/2024 à 20:45, Barry DeZonia via gdal-dev a écrit :
> Hey all,
>
> I hope this is the right place for this email. I am a developer that 
> has written a java component that interfaces with the java bindings 
> and allows my app users to access gdal data.
>
> The problem I have is that gdal seems to release somewhat often. I 
> wrote my code initially for 3.7 but later used 3.8 (and abandoned 3.7) 
> due to some new features present in the java bindings. Since then 
> there have been gdal releases for 3.9 and 3.10.
>
> How should I release my (java jar) component?  One release version per 
> gdal release? Then am I forcing a similar fork in all downstream 
> projects that use my components? It seems so.
>
> Now also imagine my component relies on something else that also has 
> multiple versions. I could get a combinatorial explosion in the number 
> of versions of my plugin.
>
> And I also seem to need to make a decision on how to nicely target 
> older gdals that don't have the new java niceties of 3.8. Many people 
> are using gdal versions older than 3.8.
>
> This whole topic is making my head spin a little. Any advice?
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.