Quick report on OGC/OSGeo/ASF code sprint

[Martin Desruisseaux <ma...@geomatys.com>]

Hello all

The joint OGC/ASF/OSGeo code sprint was this week near Lausanne [1]. A 
joint report of activity will be published later. For the part specific 
to Apache projects, below is a small summary of what we did.


    Apache Sedona

Sedona did a presentation about their background and architecture. The 
ST_Distance function was taken as an example for showing how it is used 
in a query, and what kind of geodetic calculations it requires under the 
hood. The geodetic services in Sedona are currently handled by GeoTools, 
which is a LGPL library. The licensing issue that it poses for an Apache 
project was discussed, as well as concerns about whether GeoTools 
referencing services are maintained. A proposal to migrate to Apache SIS 
was presented.

We did not had the time to start actual coding work on a migration 
experiment. Anyway such work could not be completed before either Apache 
SIS offers all features that Sedona needs (SIS currently misses a 
GeoTIFF writer and a ShapeFile reader), or before GeoTools resolves its 
conflict with GeoAPI (see "GeoAPI" section below) for allowing the two 
projects to coexist. Both issues are expected to be at least partially 
resolved by this autumn.


    Apache Baremaps

Baremaps did a 5-minutes pitch showing the project features. Bertil was 
physically present at the event, which has been a great opportunity for 
discussions.

Bertil: would you like to expand more on what happened on Baremaps side 
during those 3 days?


    Apache SIS / GeoAPI

We did not had the time to work on Apache SIS directly. But on the 
GeoAPI side (which SIS implements), we had an announcement concerning 
the resolution of "org.opengis" package name collision with GeoTools 
[2]. A GeoTools PMC representative announced that they were going to 
work on this issue in August, by stopping to use the "opengis" name on 
their side. My expectation is that this issue will be resolved for next 
GeoTools release. This is a significant announcement for any Apache 
projects that could benefit from SIS services, such as Apache Sedona and 
Baremaps.

During the code sprint, we completed the full migration of PROJ-JNI [3] 
and GIGS [4] to Java 11. Actually those two projects were already Java 
11 compatible, but the service providers were still registered in the 
Java 8 way. Service providers are the Java standard mechanism by which 
an application such as GIGS can detect automatically which GeoAPI 
implementation is available at runtime, without any previous knowledge 
of GIGS about those implementations. Before Java 9, services were 
registered by putting files in the META-INF/services directory, and 
third-party JAR files were loaded dynamically at runtime using 
ClassLoader. Since Java 9, services are registered by declaring them in 
the module-info.java file, and third-party JAR files are loaded 
dynamically at runtime using ModuleLayer. Upgrading GIGS code base to 
use ModuleLayer worked well on the Java side. The biggest difficulty was 
not with Java, but with Maven. The problem is that even if a project is 
fully modularized in the Java 9+ way, Maven exec:java goal still 
launches the application using "java --classpath" when it should use 
"java --modulepath". The consequence is that Maven systematically 
launches Java in a kind of Java 8 compatibility mode, which causes 
difficulties in finding services declared in the Java 9+ way.

Apache SIS has not yet been migrated to a fully Java 9+ modularized 
project. Consequently, GIGS tests may temporarily not work anymore on 
SIS. We will try to fix that issue before next SIS release, by finishing 
the Jigsaw modularisation of SIS.

     Martin

[1]https://github.com/opengeospatial/developer-events/wiki/Open-Standards-and-Open-Source-Software-Code-Sprint
[2]https://desruisseaux.github.io/history/GeoAPI.html
[3]https://github.com/OSGeo/PROJ-JNI
[4]https://github.com/IOGP-GIGS/GIGSGeoAPI