Proposal: Modularize Project into Separate Core, Eclipse, and Maven Plugin Repositories

[hazendaz]

Proposal: Modularize the Project for Independent Releases

I propose splitting this project into independent modules to enable more flexible and frequent releases. Currently, the site pages, core, and Eclipse components are maintained as separate builds, with custom handling for actions and deeply nested Maven plugin structure. This complexity makes it difficult to manage releases and limits future extensibility, such as supporting Gradle.

Suggested Approach:

•  Separate the project into generator-core and generator-eclipse modules. Since generator-core is already published to Maven Central and generator-eclipse has infrequent releases, this split should have minimal impact and improve maintainability.
•  Remove the Maven plugin from the main repository. This would allow the plugin to be released independently, in line with Maven’s ongoing changes (notably with Maven 3.9 and upcoming Maven 4). The plugin is already compliant, but decoupling it would make it easier to demonstrate compatibility and adapt to future changes. Additionally, this separation would make it easier to introduce a Gradle plugin in the future, should there be interest.

Implementation Notes:

•  These changes can be implemented incrementally.
•  As @jeffgbutler noted, the Maven plugin is used in core integration tests and must be able to override the generator core version. This can be handled by adding a dependency block to the plugin and specifying the desired core version, which is straightforward and easy to verify.  Having a specific action to simply test the snapshot of core at any given time would be applicable.

On Git History:

•  To preserve project history, I recommend retaining the current repository as core, cloning new repositories for the other modules, and removing unnecessary components from each. This approach maintains a clear audit trail and avoids accidental loss of information. Alternatively, we could restructure without preserving history, but keeping it is generally preferable.

Next Steps:

•  Before proceeding, we should complete a successful release to ensure the project is stable, as it has been several years since the last one.