-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support full Java Module descriptors #555
Comments
Ping 😅 |
Hi @aalmiray, I'm not an expert about this and I'd like to understand the benefits, so I have a question:
are we saying that currently we cannot use the SDK with jlink? |
It depends. Automatic module names do not work with However an hybrid distribution (modular Java Runtime + external automatic modules and/or non modular JARs) may be created. Not that many people know that hybrid JRs may be created nor the steps required to create them. Most people either go full modules or not at all when dealing with |
Feel free to propose a PR |
It would be super, super cool @aalmiray, if you could share with the community a link that explains those steps. Please? TIA. |
Have not found a blog post explaining hybrid JRs. However, there have been a couple of posts detailing how to build a small JR with jlink for applications packaged inside a container; they provide the basics. Here's why. Most people think you must have a fully modular application to reap the benefits of jlink. But not necessarily. You can create a minimal JR containing a subset of modules from the original JDK. The application doesn't have to be modular, hence its JARs are shipped with the JR. This is the basis for the hybrid approach as the only change needed is to find out if any of the application's JARs are modular. Those that are modular could be added to the JR, which removes them from the directory containing the JARs, resulting in a JR with JDK & app modules. JRs built in this way still require applications to be run in classpath mode because they are not modular. The advantage of building hybrid JRs is sharing a common base among similar applications. However, you may think of custom JRs in the same way as we do with container layers. It might be better to build a minimal JR (only JDK modules) as a base layer, all app JARs as a second layer. |
Closes cloudevents#555 Signed-off-by: Andres Almiray <[email protected]>
v2.4.2
defines automatic module names for all Maven modulesI'd be great if the library supplied full Java module descriptors. It's possible to keep bytecode baseline compatible with Java 8 while providing a full module descriptor thanks to ModiTect. This will help modular projects that consume artifacts from this specification, specifically those that create custom Java Runtimes with
jlink
, as the latter does not support automatic modules but explicit modules.I've checked all artifacts provided in
cloudevents-bom-2.4.2
and there are no split packages.The text was updated successfully, but these errors were encountered: