[GitHub] [sis] desruisseaux commented on pull request #37: Migrate from Maven to Gradle and apply JPMS modularisation

["desruisseaux (via GitHub)" <gi...@apache.org>]

desruisseaux commented on PR #37:
URL: https://github.com/apache/sis/pull/37#issuecomment-1668622209

   We could split in separated merge requests, but the migration from Maven to Gradle is very different depending on whether it is done before or after restructuring from _Package Hierarchy_ to _Module Source Hierarchy_. If we migrate to Gradle before, it would be like doing the migration twice given the amount of changes needed in Gradle scripts and plugins (`buildSrc`) after restructuring to Module Source Hierarchy.
   
   Currently the separation is done in commits as below. Those commits are in dependency order, and each of them could be taken as a merge request on its own (git "squash" and "rebase" were done extensively).
   
   1. Cleaning work
       * Remove the NetBeans Ant project
       * Remove test JAR files. Consequently tests cannot be executed anymore (temporarily)
   2. Partial JPMS
       * Add `module-info.java`. Project can still be executed with Maven, but not tested.
   3. Restructuring from Package Hierarchy to Module Source Hierarchy
       * Remove all Maven project files (because they don't work at all with Module Source Hierarchy)
       * Move all Java source files to their new location with no change in any code.
       * Post move cleanup (code changes caused by restructuring are separated in this commit).
   4. Migrage from Maven to Gradle.
       * Add Gradle build scripts, adapted to Module Source Hierarchy.
       * Documentation updates (mostly editions in Javadoc).
   
   As seen above, the commits are in 4 groups which could be separated in 4 merge requests. The reason why they are proposed in a single merge request is because the project is temporarily unbuildable and/or untestable during some intermediate steps. The project is back to buildable and testable state only after the last commit (ignoring the documentation updates).
   
   So would it still be better to split in 2 or more merge requests anyway?


-- 
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: issues-unsubscribe@sis.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org