On Tue, Sep 28, 2021 at 04:33:39PM +0200, Fabio Valentini wrote: > But as you guessed, there's no such support for gradle, sbt, bazel, or > whatever new build system Google has been cooking up recently. Nor is > there support for Groovy (no longer available in Fedora, as it > depended on gradle), Kotlin (was never packaged), or Scala (no longer > available) - all of which are now dependencies of gradle. Oh, fun. > While gradle *used* to be available as an option for Fedora Java > packages, recent versions of gradle are a barely-open-source mess that > apparently only upstream itself manages to build from source, and > everybody else is supposed to "just build with internet access and use > our binary JAR, it's fine (TM)". > > Another problem is projects that use ant or maven, but do horrendous, > nonstandard things *within* those build systems, either with custom > ant targets, or weird maven plugins. I think this difference in philosophical approach is the crux of the problem. Elsewhere in the thread people mentioned many smaller and larger *technical* issues, and we probably would have overcome those with enough motivation. But packaging of Java is so horrible because upstreams are completely uninterested in people consuming their software by compiling it from sources and reusing within other projects. Hence: crazy build systems that only work on some developer's mac on alternate weekdays, self-dependent build systems, downloading of random stuff from the network, constant api breaks and renames of things, and I'd say generally low quality of output. > using maven is actually not terrible for making RPM packages, Yeah, we have maven under control. I remember how maven started being popular, and was a huge improvement over the older java build systems. But looking back, it was never so great: for example, it was always intended only a always-online build system; the local builds we do with Xmvn are one giant hack. Version dependencies are pinned exactly, there was never any idea of version ranges or semantic versioning. And doing anything slightly non-standard with Maven was always extremely painful; things that would be one or two lines in Make or other build systems could turn into an extremely fragile 150 lines of XML. And even though Maven could be the best this ecosystem produced, it already started moving in the directions that ultimately made the later systems unusable. Ultimately, I think the Java packages in Fedora are dying because their ecosystem has philosophies which go in a different direction than our subset of the software world: building a pipeline directly from version-controlled code to any build artifacts, reproducible builds, limited trust, testing and scanning at all levels, automatization, simplification of build systems and packaging. Zbyszek _______________________________________________ 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
