HV-2001 Generate module-info for published artifacts

[marko-bekhta]

https://hibernate.atlassian.net/browse/HV-2001

This is the first iteration to generate module-info for published artifacts. It is based on https://github.com/hibernate/hibernate-validator/pull/1364 as it has some useful cleanups that make module-info generation cleaner (hence, opening only as a draft for now).

Only the last commit in this PR is really relevant to module-info.

I added specific plugin configurations to each module as it seems that each of them has specific needs and there's not much in common...

test utils module

This one seems pretty straightforward. I've dropped the dependency on testng, as it was there just for a few assert calls that we can replace with the assertj ones. The constraint assert that this util jar offers is based on assertj, so it makes sense to keep assertj 😃.

There is a simple test (test-utils).

engine (actual validator)

The plugin couldn't pick up which services are loaded via ServiceLoader so I've listed those explicitly. all seems to work fine and look ok until we get to CDI stuff... CDI needs reflection access to ValidatorImpl, ValidatorFactoryImpl and all constraint validator implementations... so that means we have to open the packages that contain those classes .... but open to CDI impl, which is ... ? so I just have them opened to all (at least for now).

Going back to the CDI stuff... I wonder whether we should move the classes around, maybe to some SPI packages for the things that are potentially instantiated through the CDI?

There are tests for the case with EL (simple) and without EL dependency (no-el).

CDI

see the comments to the engine section just above. Another problem is that Weld is using the previous version of JBoss Logging. This leads to the test failure since Weld cannot access the logger correctly in the module test.

I've moved some classes around as CDI needed reflection access to some of the classes in this module and they lived in an internal package.

The test is currently disabled (cdi), but I've tested it locally using the previous version of the logging jar.

Annotaion processor

This one seems pretty straightforward as it doesn't really have any dependencies, and the AP is added as provided to the module info by the plugin automatically.

With that, I'm not sure what would be a good way to test it, just run a compile task and pass the AP through the annotationProcessorPaths ?

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. For more information on licensing, please check here.

---

[hibernate-github-bot[bot]]

Thanks for your pull request!

This pull request appears to follow the contribution rules.

› This message was automatically generated.

[marko-bekhta]

@yrodiere can you think of anything else we can/should do here? Or should we try merging this and then formatting/sorting in and attempting to do a release after that? 🙈 😃