Handling cross-platform native dependencies #43848
Replies: 2 comments 3 replies
-
|
Do you mean if that property was configured those dependencies would be resolved and added to the build classpath before augmentation starts? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that's the idea. Of course, it's more than welcome if you have a better approach. I'm not a big fan of such a magic trick. |
Beta Was this translation helpful? Give feedback.
-
|
If I am not mistaken the so far reports have been for use cases where "I build on X platform and run on Y platform" and not for use cases where "I build on X platform and want to run on X, Y, Z". Is that right? If so, the issue we should aim to fix would be cross-compilation and not multiplatform-support. In such a scenario No matter what we end up doing it seems like we need to improve error/warning reporting to make clear that if an application depends on native libraries it won't work on any platform and should be compiled accordingly. |
Beta Was this translation helpful? Give feedback.
-
|
I agree; the problem is that most users do not understand the need for native libraries. I don't believe many Quarkus users are aware of the Brotli dependency. We could imagine instrumentation Netty or Kafka Streams to catch the loading error and indicate the issue, but it's rather intrusive. |
Beta Was this translation helpful? Give feedback.
-
|
For reference, here is the Zulip thread about it https://quarkusio.zulipchat.com/#narrow/stream/187038-dev/topic/conditional.20dependencies.20for.20OS.20and.20arch/near/451438961 |
Beta Was this translation helpful? Give feedback.
-
Hello,
Recently, we received multiple reports about our handling of native dependencies. Native dependencies are Jars containing native libraries, which are dependent on the OS/arch. For example, a native library for MacOS/ARM64 cannot be loaded on Linux/AMD64.
In native mode, there is no "cross-platform" support. But in JVM, it's slightly more problematic because the application built on OS/Arch cannot run on other OS/Arch. For example, a report explains that the OpenShift s2i binary build fails because it uploads a Jar build on the host (Mac) and runs on a Linux/AMD64 container. The native library selection during the build does not work in this case.
A naive and straightforward solution would be to include all the possible OS/Arch, but it would increase the application disk footprint.
Another approach would add a new config property (
quarkus.additional-platforms: comma separated list of OS/Arch to be included in the JVM build), and let extensions requiring native dependencies (Vert.x HTTP (brotli), Kafka Streams (rocksDB)....) to use this property to resolve additional dependencies and include them to the application (in addition to the one for the host).I don't know if this is possible, but it would provide flexibility. It would require adding new dependencies during the build time (in a build step).
Other approaches, like OS-based profiles, are not working in Gradle and would require building with multiple profiles enabled.
\CC @aloubyansky @zakkak
Beta Was this translation helpful? Give feedback.
All reactions