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

[Barry DeZonia]

Hi Even,

Maybe I should be more clear.

My java project (built with Maven) has this dependency:

<dependency>
  <groupId>org.gdal</groupId>
  <artifactId>gdal</artifactId>
  <version>3.8.0</version>
</dependency>

So if someone has installed gdal 3.8.x (including the java bindings)
my code will work with it. But this seems to imply that if I want to
support 3.4.x I need to change the dependency to 3.4.0.

So maybe I would make my project build 11 jars. The 1st jar would be
myjar-gdal-3-0 which has my code that interacts with gdal via the gdal
java dependency 3.0.0. Similarly I could have myjar-gdal-3-1,
myjar-gdal-3-2, ... and myjar-gdal-3-10. Each with its own gdal
dependency.

Note that I do not share anything with people except a single jar (so
no dylib stuff to bundle along). If some version of gdal 3.x is
installed with the java bindings present then one of my jars should
suffice. Though the developer has to specify exactly which jar version
to use.

Now also consider that my project relies on another 3rd party library
that has 5 versions. If I want to support every combo of gdal and this
3rd party library then it sounds like I'd need to build 55 jars (11
gdal 3.x.0 java jar versions paired with 5 3rd party library
versions). This is rapidly very difficult to do.

Example:

  myjar-gdal-3-2-3rd-party-lib-v1.jar
  myjar-gdal-3-2-3rd-party-lib-v2.jar
  myjar-gdal-3-2-3rd-party-lib-v3.jar
  myjar-gdal-3-2-3rd-party-lib-v4.jar
  myjar-gdal-3-2-3rd-party-lib-v5.jar
  ...
  myjar-gdal-3-5-3rd-party-lib-v1.jar
  ...
  myjar-gdal-3-10-3rd-party-lib-v3.jar
 ...
  etc.

Also I know I am simplifying because occasionally the gdal.jar file
might change more than once during the 3.y.* development during
subrelease y. (I know this because either 3.7.x or 3.8.x had two gdal
jar releases during its dev cycles).

I am really curious how people are solving this kind of problem
without pulling out their hair.


On Thu, Nov 7, 2024 at 2:46 PM Even Rouault <even.rouault at spatialys.com> wrote:
>
> 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.
>