feat: EXPOSED-758 Add Exposed Maven plugin for migration script generation

[Frederik Pietzko (frederikpietzko)]

Description

Summary of the change: Adds Exposed Maven Plugin to generate Flyway Migrations

Detailed description:

• Why: Kotlin Maven projects cannot use the gradle plugin
• What: Added Maven plugin and extracted the Gradle plugins core logic into its own module to be relied on by both Maven and Gradle plugins, and I also tried to add reasonable documentation.
• How: Extracted core logic from Gradle Plugin into its own module, also moving relevant tests. Refactored Gradle Plugin to and map configuration to the shared configuration model. Added Maven plugin also relying on shared module.

---

Type of Change

Please mark the relevant options with an "X":

• Bug fix
• New feature
• Documentation update

Updates/remove existing public API methods:

• Is breaking change -> small brake in gradle dsl, because of changed package for VersionFormat

Affected databases:

• MariaDB
• Mysql5
• Mysql8
• Oracle
• Postgres
• SqlServer
• H2
• SQLite

Checklist

• Unit tests are in place
• The build is green (including the Detekt check)
• All public methods affected by my PR has up to date API docs
• Documentation for my change is up to date

---

Related Issues

EXPOSED-758

[Frederik Pietzko (frederikpietzko)]

Integration Testing this not really straightforward. Only reasonable option I can think of would be to run Maven from the test which would require a maven binary installed both on in ci and developers machines.
Does this sound acceptable?

[Chantal Loncle (bog-walk)]

Thanks for working on this PR Frederik Pietzko (@frederikpietzko) 🎉 Will start the review process.

One initial note, we only ever call dokkaGenerate on release PRs. If all the docs/api files are left in this PR, and the PR is eventually merged to main, these files would be immediately published from main and visible on the public api reference page. Even though the feature itself would not yet be publicly available/released 🙁

So please revert all changes to docs/api folder.
The added documentation-website snippets and topics and the module api changes from calling apiDump are all good and helpful though, and should remain in.

[Chantal Loncle (bog-walk)]

Leonid Stashevsky (@e5l) Integration testing wasn't the most straight-forward for the Gradle plugin either, but we did manage to start getting some in --> tests. Any objections to the Maven integration testing suggestion put forward by Frederik Pietzko (@frederikpietzko) above?

[Frederik Pietzko (frederikpietzko)]

One initial note, we only ever call dokkaGenerate on release PRs. If all the docs/api files are left in this PR, and the PR is eventually merged to main, these files would be immediately published from main and visible on the public api reference page. Even though the feature itself would not yet be publicly available/released 🙁

So please revert all changes to docs/api folder. The added documentation-website snippets and topics and the module api changes from calling apiDump are all good and helpful though, and should remain in.

Removed docs/api changes. Should i move the documentation-website snippets into a seperate stacked PR, or are they fine staying in here?

[Chantal Loncle (bog-walk)]

It's certainly a bit easier to review if documentation comes afterwards in a separate PR, especially as I would request an additional final review from our technical writer. Some parts of the documentation may end up changing depending on whether there are requested changes over the review iteration. Ultimately, it's not a problem for me to review as it is now, but if it is easy for you to divide and put aside the documentation, go for it.