Martin, I've been following the development on this as I've been working for a while on adding JPMS support to the OpenSearch codebase ( https://github.com/opensearch-project/opensearch/issues/5910). 💯 support this effort. FWIW, the same approach was taken on Lucene. For ~1 year Mark Miller (pretty much single handedly) switched Lucene from ant to gradle first. Then module-info.java was added to each Lucene module and API classes carefully exported.
Quick question. Are there corners of the SIS code base that could also benefit from some of the other JDK JEP improvements (e.g., Valhalla, Panama)? Perhaps we could explore adding SIMD optimizations through the java vector incubating API with JDK 20 runtime? I think moving to JPMS and a gradle build system would make this easier and we could cross breed some of the MRJAR and Panama API integration work done on Lucene. On Sat, Jul 29, 2023, 10:13 AM Martin Desruisseaux < [email protected]> wrote: > Hello all > > This is a proposal for a major restructuring of Apache SIS source code. > This proposal would impact SIS developers, but not users. For all users, > package names and Maven coordinates will stay unchanged. > > The goal is to apply Java Platform Module System (JPMS) modularisation, > also known as "Jigsaw", on the Apache SIS project. At the minimum, JPMS > requires that we add a "module-info.java" file at the root of every > modules. It has various consequences, some of them already resolved > (e.g. ensuring that no module use the same package name, adapting > various usages of ServiceLoader, resources and reflections for module > encapsulation). However while some JPMS is possible with Maven, taking > full advantage of JPMS requires source code restructuring. This is > because all Java versions up to Java 8 supported only one way to > organize the source code, known as Package Hierarchy, but Java 9 > introduced a second way to organized source code, known as Module > Hierarchy. Not many peoples are aware of this second layout, maybe > because it is not supported by Maven or Gradle. But it is the layout > used by OpenJDK for example. > > Getting Maven to work with Module Hierarchy would be very difficult. > However it is possible with Gradle, because of its flexibility. So the > proposal to restructure source code according the Module Hierarchy > implies migrating from Maven to Gradle. This work has been done and > tested on a branch, and has reached a point where I think it can be > submitted to SIS PMC. The following link describes in more details what > is a Module Source Hierarchy, how we propose to restructure SIS source > code, and how to get Gradle to work with it. > > https://geomatys.github.io/draft/Modularization.html > > Content: > > * Overview of directory layout change > * Apache SIS restructuring > * Gradle configuration for Module Source Hierarchy > o Gradle issues and workarounds > * Advantages of Source Module Hierarchy > * Limitations of Source Module Hierarchy > * Quasi-blocker Maven bug > * Conclusion > o Ideas for Gradle evolution > > I would like to start a discussion about whether peoples agree/disagree > with the proposed plan. If we reach an agreement, I will prepare later > in August a pull request to be submitted to PMC vote. In the meantime, I > plan to fill issues on Gradle GitHub for making proposals for easier > support of Module Hierarchy in Gradle. > > Reminder: this change should have no significant impact on users. The > same Apache SIS JAR files will continue to be deployed on Maven Central > under the same groupId and artifactId, with the same "org.apache.sis" > packages. > > Martin > >
