Hello, I have discovered an annoying issue with java within the AUR. One of the projects I aim to wrap is written in java, however it contains a lot of other dependencies in java, and I have been thinking about the idea of how to package, and installing a jar with all the dependencies compressed within it defeats the purpose of packaging. I assume I should have each dependency as its own package, which means its more maintainable and each dependency can be bumped manually, but I doubt it is conventional to put .jar's in with shared objects (.so) within the libraries directory. Does anyone have any ideas how you would package a large Java codebase with the dependencies separated to be more maintainable? I am aware Java is such a pain to package, distributions such as gentoo do not even bother sometimes and do not support java packaging that well. Thanks, Polarian
On 15/12/2022 16:12, Polarian wrote:
Hello,
Hi Polarian
I have discovered an annoying issue with java within the AUR.
One of the projects I aim to wrap is written in java, however it contains a lot of other dependencies in java, and I have been thinking about the idea of how to package, and installing a jar with all the dependencies compressed within it defeats the purpose of packaging.
I assume I should have each dependency as its own package, which means its more maintainable and each dependency can be bumped manually, but I doubt it is conventional to put .jar's in with shared objects (.so) within the libraries directory.
Does anyone have any ideas how you would package a large Java codebase with the dependencies separated to be more maintainable?
Usually large scale Java project use a build tool to build and pakcage such as maven or gradle. It falls usually on the build tool to package the program and its dependencies and create a "distribution" tar.gz or zip file which you could use for deployment. You can check how we deal with Java applications in our repositories. For a more details answer and suggestions please reference the project you intend to package. Cheers, Leonidas
Hello, I intend to package OneDev as I could not find any package for it yet on the AUR. It currently uses JSW (Java Service Wrapper) which is a proprietary tool to wrap it, I am currently contacting the developer in providing the plain Jar without wrapping with proprietary deployment tools, this will also shrink the size of the package because who the fuck wants a proprietary JVM wrapped within every java package? My issue is, the codebase contains all the libs such as "logback.jar", which I do not want to include within the package because it is a very common dependency, and I feel it will bloat the package and will cause duplicate data within the system where other java packages will have logback with them. So I was thinking instead of doing this, having separate AUR packages for every dependency, this can already be seen here:; https://aur.archlinux.org/packages/slf4j which is a package for slf4j which is in almost every single java codebase! Looking at the PKGBUILD of this AUR package it installs them under /usr/share/java, but I am not sure if this is conventional or just what the package maintainer has decided to do. I also recommend that the AUR ArchWiki pages be extended to have guides on how to package every non-binary programming language which is common, as there is currently no "conventional" method of doing it, which means each AUR package has a different way of doing it, one aur package I have adopted bundles all the dependencies with it WHICH IS NOT MAINTAINABLE!!! A way I think of packages is asking yourself "does this package service one function, and provide ONLY that function", for example if you are bundling a JDK you would not start sticking in the GCC codebases in there because "JDK might want GCC to build it". Its a poor example but you get the idea, as AUR packagers we need to ensure that the packages are small, and service their purpose with as little to no data duplication as possible! Thanks for the support :)
Le 15/12/2022 à 15:34, Polarian a écrit :
Hello, Hi [...]
I also recommend that the AUR ArchWiki pages be extended to have guides on how to package every non-binary programming language which is common, as there is currently no "conventional" method of doing it, which means each AUR package has a different way of doing it, one aur package I have adopted bundles all the dependencies with it WHICH IS NOT MAINTAINABLE!!!
[...] There's already packaging guidelines for every "common languages". You can find them all in the "Additional guidelines" chapter of the "Arch package guidelines" Wiki page [1]. See the one for Java [2] for instance. Also, the wiki itself is a community effort. If you feel like something's missing or could be improved, don't hesitate to add it to the "discussion/talk" tab or eventually directly in the main page if you're confident about your change(s).
[1] https://wiki.archlinux.org/title/Arch_package_guidelines#Additional_guidelin... [2] https://wiki.archlinux.org/title/Java_package_guidelines -- Regards, Antiz (Robin C.)
Hi, On 15.12.22 15:34, Polarian wrote:
Hello,
I intend to package OneDev as I could not find any package for it yet on the AUR. It currently uses JSW (Java Service Wrapper) which is a proprietary tool to wrap it, I am currently contacting the developer in providing the plain Jar without wrapping with proprietary deployment tools, this will also shrink the size of the package because who the fuck wants a proprietary JVM wrapped within every java package?
Is the source of your PKGBUILD going to be this vendor JAR? Then it probably would follow the same logic as other "binary" AUR Java packages (intellij and android studio come to mind), where everything Java side is vendored into the PKGBUILD, and only the FFI dependencies (~= .so files) pulled in as package dependencies.
On 15/12/2022 16:34, Polarian wrote:
Hello,
I intend to package OneDev as I could not find any package for it yet on the AUR. It currently uses JSW (Java Service Wrapper) which is a proprietary tool to wrap it, I am currently contacting the developer in providing the plain Jar without wrapping with proprietary deployment tools, this will also shrink the size of the package because who the fuck wants a proprietary JVM wrapped within every java package?
My issue is, the codebase contains all the libs such as "logback.jar", which I do not want to include within the package because it is a very common dependency, and I feel it will bloat the package and will cause duplicate data within the system where other java packages will have logback with them.
So I was thinking instead of doing this, having separate AUR packages for every dependency, this can already be seen here:;
I wouldn't bother really. Java usually has too many dependencies to do somethign like that. I'd just follow the instructions they mention for system install here [1] As for the JSW (from tanuki) I'd argue to the devs to switch to an open source alternative like YAJSW [2] and skip paying the fee for JSW but it's usually hard to convience the devs if they already have clients.
https://aur.archlinux.org/packages/slf4j I don't get why you'd install this as a separate package because it's pretty useless in it's own.
[1]: https://docs.onedev.io/installation-guide/run-on-bare-metal [2]: https://yajsw.sourceforge.io/
I believe your problem comes from upstream vendoring the dependencies. If that’s the case, trying to separate libraries into other packages will require continuous effort from you. Could get even worse. If you fail, the users — unaware of external dependencies being your doing — will start bugging upstream and everybody will be unhappy. While I do understand reasons for vendoring, I am myself against the idea. But if upstream decides to do that, going against their decision is pain.
participants (5)
-
Leonidas Spyropoulos
-
mpan
-
Polarian
-
Robin Candau
-
Sven Schwedas