Re: Package uses Gradle (retired) to build: what to do?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Feb 9, 2020 at 2:09 PM Fabio Valentini <decathorpe@xxxxxxxxx> wrote:
>
> On Sun, Feb 9, 2020 at 2:49 PM Ankur Sinha <sanjay.ankur@xxxxxxxxx> wrote:
> >
> > On Sun, Feb 09, 2020 10:30:41 +0100, Nicolas Mailhot via devel wrote:
> > > Le samedi 08 février 2020 à 19:16 -0500, Neal Gompa a écrit :
> > > >
> > > > What does it tell? To me, it says that FOSS platforms don't care
> > > > about
> > > > Java as much as they used to. We're clearly able to do stuff with Go
> > > > and Rust, which are just as "anti-distribution" as Java is (based on
> > > > what other people say).
> > >
> > > While the Go core team definitely cares little about distributions, the
> > > Go module system is enforcing similar sanity rules than us (no locked
> > > versions, semver, etc) which makes it quite a lot friendlier than Java.
> > >
> > > Any language that passed the stone age of 'it builds locally with a
> > > stash of fixed third party code of dubious origin and freshness' will
> > > be easier to distribute than Java.
>
> (snip)
>
> > Thanks for all your comments everyone. What I deduce from here is that
> > packaging and maintaining Gradle is quite a task, and it may not be
> > doable (or worth doing) with our limited resources.
>
> Yeah, I don't think gradle can be maintained as a limited-resource
> community effort ... Mikolaj is the original maintainer, and he wrote
> some documentation for how to bootstrap gradle. However, he since
> dropped all but one of his fedora packages, and the bootstrapping
> process is now outdated and does not work anymore (we tried).
>
> See: https://src.fedoraproject.org/rpms/gradle/tree/f30
>
> Additionally, gradle requires groovy to build, and groovy requires
> gradle to build, and gradle requires gradle to build. And both gradle
> and groovy are retired on f31+. So it's going to require some
> multi-step bootstrap to get anything off the ground again :(
>
> To make things even more interesting, new versions of gradle now also
> include scala and kotlin code :D
>

Do we even have recent versions of scala in Fedora? And as far as I
know, Kotlin is still not in Fedora either...

> > So, to bring the thread back to the original question: what do we do?
> >
> > - Does anyone have experience with converting Gradle based projects to
> >   Maven? Can we use something like this in %prep, for example, or
> >   locally generate the pom files and ship them in src.rpm?
> >   https://stackoverflow.com/questions/12888490/gradle-build-gradle-to-maven-pom-xml
> >   https://docs.gradle.org/current/userguide/maven_plugin.html
> >
> > - If it is possible to convert from Maven poms to Gradle build files,
> >   can we do the opposite perhaps?
>
> Yes, that's possible, and in fact, that's what a few packages already
> do. For example, aqute-bnd and testng are built this way (with
> generated or hand-ported pom.xml files included as %{SOURCEX} files,
> and then used as maven input). However, this is also more or less
> preventing us from updating these packages since we didn't do this
> port and have no idea how to adapt these files for new versions.
>
> > What are our other options? (Of course, I assume bundling the Gradle
> > binary for Fedora is out.)
>
> - Option 1: Convert package build systems from gradle to maven.
> Pro: Works with current packaging tools.
> Con: might make package updates harder.
>

As I think we can see here, this option doesn't really scale well and
causes more problems than it solves.

> - Option 2: Bring back gradle, possibly in a multi-step bootstrapping
> process (like Neal outlined), with a "full-bundled" build is done
> first to get things off the ground, and after that, components can be
> de-bundled one after another.
> Pro: no changes necessary for packages built with gradle.
> Con: Lots of work packaging gradle and its ecosystem.
>

At least initially, it shouldn't be bad, and unbundling can be done
iteratively with relatively little pain. This has the benefit of
unlocking most of the JVM ecosystem for Fedora again, as Gradle has
become the most popular option for building stuff on the JVM.

> - Option 3: Retire packages requiring gradle, and ship them as flatpaks >:-D
>

I hope you're not being serious. The Java ecosystem is a lot more than
just the Eclipse IDE. There's a lot of server side software, developer
tools, web code, and desktop apps that use Java ecosystem software in
some way.

The problem is that we need to start getting people who are interested
in the JVM/Java ecosystem to come together and help reboot the Java
SIG, ideally as a cross-distro SIG like the Rust SIG is. How we get
there? I don't know.



-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux