build: Moving OTP to its own Maven module, refactor out Raptor into its own module #6130
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TL; DR: This turns OTP into a multi-module project. Discussion required.
Summary
This changes the project from being a single-module setup to have multiple Maven modules. There was consensus for changing the build to this at the OTP Berlin developer days, this is an attempt to do that.
There was also an agreement to move Raptor out of the core module so that has been done at the same time. In order to get it done, a few files was moved to a shared
framework
module. The classes that are there are the bare minimum to get Raptor to compile.Note that since this PR moved around all source file, this PR will most likely mess up many other PRs that will have to be rebased so choose when it is integrated with caution.
Questions:
modules/
. The main code live undermodules/otp
, Raptor is undermodules/raptor
./.git-blame-ignore-revs
.framework
module. Should it be renamed tolang
,utils
or something similar? I think it would be nice to separate it from the framework package that is inside OTP, both in name and package name.Future TODOs:
Clean up the dependency list.
Recommendation: keep all dependencies in the dependency management section in
/pom.xml
. Use properties to manage the version across group IDs as it is done today. Remove anyversion
tag from child modules.Apply useful Maven plugins
Look to see if there are any useful rules from the Enforcer plugin that you want applied. In particular the
requireSameVersions
rule might be useful: https://maven.apache.org/enforcer/enforcer-rules/requireSameVersions.html.Documentation
No documentation is updated in this PR. Should definitely be done later.