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@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

Reply via email to