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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure