Can't find micronautserviceconfigs when running as jlink-ed application about micronaut-core HOT 9 OPEN

do you know of any modular jars out there that contain static resources that we could use in this test? Currently Micronaut doesn't support the module system, but maybe with the change you propose it could be possible I guess.

I'll prepare one just for testing. Notice in the exception that io.micronaut.context.event.ApplicationEventPublisher cannot be found when micronaut-inject-x.y.z.jar is on the modulepath instead of on the classpath. It is not a third-party jar issue, just the specs of modulepath that's causing an issue.

from micronaut-core.

@rfscholte I did some experiments in this area a few months ago, they may be useful to you. I would be happy to help on this as we have been wanting to use jlink and Micronaut together too.

Edit: Ah, I see you are a Java champion and work on Maven. You probably don't need my help. But I would still be happy to test or assist any way I can 😄

from micronaut-core.

do you know of any modular jars out there that contain static resources that we could use in this test? Currently Micronaut doesn't support the module system, but maybe with the change you propose it could be possible I guess.

from micronaut-core.

A bit of background: One of the requirements of the application I'm building is that is has to be built with jlink.
It should also use a DI-container, but currently there's no modularized implementation available, so I patch them a bit. Guice +Sisu seems okay, but has quite some third party dependencies that are not modularized yet. Micronaut looks like a better option if a few issues are solved (including this one).

One of the things I'm wondering: why did you choose for a services-directory with empty files where the name is the implementation?
sisu guice works, because is has the file META-INF/sisu/javax.inject.Named containing all the named classes. (and you probably also notice another issue here: as I'm writing a new application, I'd like to start with the jakarta namespaced classes).
Can we work on a similiar approach here?

from micronaut-core.

we used to have META-INF/services definition that contained a single file with all of the classes, but the issue with this approach is it needs a full recompile of all classes that participated in its creation each time any of them change which is not great for incremental compilation performance.

We had a project that has over a million lines of code and was taking a significant amount of time to compile, we switched the implementation to a directory with a list of files that represent the class names and with this solution you have a 1-to-1 relationship between annotated class and generated file so we could effectively compile incrementally and significantly improve compiler performance.

from micronaut-core.

for reference #7195

from micronaut-core.

This only seems to be an issue when using jlink.

logger.error("{}", Application.class.getClassLoader().getResource("META-INF/micronaut/io.micronaut.inject.BeanDefinitionReference") != null );
logger.error("{}", Application.class.getClassLoader().getResource("META-INF/micronaut/io.micronaut.inject.BeanDefinitionReference/io.micronaut.context.event.ApplicationEventPublisherFactory") != null );

[main] ERROR micronaut.Application - false
[main] ERROR micronaut.Application - true

The steps to reproduce it using modulelayers are incorrect, which makes it even harder to verify this.

I guess the approach with the least impact here is to whitelist paths like META-INF/micronaut/io.micronaut.inject.BeanDefinitionReference; don't verify if it exists. WDYT?

from micronaut-core.

This only seems to be an issue when using jlink.

logger.error("{}", Application.class.getClassLoader().getResource("META-INF/micronaut/io.micronaut.inject.BeanDefinitionReference") != null );
logger.error("{}", Application.class.getClassLoader().getResource("META-INF/micronaut/io.micronaut.inject.BeanDefinitionReference/io.micronaut.context.event.ApplicationEventPublisherFactory") != null );

[main] ERROR micronaut.Application - false
[main] ERROR micronaut.Application - true

The steps to reproduce it using modulelayers are incorrect, which makes it even harder to verify this.

I guess the approach with the least impact here is to whitelist paths like META-INF/micronaut/io.micronaut.inject.BeanDefinitionReference; don't verify if it exists. WDYT?

Seems reasonable to me

from micronaut-core.

Just received confirmation from Alan Bateman that this is indeed the expected behavior: https://mail.openjdk.org/pipermail/jigsaw-dev/2024-June/015042.html

from micronaut-core.