Thanks for the quick answer and the hint about service, but as you can
imagine, services don't really help here since I am trying to use CDI
which does it's own discovery.
I understand the point about "99,999 other modules", that's why I asked
specifically if such a module is even "visible" somehow such that a CDI
container could do something about this. As far as I know, the Maven
surefire plugin adds only the module of the artifact for which to
execute tests to the module path via --add-modules. Maybe I should
request that runtime dependencies should be added with the --add-modules
flag as well. This sounds like a promising solution though, thanks for
the tip!
Regards,
Christian
Am 28.06.2021 um 11:21 schrieb Alan Bateman:
On 28/06/2021 09:49, Christian Beikov wrote:
Hello experts,
I am in the process of modularizing one of my projects and hit some
rather annoying limitations that requires me to change parts of my
build and dependencies due to the way the Java module system works.
I usually have modules like x-api, x-impl and x-testsuite where I
have a compile time dependency from x-impl to x-api. In x-testsuite I
only code against x-api, so I define a Maven runtime dependency on
x-impl in order for my CDI container to pick up the implementations.
The annoying part is that with modularization I now need to declare
my dependency in x-testsuite on x-impl as compile time dependency,
because otherwise I can't list the module in the module-info. If I
don't list the module, then it is not "visible" to the CDI container,
which I guess is on purpose, even though it probably ends up in the
module path.
Is that by design that classes are not visible if no module depends
on a module like x-impl in such a scenario, or is that maybe
something that could work and should be improved in the CDI
implementation? I was thinking that if "requires runtime ..." were
allowed without checking that the module is available during
compilation, this would work fine. Did this idea come up before already?
The module system supports services. x-api uses a service, x-impl
provides an implementation of the service. If x-api is resolved then
all observable modules that provide an implementation of the services
used by x-api will be resolved too. In this scenario, x-impl requires
x-api, x-api does not require x-impl. You used the phrase "compile
time dependency" but it's more than that, it's all phases as there
will be references in x-impl to x-api's exported API.
I don't know if you control the CDI implementation or not but if you
aren't using services then you'll need to help the module system with
"--add-modules x-impl". This is because no other module requires
x-impl and it's not providing an implementation of a service. It may
be observable but it's the same directory as 99,999 other modules that
you don't care about.
-Alan