graemerocher
commented
1 year ago probably works if you exclude shading and/or use docker image packaging
Open chumer opened 1 year ago
graemerocher
commented
1 year ago probably works if you exclude shading and/or use docker image packaging
chumer
commented
1 year ago @graemerocher can you please point me to docs I can link from our docs?
graemerocher
commented
1 year ago @chumer think you need to configure
@alvarosanchez think we need an example in the docs
chumer
commented
1 year ago Yes.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.5.1</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>skips shading. But when users are used to shading as their default deployment model, how will they deploy then? I fear a Micronaut user might get lost here. I guess we should offer an alternative way to build deployable artefacts, right? Or are users already expected to know what to do?
alvarosanchez
commented
1 year ago The only long-term solution is to get rid of shading, it's very problematic. It's been discussed for years, but we never get to the point to put some effort on it. Perhaps it's about time.
One thing that you should be aware thought is that the Maven Shade Plugin will keep a copy of the original JAR as original-xxx. Can you not use that?
Expected Behavior
With GraalVM 23.1 (GraalVM for JDK 21) GraalVM Truffle/Polyglot languages are now consumed from the class/module-path. For context, this project is also known as Truffle Unchained, and we wrote up all about it here: https://medium.com/graalvm/truffle-unchained-13887b77b62c
For that to work, we require the optimizing Truffle runtime to run as a named module. The reason is that we would otherwise need to export the internal JVMCI API to ALL-UNNAMED. The JVMCI is unsafe on steroids and must not be exported to ALL-UNNAMED to preserve the VM integrity.
There is no problem with regular Java SE applications that leverage the module-path or use a module class loader as the truffle runtime runs as named module. As far as I understand Micronaut cannot run modules as named modules atm, therefore this solution cannot be applied. But please correct me if I am wrong.
When running languages from the classpath the Polyglot runtime automatically scans the classpath and looks for modular jar files that it can spawn on a separate module-layer + classloader. This approach typically works for regular Java SE applications, but it fails when Micronaut shades everything into a single jar file.
As a workaround, if you run with
mvn mn:runand it works because it uses the regular class-path.Another workaround I had to deploy to make micronaut work with GraalVM for JDK 21 was I had to add these two dependencies:
The reason for this workaround is that the micronaut plugin depends on the two dependencies with version 23.0.0 which causes issues.
I've discussed this briefly with @sdelamo at the GraalVM Meetup and he asked me to open an issue to start the discussion. I do not think shading all the language jars into a single jar can work because this makes it impossible to run jars as named modules. Are there already plans to revisit this? Do you have alternative ways to deploy that we could document?
Other frameworks like Spring and Quarkus use custom class loaders, but they keep the jar files intact, so there in theory we enumerate jar files for the module-layer with an integration API. I do not see how this can work with shading.
Quarkus issue: https://github.com/quarkusio/quarkus/issues/36242
I've discussed this briefly with @sdelamo at the GraalVM Meetup and he asked me to open an issue to start the discussion.
Actual Behaviour
Steps To Reproduce
mvn packagein the embedding-micronaut folder$JAVA_HOME/bin/java -jar ./target/micronautguide-0.1.jarEnvironment Information
GraalVM for JDK 21 Polyglot version 23.1.0
Example Application
No response
Version
4.0.3