Ongoing work: Jigsaw modularization

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

Hello all

This is a report about ongoing work on Apache SIS. Since we upgraded 
from Java 8 to Java 11, we take the opportunity for applying the Java 
Platform Module System (JPMS) on the project. This work is done in a 
separated repository for now and is a little bit long. Because it is a 
big change, we would like to submit it for a vote when it will be ready. 
The current state of the work can be seen there:

    https://github.com/Geomatys/sis/commits/Jigsaw

A big part of the work is to change the way to load services and 
resources. JPMS adds restrictions about what a module can load. It 
become difficult to load a resource from another module, so we have to 
modify the code in such a way that calls to java.util.ServiceLoader or 
Class.getResourceAsStream(…) are done from the module that uses the 
service or owns the resource, and not from an utility module. Commits 
related to JPMS restrictions are:

  * Upgrade Jakarta XML binding from version 2 to version 4 (done last
    week by lazy consensus)
  * Move a test class for avoiding package collision between two modules
  * Add public static provider() methods (as expected by ServiceLoader)
  * Remove the DefaultFactories class because it does not work in the
    context of JPMS
  * Move TemporalUtilities to the metadata modules since it is not
    needed by the utility modules
  * Remove deprecated dimension attributes from OperationMethod
  * Remove the use of internal LazySet as a workaround for JDK 8 bug
    since it is no longer necessary
  * Delegate the loading of GeoAPI resources to GeoAPI itself
  * Replace TypeRegistration.hasRenameFile(…) by a mechanism in which
    the `TypeRegistration` subclass fetches itself the resource
  * Remove usage of ResourceBundle.Control because it is not supported
    in the context of named modules
  * Add module-info.java files and migrate the declarations of service
    providers
  * Replace reflection by ServiceLoader uses in the `OptionalDependency
  * Opens to JAXB implementations the classes to be marshalled in XML

In addition to above work for JPMS restrictions, we also have work 
related to Maven restrictions. I found no way to take full advantage of 
JPMS using Maven. Doing JPMS with Maven is not impossible, but forces 
project to restrict themselves to a subset of JPMS advantages. We will 
post a blog later giving more explanation. So for maximal benefit from 
JPMS, it seems necessary to migrate to Gradle or other build system with 
similar flexibility. The next commits listed below are for this migration:

  * Remove the NetBeans Ant project, replaced (for now) by Maven
  * Remove all Maven project files and documentation files which will
    become obsolete
  * Move directories of all source codes. The new directories are the
    module names, as required by Java compiler when building a
    modularized project
  * Add Gradle build scripts

This branch gets frequent squashes and rebases, which is why the work is 
done on a separated repository until it stabilize. While a significant 
change in internal code and in the build system, those changes should 
have few visible impact on the public API. So from the user point of 
view, it should stay a minor SIS upgrade.

I will post more news when the work will be ready.

     Martin