desruisseaux commented on PR #37: URL: https://github.com/apache/sis/pull/37#issuecomment-1670467970
The refactoring that we could do without breaking the build were already done. It was the topic of #34. When I was working on modularisation, I was preparing those two merge requests simultaneously with lot of "git rebase" and squashes. This merge request contains commits that couldn't be moved to the "pre-migration" phase. The reason why JPMS had to be done before Gradle migration is because the _Module Source Hierarchy_ is not just about resolving package name clashes. It is a more disruptive feature, supported by standard Java tools since Java 9 but not well known, maybe because neither Gradle or Maven supports it (but Gradle flexibility makes possible to get it working anyway). Module Source Hierarchy is explained briefly in the [Directory Hierarchies](https://docs.oracle.com/en/java/javase/20/docs/specs/man/javac.html#directory-hierarchies) section of Oracle's documentation. I tried to explain more in section 1 of [Java Module Source Hierarchy in a Gradle sub-project](https://geomatys.github.io/draft/Modularization.html) page. Finally I opened issue https://github.com/gradle/gradle/issues/25974 for better support of this feature. It is the application of Module Source Hierarchy, not the addition of `module-info.java` files, which implies a very different way to build the Gradle scripts. So JPMS cannot be moved after Gradle migration, because the migration work is too different depending if done before or after Module Source Hierarchy. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
