Re-Launching the Java SIG

This past weekend I finally decided to jump off the cliff and attempt
to re-launch the Java SIG. It seems there’s some interest in keeping
the Java stack maintained, it’s just not focused or organized right
now.

What we did when starting the Stewardship SIG seems to have worked out
pretty well, so I’m trying to follow in those footsteps here:

  • new proper FAS / pkgdb group: java-maint-sig (“java-sig” is occupied
    by an old, unused bot account)
  • new private mailing list: java-maint-sig (for RHBZ bugs - so,
    possibly, also CVEs - hence, private)
  • tracking project on pagure: https://pagure.io/java-maint-sig (for
    maintenance scripts, tracking tickets, awesome package dashboards,
    etc.)

There’s already a public fedora mailing list for Java (java-devel),
and and IRC channel (#fedora-java on freenode.net), which we will
continue to use. Sadly, the existing wiki page for the Java SIG is
hopelessly outdated, so I’m tempted to just scrap it and point readers
to the pagure tracking project once it’s set up beyond a basic README
file.

Major upcoming projects for the “new” Java Package Maintainers group include:

  • managing OpenJDK 11 / Java 11 transition for hundreds of Java
    packages in fedora 33
  • starting to transition well-maintained Java packages from the
    Stewardship SIG back into Java SIG
  • possibly porting packages from gradle to maven to fix build issues
    and broken dependencies
  • transitioning from old java.net / JavaEE projects to the new ones
    now under the eclipse-ee4j umbrella

I know that - among others - the PKI team, Neuro SIG, and Eclipse
maintainers depend on parts of the java stack for their packages, so I
hope that we can work together with them on these things, as well.

So, if you’re interested, please consider joining this group effort.
I’ll get new members set up with the FAS group / pagure project / mailing list.

Let’s make this happen.

2 Likes

I’m curious how/why this is mentioned. What is wrong with Gradle?

gradle is no longer available as an RPM package since fedora 31.

The version that is available up to fedora 30 is 4.4.1, which was released in December 2017, which was already out of date when fedora 30 was released.

Gradle was then removed from fedora 31 and later because:

  • it failed to build, and it also failed to build itself, even in “bootstrap” mode
  • updating to newer versions was/is basically impossible

Some people (myself included) tried to fix gradle, update it to a newer version, and add it back to fedora, but with the way the build system works, I see no way for this ever to become possible again:

  • even their source code downloads contain and need a prebuilt JAR to launch the build process,
  • the build process needs internet access to download all their dependencies (with fixed versions)

We have not even found a way to make the official gradle release binaries build gradle itself without internet access, let alone have a working self-built gradle.

When trying to communicate our frustrations with the gradle build process to the gradle project, we were basically ridiculed, and told that “we’re just not doing it right”, and that they need their bespoke build process (which, as I mentioned, can’t be made to run “ab initio”, and downloads loads of stuff from the internet, even when you download their “complete release”) for “reproducibility”. They even got angry with me when I mentioned that it might be argued that gradle is not an open source project then, if nobody but themselves can even build it :slight_smile:

Which is the point at which we gave up.

This is why we now recommend packagers to use maven when possible, or to do simple ports from gradle to maven for necessary projects, where this is feasible. Some packages have been doing this for a while (including junit5).

4 Likes

Wow! That is incredibly bad. Thank you for explaining it. I had no idea it was like that.