On 9/26/21 3:20 PM, Fabio Valentini wrote:
Good evening everybody, Not sure why it's me who's writing this message, but somebody needs to do it. Community maintenance of Java packages in Fedora is, for all intents and purposes, dead. Mikolaj keeps a bare minimum of packages working for the maven toolchain, but that's it. Fedora 35 will ship without packages for the Eclipse IDE, and none of the Java applications I know of are still in working order. While I had hoped that setting up a "new" SIG and gathering members to shore up community maintenance of the "extended core" Java stack, this effort fizzled out after mere weeks. "He's dead, Jim."
I will add my view as someone that use to package a tiny few Java packages for Fedora (maily Eclipse plugins). My view may be outdated so everyone is free to correct me as always.
I think saying the Java ecosystem isn't friendly to traditional packaging could be said for any other modern language Fedora has accepted without a fuss. Go and Rust applications has made some of the traditional rules of dynamic loaded code having a preference being challenged by these "newcomers" that don't support it.
Meanwhile Java packages still are difficult because of the need of everything to be split on multiple packages and every jar found being replaced by symlinks to files in /usr/java/*. In Eclipse plugins this remain more difficult, because plugins al already jars with embeeded jars where a custom classloader is able to load things withour having everything extracted on the filesystem.
I think the only way the Java ecosystem to survive in Fedora outside of OpenJDK and some core components is to allow bundling (Even JavaScript bundling is already allowed), but how do to it without compromising security?
1. I propose that every package should use a modern Java build system that resolve dependencies (Maven, Gradle, Ant+Ivy, etc), If the package doesn't have that, a patch should be provided and contributed upstream.
2. We have automation to extract the dependencies required by the main package and allow the Fedora build system to automate the creation of packages for these dependencies from source and generate for example subpackages *-mave or something like that, that provides these dependencies as maven repositories locally to be use by other packages.
3. Packages embeede thes libraries like they upstream do, without having to patch hundred of build script to use links to /usr/java.
4. Automate that dependencies updates should trigger dependent packages rebuild
This as dependent Jar files as "source code" like Rust and Go are currently packages.
Without a process simplification for the packages like this one, or something better. The Java applications ecosystem being packaged on Fedora will not be resurrected.
Now to the reason why I feel the need to beat a dead horse: I wonder if the @java-maint-sig group should actually continue to exist (or rather, be maintainer or bugzilla assignee for packages, because I don't even know if FAS groups can be deleted). It seems that none of the current members (I am no longer one of them) are active. Bugs, including security issues with assigned CVE numbers, are collecting dust. Packages get orphaned and retired one by one because they fail to build or install. At this point, I'm still the only person with the password for the SIG's bugzilla account and the only administrator of the private mailing list - just because I wouldn't even know who to hand those things over to (fedora-infra?). There's nobody left, nobody is reading the mailing lists. Only tumbleweeds are here. Should the @java-maint-sig group be removed from any packages it is still associated with? Should it be dissolved, and members be removed? Should the remaining ruins that used to be packages be orphaned? Retired? Buried? Forgotten? I don't know. Fabio
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
