Re: Requires runtime considered?
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
Re: Requires runtime considered?
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
Requires runtime considered?
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? Regards, Christian
