[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-jigsaw-dev
Subject:    Re: Requires runtime considered?
From:       Christian Beikov <christian.beikov () gmail ! com>
Date:       2021-06-28 9:40:05
Message-ID: 0c2d4101-fb80-a82f-3901-e5cf1e09c26a () gmail ! com
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]