#35 evaluate possibility of dropping gradle
Closed 2 years ago by decathorpe. Opened 2 years ago by decathorpe.

The fedora package is more than one major version behind upstream (4.4.1, released Dec. 2017, vs. 5.5, released 2019).

It's only directly depended on by three (!) packages, two of which are optional fedora build system integrations (that can be turned off by switching bconds in javapackages-tools and xmvn), and the other is shrinkwrap-resolver, which is a leaf package AFAICT. gradle-local is only used for building less than 10 actively maintained packages, which can be ported to be built with maven with some effort, as has been done for some other packages already (junit5, testng, aqute-bnd, etc.).

Dropping gradle would probably allow us to drop some other packages as well, since it has a rather long list of dependencies (over 100 lines of BRs and almost 100 lines of Requires).

gradle-local (javapackages-tools) is buildrequired by:


Right, I forgot to check for these dependencies as well.

Most of them are either not tracked in koschei (yet), or already broken.

I'll add them all to koschei so we can better determine the impact.

Additional data point: gradle is not even installable on i686 and arm right now, because jgit is now only available on 64bit arches:

Problem: conflicting requests
  - nothing provides jgit needed by gradle-4.4.1-3.fc31.noarch
  - nothing provides mvn(org.eclipse.jgit:org.eclipse.jgit) needed by gradle-4.4.1-3.fc31.noarch

After doing some more digging, it looks like no Stewardship SIG packages require gradle for building, except for optional or circular dependencies that can be broken (in xmvn, groovy, javapackages-tools, etc.).

I don't think we have the manpower to keep gradle working (and it's already seriously out of date), especially if we will need to restrict it and all its dependent packages 64bit arches anyway. The number of packages absolutely requiring gradle isn't big, so I don't have any hopes that somebody else will fix it, either.

@mizdebsk what do you think? I see that gradle is not part of modular branches, with support for gradle being disabled in both xmvn and javapackages-tools.

I think we should orphan it ...

If we are to orphan it, we need to make the dependencies from our own packages go away. Can we at least remove it from groovy?

I don't think we can drop it from groovy, but unless I'm missing something, I think we can drop groovy at the same time. Support for it is mostly already optional and under bconds in our packages (in xbean and maven-script-interpreter). There's also a dependency circle involving groovy, gradle, and gpars, which should clear things up as well.

The only problematic dependency chain I found was dogtag-pki -> jackson -> groovy18 -> gpars -> gradle. It looks like jackson only needs groovy18 for the test suite, but I am apparently incapable of deciphering ant's XML build definitions.

Alright, groovy18 can be dropped from jackson quite easily after all, I've prepared a PR here:


PR to drop groovy support in tesla-polyglot:


(Though that one is broken already.)

This is dependency graph of gradle, groovy, and groovy18 (hopefully without too many errors). I've looked at possibilities drop dependencies and noted them in the graph, where it's possible. I've also annotated packages that are currently orphaned, broken, doomed (TM), or leaf packages AFAICT.

Dependency sub-trees for logback and wildfly are broken out for deduplication.

(dependency tree updated for retired packages and moved to ticket body)

The affected non-orphaned, non-broken packages not owned by the SIG are (no guarantee for completeness:

  • arduino
  • cassandra
  • fernflower
  • hystrix
  • infinispan
  • java-runtime-decompiler
  • jetty (optional dep: weld-core)
  • josm
  • legendsbrowser
  • liquibase
  • lucene (optional dep: randomizedtesting, spatial4j)
  • lz4-java
  • mariadb-java-client
  • mongo-java-driver
  • postgresql-jdbc (test dep: classloader-leak-test-framework)
  • multibit-hardware
  • openjfx
  • olfs
  • procyon
  • resteasy
  • springframework
  • wss4j

Removing Gradle should be possible. Packages that use Gradle for building (including groovy package) should be easily portable to be built with Maven instead. We already have some packages built this way - upstream uses Gradle, but Fedora uses Maven. Examples: aqute-bnd, junit5.

Also, we'd need to either port groovy's build to maven, or move users of logback-classic to slf4j-simple or log4j, since logback contains groovy code that's used at runtime.

I've updated the dependency tree by removing retired packages, and moved it to the ticket body text instead of a random comment. Things are moving in the right direction :smile:

Just a heads-up: I will announce my / our intention to drop gradle (for fedora 32) in my flock talk (and with an accompanying announcement mail).

  • 4.4.1 (packaged) was released in Dec 2017, current is 5.5.1 (July 2019)
  • no other distro packages anything newer, as far as I can tell. so we can't reuse their work here
  • only Arch has up-to-date gradle, groovy, and kotlin packages, but they just package the upstream binary releases
  • packages using gradle for building can be ported to use maven instead (look at testng, junit5, aqute-bnd for examples)
  • only 15 fedora packages are built with gradle - of which 5 are orphans, and 3 are maintained by the SIG because they are dependencies of gradle (gpars, gradle, groovy)

@decathorpe ACK, this sounds good from my end.

It's done.


@jjelen you can orphan the package, if you want. I've already removed the SIG.

Metadata Update from @decathorpe:
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.