libgdal-java needs to be added to the nightly osgeo repo

[misev]

On OSGeoLive 14, libgdal-java is the standard Ubuntu 20.04 version 3.0.4, but the rest of GDAL libs and tools is 3.2.0. So there's an incompatibility which causes errors in applications that use libgdal-java, e.g. rasdaman gets this bogus error:

java.lang.RuntimeException: OGR Error: General Error

[Bas Couwenberg]

The libgdal-java binary package is no longer built since gdal (3.1.0~rc1+dfsg-1~exp1) because it prevented building gdal and its reverse dependencies on architectures for which Java is not available (​Debian Bug #947960 - gdal: Doesn't build on ports without java).

[misev]

The OSGeoLive 14.0 supports Java fine though, and installs GDAL from an unofficial package repo. This needs to be resolved somehow on OSGeoLive: either add libgdal-java to this package repo, or install GDAL from the standard Ubuntu 20.04 repos. Otherwise GDAL is broken, as it's missing the Java bindings.

[misev]

I had to compile gdal 3.2 manually, include libgdalalljni.so in the rasdaman package, and then copy it in the install_rasdaman.sh script to fix this.

[kalxas]

Thanks, I will see if I can get the java bindings back for our ppa only.

[kalxas]

Ticket retargeted after milestone closed

[edso]

wrt. OSGeoLive15, current alpha1 iso

just wanted to check OpenJUMP gdal support and noticed gdal-jni is missing. seems like the above still stands or even worse, there isn't even a libgdal-java package anymore in Ubuntu 22 Jammy ​https://packages.ubuntu.com/search?suite=all&arch=any&searchon=names&keywords=gdal-java

the installer can probably download and build it, but it'll probably easier just to provide it.

opinions?

[edso]

just took some spare time to try and build the missing java jni. i succeeded for simplicity sake with Lubuntu22's default gdal 3.4.1

1. install in a virtual machine
2. activate deb+src apt entries, apt get update

now pretty much as explained here ​https://www.ducea.com/2008/03/06/howto-recompile-debian-packages/ patch/rebuild the package

3. apt-get install devscripts build-essential, apt-get build-dep gdal-bin

we need java and ant for the java-bindings

4. apt-get install openjdk-8-jdk openjdk-8-source ant
5. as user, apt-get source gdal-bin
6. cd gdal-3.4.1+dfsg/
7. edit debian/rules, add --with-java after override_dh_auto_configure:
8. edit swig/java/java.opt JAVA_HOME to point to /usr/lib/jvm/java-1.8.0-openjdk-amd64
9. build debuild -us -uc

this resulted in the deb packages built, but java-jni was still missing. so i ran that explicitely

10. cd swig/java/
11. make

dunno why i needed to run it explicitely. the resulting swig/java/libgdalalljni.so however worked as expected.

not sure if that can be integrated into the updated gdal-3.4.3 package on ​https://launchpad.net/~osgeolive/+archive/ubuntu/nightly/+packages

although the above result will likely work for all 3.4.x versions, the java-binding can probably be built from the updated package as well.

[Bas Couwenberg]

Reverting this change should be your starting point to get Java support back into the gdal package:

​https://salsa.debian.org/debian-gis-team/gdal/-/commit/936e50e1a9e5eb3d1bd10147b5d5c25476845b23

From 3.5.0 onwards that will need to be adapted to CMake.

[edso]

thx Bas,

looks like lot to just build it for a one arch LiveCD :). simply prebuilding it for amd64 and place the prebuilt binaries looks like the way to go.

@kalxas do you agree? if so i'd be willing to build/zip and place it in our OJ/osgeo file space.

[misev]

This is what we did as well for rasdaman, use prebuilt binaries for amd64. In case you want to reuse it: ​https://download.rasdaman.org/installer/tpinstaller/ubuntu2204/

[Bas Couwenberg]

Not building libgdal-java from the gdal source package will make it go out of sync quickly.

If you don't want to hassle to maintain the gdal packaging changes for OSGeoLive, you could download the JAR from Maven Central in install_rasdaman.sh or install_openjump.sh:

​https://search.maven.org/artifact/org.gdal/gdal

For example:

cd /usr/share/java
GDAL_VERSION=$(apt-cache show libgdal-dev | grep Version | awk -F': ' '{print $2}' | sort | tail -1 | awk -F'.' '{print $1"."$2".0"}')
wget https://repo1.maven.org/maven2/org/gdal/gdal/${GDAL_VERSION}/gdal-${GDAL_VERSION}.jar
ln -s gdal-${GDAL_VERSION}.jar gdal.jar
cd $OLDPWD

[edso]

Not building libgdal-java from the gdal source package will make it go out of sync quickly.

shouldn't be an issue, as the gdal version is fixed on OSGeo-LiveCD and won't change after release. maybe it's worth spending some effort when gdal 3.5 will be used (wrt. to the cmake switch you mentioned)

If you don't want to hassle to maintain the gdal packaging changes for OSGeoLive, you could download the JAR from Maven Central in install_rasdaman.sh or install_openjump.sh

from my experience, the issue usually isn't the gdal's lightweight jar binding, but the JNI, which isn't contained in it and needs to match the system's gdal. that's what's currently missing.

[edso]

Replying to misev:

This is what we did as well for rasdaman, use prebuilt binaries for amd64. In case you want to reuse it: ​https://download.rasdaman.org/installer/tpinstaller/ubuntu2204/

as it mentions no version, i'll assume this was built for/with gdal-3.4.1 then too, right?

[kalxas]

Sounds ok to use a pre-build archive for the java bindings, please keep in mind that we have gdal 3.4.3 in our ppa.

[kalxas]

​https://github.com/OSGeo/OSGeoLive/pull/324

[kalxas]

Can someone please confirm this setup works now?

[edso]

downloading ​https://download.osgeo.org/livedvd/nightly/osgeolive-nightly-build110-amd64-2514c6c-master.iso is slow.

will have a look later.

[edso]

tried build110 iso and works for me.

[misev]

I just had to do the manual build for Ubuntu 24.04 as well, following similar steps as in comment:7 except in debian/rules you append a CMake option now -DBUILD_JAVA_BINDINGS=ON.