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 #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]

Thanks for your pull request!

This pull request appears to follow the contribution rules.

› This message was automatically generated.

[yrodiere]

Hey, thanks. My comments below.

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?

Maybe, though I'd love to know what those things are and how the CDI container manages to guess the names of the relevant classes. Are those hardcoded somewhere, or... ?

[yrodiere]

.spi.internal, really? 🤔

Are you trying to confuse automatic tooling? :)

[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? 🙈 😃

[yrodiere]

Thanks. Added a few comments, but feel free to merge when you think it's ready.

[yrodiere]

This seems... fragile?

If we add some abstract class above ValidatorImpl, it will probably no longer work.

And with ValidatorProviderHelper.forDefaultProvider, it will definitely not work -- though I admit I have no idea what's the purpose of that thing.

Shouldn't you adjust how ValidationProviderHelper is built instead? E.g. forHibernateValidator would pass HibernateValidatorFactory.class/HibernateValidator.class to the constructor, while forDefaultProvider would do that if ValidatorFactory implements HibernateValidatorFactory, and default to some other behavior if not (maybe ValidatorFactory.class/Validator.class?).

[marko-bekhta]

hmm, if we pass just the interface, then we might lose some interfaces:

ValidatorImpl implements Validator, ExecutableValidator

On the other hand, the ValidatorFactoryImpl extends AutoCloseable, and since we are taking the class hierarchy, we add AutoCloseable to the types, so that means we allow something like ...

@Inject
@HibernateValidator
AutoClosable validatorFactory;

is possible? 🤔 😃

Maybe... if it is an HV factory/validator, we filter out any internal classes/interfaces by looking at the package, and otherwise, we keep everything. There's this test that checks if someone can inject their own custom factory/validator, and in that case, the implementation classes are injected, that's why I think if it is not "ours", we just keep it all and leave it to the user to deal with.

hibernate-validator/cdi/src/test/java/org/hibernate/validator/test/cdi/internal/injection/InjectionOfCustomProviderTest.java

Lines 51 to 73 in e5a569e

	@Inject
	ValidatorFactory defaultValidatorFactory;
	@Inject
	Validator defaultValidator;
	@Inject
	MyValidatorFactory myValidatorFactory;
	@Inject
	MyValidator myValidator;
	@Inject
	@HibernateValidator
	ValidatorFactory hibernateValidatorFactory;
	@Inject
	@HibernateValidator
	Validator hibernateValidator;
	@Inject
	@HibernateValidator
	HibernateValidatorFactory hibernateValidatorSpecificFactory;

[yrodiere]

if it is an HV factory/validator, we filter out any internal classes/interfaces by looking at the package

Okay, but perhaps hardcode that list (with a test to check it stays up to date).

otherwise, we keep everything. There's this test that checks if someone can inject their own custom factory/validator, and in that case, the implementation classes are injected, that's why I think if it is not "ours", we just keep it all and leave it to the user to deal with.

Makes sense.

[yrodiere]

Being literal here, eh? 😁