Open aksh1618 opened 2 years ago
Thank you for raising this issue. Couple of weeks ago I had a look at the guidelines for Java apps and I must confess I've got some concerns about them, particularly the need to break down the default app layout (executable/launcher scripts inside bin
, jars inside lib
) into the preferred AUR layout to reduce duplication.
This being said, if it can be done via templates and configuration then we can have a look.
There's one last piece of information that I did not read before:
As is standard with Arch Linux packages, if the above standards cannot be adhered to without a serious amount of work, the package should be installed in its preferred manner, with the resulting directory located in /opt. This is useful for programs that bundle JREs or include customized versions of dependencies, or do other strange or painful tasks.
This means it's possible to package custom Java Runtimes created with jlink as long as the application is installed at /opt
. This was one of the concerns I had for supporting AUR. Now that I know it's possible to use this mode I think that AUR integration would give you the choice to use the standard layout (as explained by the first set of rules) or use the "exception" option. This is useful for distributions of type JLINK but also for other distros where relocating files turns out to be a problem, such as missing elements in the classpath (think external resource directories such as conf
or similar).
Hi! I'm using arch linux, and one of the main things I love about it is the AUR, which is
So I'd love to have AUR added as a packager so projects using jreleaser already and in future can easily publish AUR packages also. I'm not sure if this aligns with the project direction, as Snap is already supported, and AppImage & Flatpak seem to be in the pipeline, but I believe there is some merit in providing support for AUR at some point, as it offers an almost native installation experience for any arch user.
Some relevant resources: