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

[Ankur Sinha]

Hello,

netcdf-java[1] uses the Gradle build system, and is required to update
hdfview[2] to the latest version. Gradle, however, was retired[3] as
"out of date, broken, fails to build, basically unmaintainable".

Now, I know that following our system, one must package Gradle first but
given the retirement comment, packaging and then maintaining it does not
appear a simple task, and for one dependency only, it seems overkill.

Is there perhaps a way of bypassing that somehow? For example, is there
a way to use good old Maven to build a Gradle based project?

[1] https://docs.unidata.ucar.edu/netcdf-java/5.2/userguide/building_from_sou...
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1797361
[3] https://src.fedoraproject.org/rpms/gradle/blob/master/f/dead.package

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London

[Neal Gompa]

On Sat, Feb 8, 2020 at 6:23 AM Ankur Sinha <sanjay.ankur(a)gmail.com&gt; wrote:
>  Hello,
>
>  netcdf-java[1] uses the Gradle build system, and is required to update
>  hdfview[2] to the latest version. Gradle, however, was retired[3] as
>  "out of date, broken, fails to build, basically unmaintainable".
>
>  Now, I know that following our system, one must package Gradle first but
>  given the retirement comment, packaging and then maintaining it does not
>  appear a simple task, and for one dependency only, it seems overkill.
>
>  Is there perhaps a way of bypassing that somehow? For example, is there
>  a way to use good old Maven to build a Gradle based project?
>
>  [1] https://docs.unidata.ucar.edu/netcdf-java/5.2/userguide/building_from_sou...
>  [2] https://bugzilla.redhat.com/show_bug.cgi?id=1797361
>  [3] https://src.fedoraproject.org/rpms/gradle/blob/master/f/dead.package
>  
Gradle is a blocker for a lot of projects, unfortunately. Not
supporting what appears to be one of the preferred build tools in the
Java ecosystem has made things quite painful...



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Nico Kadel-Garcia]

On Sat, Feb 8, 2020 at 10:44 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Sat, Feb 8, 2020 at 6:23 AM Ankur Sinha <sanjay.ankur(a)gmail.com&gt; wrote:
>  >
>  > Hello,
>  >
>  > netcdf-java[1] uses the Gradle build system, and is required to update
>  > hdfview[2] to the latest version. Gradle, however, was retired[3] as
>  > "out of date, broken, fails to build, basically unmaintainable".
>  >
>  > Now, I know that following our system, one must package Gradle first but
>  > given the retirement comment, packaging and then maintaining it does not
>  > appear a simple task, and for one dependency only, it seems overkill.
>  >
>  > Is there perhaps a way of bypassing that somehow? For example, is there
>  > a way to use good old Maven to build a Gradle based project?
>  >
>  > [1]
> https://docs.unidata.ucar.edu/netcdf-java/5.2/userguide/building_from_sou...
>  > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1797361
>  > [3] https://src.fedoraproject.org/rpms/gradle/blob/master/f/dead.package
>  >
>
>  Gradle is a blocker for a lot of projects, unfortunately. Not
>  supporting what appears to be one of the preferred build tools in the
>  Java ecosystem has made things quite painful... 
How difficult is it to migrate a gradle build to a maven build?

[Neal Gompa]

On Sat, Feb 8, 2020 at 11:40 AM Nico Kadel-Garcia <nkadel(a)gmail.com&gt; wrote:
>  On Sat, Feb 8, 2020 at 10:44 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >
>  > On Sat, Feb 8, 2020 at 6:23 AM Ankur Sinha <sanjay.ankur(a)gmail.com&gt; wrote:
>  > >
>  > > Hello,
>  > >
>  > > netcdf-java[1] uses the Gradle build system, and is required to update
>  > > hdfview[2] to the latest version. Gradle, however, was retired[3] as
>  > > "out of date, broken, fails to build, basically unmaintainable".
>  > >
>  > > Now, I know that following our system, one must package Gradle first but
>  > > given the retirement comment, packaging and then maintaining it does not
>  > > appear a simple task, and for one dependency only, it seems overkill.
>  > >
>  > > Is there perhaps a way of bypassing that somehow? For example, is there
>  > > a way to use good old Maven to build a Gradle based project?
>  > >
>  > > [1]
> https://docs.unidata.ucar.edu/netcdf-java/5.2/userguide/building_from_sou...
>  > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1797361
>  > > [3] https://src.fedoraproject.org/rpms/gradle/blob/master/f/dead.package
>  > >
>  >
>  > Gradle is a blocker for a lot of projects, unfortunately. Not
>  > supporting what appears to be one of the preferred build tools in the
>  > Java ecosystem has made things quite painful...
>
>  How difficult is it to migrate a gradle build to a maven build? 
Very. Gradle is script oriented. Everything is written in Groovy.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Sérgio Basto]

On Sat, 2020-02-08 at 11:41 -0500, Neal Gompa wrote:
>  On Sat, Feb 8, 2020 at 11:40 AM Nico Kadel-Garcia
> <nkadel(a)gmail.com&gt;
>  wrote:
>  > On Sat, Feb 8, 2020 at 10:44 AM Neal Gompa <ngompa13(a)gmail.com&gt;
>  > wrote:
>  > > On Sat, Feb 8, 2020 at 6:23 AM Ankur Sinha <
>  > > sanjay.ankur(a)gmail.com&gt; wrote:
>  > > > Hello,
>  > > > 
>  > > > netcdf-java[1] uses the Gradle build system, and is required to
>  > > > update
>  > > > hdfview[2] to the latest version. Gradle, however, was
>  > > > retired[3] as
>  > > > "out of date, broken, fails to build, basically
>  > > > unmaintainable".
>  > > > 
>  > > > Now, I know that following our system, one must package Gradle
>  > > > first but
>  > > > given the retirement comment, packaging and then maintaining it
>  > > > does not
>  > > > appear a simple task, and for one dependency only, it seems
>  > > > overkill.
>  > > > 
>  > > > Is there perhaps a way of bypassing that somehow? For example,
>  > > > is there
>  > > > a way to use good old Maven to build a Gradle based project?
>  > > > 
>  > > > [1] 
>  > > >
> https://docs.unidata.ucar.edu/netcdf-java/5.2/userguide/building_from_sou...
>  > > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1797361
>  > > > [3] 
>  > > > https://src.fedoraproject.org/rpms/gradle/blob/master/f/dead.package
>  > > > 
>  > > 
>  > > Gradle is a blocker for a lot of projects, unfortunately. Not
>  > > supporting what appears to be one of the preferred build tools in
>  > > the
>  > > Java ecosystem has made things quite painful...
>  > 
>  > How difficult is it to migrate a gradle build to a maven build?
>  
>  Very. Gradle is script oriented. Everything is written in Groovy. 
and why gradle was retired ? is easy unretire it ? 


>  -- 
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail] 
-- 
Sérgio M. B.

[Gary Buhrmaster]

On Sat, Feb 8, 2020 at 5:08 PM Sérgio Basto <sergio(a)serjux.com&gt; wrote:

>  and why gradle was retired ? is easy unretire it ? 
Announced here (with reasons):
 
https://lists.fedoraproject.org/archives/list/[e-mail]...

[Jun Aruga]

>  and why gradle was retired ? is easy unretire it ? 
I am running gradle command right now as a coincidence .

The upstream project is active.
https://github.com/gradle/gradle

We also might refer other distribution's spec files if we unretire.
https://software.opensuse.org/package/gradle
https://tracker.debian.org/pkg/gradle

-- 
Jun | He - His - Him

[Gerald Henriksen]

On Sat, 8 Feb 2020 18:50:25 +0100, you wrote:

> > and why gradle was retired ? is easy unretire it ?
>
> I am running gradle command right now as a coincidence .
>
> The upstream project is active.
> https://github.com/gradle/gradle
>
> We also might refer other distribution's spec files if we unretire.
> https://software.opensuse.org/package/gradle
> https://tracker.debian.org/pkg/gradle 
They are unlikely to be of much help given how out of date they are.
Gradle is currently at 6.1.1 and Debian seems to be packaging 4.4.1
and OpenSuse is at 3.2.1.  Ubuntu seems to be 4.7

The other message that posted the link to the email regarding the
removeal of Gradle indicated a lot more dependencies were added since
those versions were packaged.

It is telling when essentially none of the open source operating
systems have a current gradle version (FreeBSD does, but they just
grab and wrap the binary from the Gradle website) that gets built from
source.

[Sérgio Basto]

On Sat, 2020-02-08 at 19:03 -0500, Gerald Henriksen wrote:
>  On Sat, 8 Feb 2020 18:50:25 +0100, you wrote:
>  
>  > > and why gradle was retired ? is easy unretire it ?
>  > 
>  > I am running gradle command right now as a coincidence .
>  > 
>  > The upstream project is active.
>  > https://github.com/gradle/gradle
>  > 
>  > We also might refer other distribution's spec files if we unretire.
>  > https://software.opensuse.org/package/gradle
>  > https://tracker.debian.org/pkg/gradle
>  
>  They are unlikely to be of much help given how out of date they are.
>  Gradle is currently at 6.1.1 and Debian seems to be packaging 4.4.1
>  and OpenSuse is at 3.2.1.  Ubuntu seems to be 4.7 
about versions available [1] 

[1] 
https://repology.org/project/gradle/versions


>  The other message that posted the link to the email regarding the
>  removeal of Gradle indicated a lot more dependencies were added since
>  those versions were packaged.
>  
>  It is telling when essentially none of the open source operating
>  systems have a current gradle version (FreeBSD does, but they just
>  grab and wrap the binary from the Gradle website) that gets built
>  from
>  source.
>   
-- 
Sérgio M. B.

[Neal Gompa]

On Sat, Feb 8, 2020 at 7:04 PM Gerald Henriksen <ghenriks(a)gmail.com&gt; wrote:
>  On Sat, 8 Feb 2020 18:50:25 +0100, you wrote:
>
>  >> and why gradle was retired ? is easy unretire it ?
>  >
>  >I am running gradle command right now as a coincidence .
>  >
>  >The upstream project is active.
>  >https://github.com/gradle/gradle
>  >
>  >We also might refer other distribution's spec files if we unretire.
>  >https://software.opensuse.org/package/gradle
>  >https://tracker.debian.org/pkg/gradle
>
>  They are unlikely to be of much help given how out of date they are.
>  Gradle is currently at 6.1.1 and Debian seems to be packaging 4.4.1
>  and OpenSuse is at 3.2.1.  Ubuntu seems to be 4.7
>  
openSUSE is currently on 4.4.1 as well[1].

[1]:
https://build.opensuse.org/package/view_file/openSUSE:Factory/gradle/grad...

Rebasing to Gradle 5 or higher means Java 7 support is dropped. That
probably held back a lot of people from doing Gradle upgrades for a
while. Gradle 5 and 6 also does some significant changes to the Gradle
Groovy-based DSL, which means that a lot of projects are likely
struggling to upgrade.

But the Gradle 5.0 release introduced the Kotlin-based DSL, and we
don't even have Kotlin in Fedora...

>  The other message that posted the link to the email regarding the
>  removeal of Gradle indicated a lot more dependencies were added since
>  those versions were packaged.
>
>  It is telling when essentially none of the open source operating
>  systems have a current gradle version (FreeBSD does, but they just
>  grab and wrap the binary from the Gradle website) that gets built from
>  source. 
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).



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Gerald Henriksen]

On Sat, 8 Feb 2020 19:16:45 -0500, you wrote:

> 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). 
Go and Rust have the advantage that the build system is included in
the language, so packagers don't have to attempt to package x
different build systems (and because they are included, they also
don't tend to have an expanding with time dependency list).

[Nicolas Mailhot]

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.

Regards,

-- 
Nicolas Mailhot

[Ankur Sinha]

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

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...
  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?

What are our other options? (Of course, I assume bundling the Gradle
binary for Fedora is out.)

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London

[Neal Gompa]

On Sun, Feb 9, 2020 at 8:49 AM Ankur Sinha <sanjay.ankur(a)gmail.com&gt; 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.
>
>  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.
>
>  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...
>    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?
>
>  What are our other options? (Of course, I assume bundling the Gradle
>  binary for Fedora is out.)
>  
One way to bootstrap getting Gradle back in Fedora is to have it
packaged with a vendored set of source dependencies, and build
everything from source that way. That'll make each gradle package
build quite slow, but at least packaging the dependencies can be done
iteratively rather than all at once.

This is essentially the approach that was done for Go and some
"special" Python applications. As the Fedora guidelines allow bundling
provided the spec has versioned bundled() Provides, this is the
fastest, most-compliant approach.




--
真実はいつも一つ！/ Always, there's only one truth!

[Fabio Valentini]

On Sun, Feb 9, 2020 at 2:49 PM Ankur Sinha <sanjay.ankur(a)gmail.com&gt; 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

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

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

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

Fabio

> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Neal Gompa]

On Sun, Feb 9, 2020 at 2:09 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  On Sun, Feb 9, 2020 at 2:49 PM Ankur Sinha <sanjay.ankur(a)gmail.com&gt; 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...
>  >   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!

[Jun Aruga]

>  netcdf-java[1] uses the Gradle build system, and is required to
> update 
hdfview[2] to the latest version. Gradle, however, was retired[3] as
"out of date, broken, fails to build, basically unmaintainable".

Checking the build.grade file (gradle recipe filei) of netcdf-java, is
it possible to build and run it  with "javac" and "java" command
without "gradle"?
https://github.com/Unidata/netcdf-java/blob/master/build.gradle

-- 
Jun | He - His - Him

[Ankur Sinha]

On Sun, Feb 09, 2020 20:49:19 +0100, Jun Aruga wrote:
>  > netcdf-java[1] uses the Gradle build system, and is required to
> update
>  hdfview[2] to the latest version. Gradle, however, was retired[3] as
>  "out of date, broken, fails to build, basically unmaintainable".
>  
>  Checking the build.grade file (gradle recipe filei) of netcdf-java, is
>  it possible to build and run it  with "javac" and "java" command
>  without "gradle"?
>  https://github.com/Unidata/netcdf-java/blob/master/build.gradle 
I'm sure it must be doable, but it brings us back to the same issue of
packagers having to interpret Gradle build files to implement the build
manually. It'll probably be easier to migrate them to Maven files if we
do go down this road.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London

[Ankur Sinha]

On Sun, Feb 09, 2020 14:23:12 -0500, Neal Gompa wrote:
>  On Sun, Feb 9, 2020 at 2:09 PM Fabio Valentini
> <decathorpe(a)gmail.com&gt; wrote:
>  >
>  <snip>
>  >
>  > > 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. 
I'll have a look at this to see what the effort required here is. If it
can be done automatically, it may not be so hard. I found this, for
example:

https://github.com/tvaughan77/gradle2maven

>  > - 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. 
I certainly see your point, but given the (perceived?) lack of Java
focussed man-power in the community at the moment, it is hard to say if:

- we'll have enough resources to unbundle it in the short-term future;
- we'll have enough resources to maintain the whole unbundled ecosystem
  in the long-term future.

I.e., will this last in the long term, or will we be having such a
conversation again soon?

I guess we can just keep the bundled version as long as we need to, but
before we go down this option: how many folks in the community can
commit to helping maintain Gradle, at least in its bundled form, in the
long term, say till F34 release? If we don't have enough resources for
this, then the initial effort may not be worth investing in the first
place.

I can help with general packaging, I don't do a lot of Java, and I
certainly don't do a lot of Gradle, so I would not want to be the single
or main point-of-contact for this. My focus in Fedora is
SciTech/NeuroFedora, and I do not have cycles to also prioritise
Java/Gradle work.


>  <snip> 
-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London

[Ankur Sinha]

On Mon, Feb 10, 2020 11:31:08 +0000, Ankur Sinha wrote:
>  On Sun, Feb 09, 2020 14:23:12 -0500, Neal Gompa wrote:
>  > On Sun, Feb 9, 2020 at 2:09 PM Fabio Valentini <decathorpe(a)gmail.com&gt; wrote:
>  > >
>  > <snip>
>  > >
>  > > > 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.
>  
>  I'll have a look at this to see what the effort required here is. If it
>  can be done automatically, it may not be so hard. I found this, for
>  example:
>  
>  https://github.com/tvaughan77/gradle2maven
>  
>  > > - 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.
>  
>  I certainly see your point, but given the (perceived?) lack of Java
>  focussed man-power in the community at the moment, it is hard to say if:
>  
>  - we'll have enough resources to unbundle it in the short-term future;
>  - we'll have enough resources to maintain the whole unbundled ecosystem
>    in the long-term future.
>  
>  I.e., will this last in the long term, or will we be having such a
>  conversation again soon?
>  
>  I guess we can just keep the bundled version as long as we need to, but
>  before we go down this option: how many folks in the community can
>  commit to helping maintain Gradle, at least in its bundled form, in the
>  long term, say till F34 release? If we don't have enough resources for
>  this, then the initial effort may not be worth investing in the first
>  place. 
Anyone with the time to (co-)maintain Gradle? :)

>  I can help with general packaging, I don't do a lot of Java, and
> I
>  certainly don't do a lot of Gradle, so I would not want to be the single
>  or main point-of-contact for this. My focus in Fedora is
>  SciTech/NeuroFedora, and I do not have cycles to also prioritise
>  Java/Gradle work. 


-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London

[Jun Aruga]

>  Anyone with the time to (co-)maintain Gradle? :) 
I added Mikolaj and Daniel to TO.
They had maintained gradle before being dead.package, seeing the past
commits in rpms/gradle.
Mikolaj and Daniel, do you like to come back as a maintainer of rpms/gradle?

-- 
Jun | He - His - Him

[Mikolaj Izdebski]

On Thu, Feb 13, 2020 at 11:33 AM Jun Aruga <jaruga(a)redhat.com&gt; wrote:
>  > Anyone with the time to (co-)maintain Gradle? :)
>
>  I added Mikolaj and Daniel to TO.
>  They had maintained gradle before being dead.package, seeing the past
>  commits in rpms/gradle.
>  Mikolaj and Daniel, do you like to come back as a maintainer of rpms/gradle? 
Currently I don't have time to maintain Gradle in Fedora. Several of
my packages are built with Gradle by their upstreams, but currently it
is more feasible to port packages to be built with Maven rather than
maintaining Gradle in Fedora. But this may change in the future - as
more projects start to use Gradle I may decide to take up its
maintenance in upcoming years.

--
Mikolaj Izdebski

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 17, 2020 at 09:13:14AM +0100, Mikolaj Izdebski wrote:
>  On Thu, Feb 13, 2020 at 11:33 AM Jun Aruga <jaruga(a)redhat.com&gt;
> wrote:
>  >
>  > > Anyone with the time to (co-)maintain Gradle? :)
>  >
>  > I added Mikolaj and Daniel to TO.
>  > They had maintained gradle before being dead.package, seeing the past
>  > commits in rpms/gradle.
>  > Mikolaj and Daniel, do you like to come back as a maintainer of rpms/gradle?
>  
>  Currently I don't have time to maintain Gradle in Fedora. Several of
>  my packages are built with Gradle by their upstreams, but currently it
>  is more feasible to port packages to be built with Maven rather than
>  maintaining Gradle in Fedora. But this may change in the future - as
>  more projects start to use Gradle I may decide to take up its
>  maintenance in upcoming years. 
It seems gradle is also used by checkerframework [1], which is in the
dependency tree of closure-compiler.

Returning to the case of netcdf-java, the build is not that trivial,
since the package uses JNI to access a few c libraries. Recreating
that in maven will not be a trivial task.

I tried to apply gradle2maven on netcdf-java. After fixing a bunch of
trivial issues (g2m only allowed single quotes, the project uses double,
g2m had minor syntax differences that caused the regexps used by g2m to
fails, etc), I realized that gradle has a substitution system for variables
defined using 'ext{...}', which g2m has no notion of. So g2m would certainly
require a lot of work to be useful.

Somewhat desperate, I tried the gradle version in F30 on netcdf-java,
and the results seemed promising. The build failed because F30 has too-old
xmlunit, and with a newer one some other things in F30 are incompatible,
but it seems that gradle is at least able to load the project.

After spending a few hours on those two cases, I think bringing back
groovy and gradle would be the best path forward. It just seems to be
more promising over longer term. Trying to hold back the wave of
projects using gradle will cause more and more holes in our dependency
graph, and converting anything except the trivial projects is clearly
very painful. (In fact, this shows the advantage of declarative syntax
over imperative. Clearly converting maven to gradle is easy, and going
back the other way not. In the light of this, building another
imperative build system is a large step backwards, but if that's what
our upstreams chose, we don't have much choice.)

What would be the path toward bringing gradle back in F32+?

[1] https://github.com/typetools/checker-framework/

Zbyszek

[Fabio Valentini]

On Tue, Mar 10, 2020 at 7:48 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  On Mon, Feb 17, 2020 at 09:13:14AM +0100, Mikolaj Izdebski wrote:
>  > On Thu, Feb 13, 2020 at 11:33 AM Jun Aruga <jaruga(a)redhat.com&gt; wrote:
>  > >
>  > > > Anyone with the time to (co-)maintain Gradle? :)
>  > >
>  > > I added Mikolaj and Daniel to TO.
>  > > They had maintained gradle before being dead.package, seeing the past
>  > > commits in rpms/gradle.
>  > > Mikolaj and Daniel, do you like to come back as a maintainer of rpms/gradle?
>  >
>  > Currently I don't have time to maintain Gradle in Fedora. Several of
>  > my packages are built with Gradle by their upstreams, but currently it
>  > is more feasible to port packages to be built with Maven rather than
>  > maintaining Gradle in Fedora. But this may change in the future - as
>  > more projects start to use Gradle I may decide to take up its
>  > maintenance in upcoming years.
>
>  It seems gradle is also used by checkerframework [1], which is in the
>  dependency tree of closure-compiler.
>
>  Returning to the case of netcdf-java, the build is not that trivial,
>  since the package uses JNI to access a few c libraries. Recreating
>  that in maven will not be a trivial task.
>
>  I tried to apply gradle2maven on netcdf-java. After fixing a bunch of
>  trivial issues (g2m only allowed single quotes, the project uses double,
>  g2m had minor syntax differences that caused the regexps used by g2m to
>  fails, etc), I realized that gradle has a substitution system for variables
>  defined using 'ext{...}', which g2m has no notion of. So g2m would certainly
>  require a lot of work to be useful.
>
>  Somewhat desperate, I tried the gradle version in F30 on netcdf-java,
>  and the results seemed promising. The build failed because F30 has too-old
>  xmlunit, and with a newer one some other things in F30 are incompatible,
>  but it seems that gradle is at least able to load the project.
>
>  After spending a few hours on those two cases, I think bringing back
>  groovy and gradle would be the best path forward. It just seems to be
>  more promising over longer term. Trying to hold back the wave of
>  projects using gradle will cause more and more holes in our dependency
>  graph, and converting anything except the trivial projects is clearly
>  very painful. (In fact, this shows the advantage of declarative syntax
>  over imperative. Clearly converting maven to gradle is easy, and going
>  back the other way not. In the light of this, building another
>  imperative build system is a large step backwards, but if that's what
>  our upstreams chose, we don't have much choice.) 
(snip)

>  What would be the path toward bringing gradle back in F32+? 
From the little experience I have with the gradle package, I think
we'd need to follow roughly these steps:

- fix the last version of gradle that was available from fedora,
before it was retired
(by "fix", I mean: be able to build, and build itself in non-bootstrap mode)
- do the same for groovy (which has a mutual dependency with gradle)
- try to update gradle to newer versions (probably by first bundling
some dependencies, e.g. kotlin)
- and after that's done, un-bundle those dependencies and package them
separately.

I think it should also be possible to pool resources with the
maintainers of gradle in OpenSUSE and maybe Mageia.

Fabio

> [1] https://github.com/typetools/checker-framework/
>
> Zbyszek
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Mario Torre]

The problem with Gradle as far as I'm aware is that it's a moving
target. It insist on updating itself when you have an incompatible
version and versions tend to break compatibility a lot, with new
features added often, all of which makes impossible for a Linux
distribution to keep up realiably.

Cheers,
Mario

On Sat, Feb 8, 2020 at 12:23 PM Ankur Sinha <sanjay.ankur(a)gmail.com&gt; wrote:
>  Hello,
>
>  netcdf-java[1] uses the Gradle build system, and is required to update
>  hdfview[2] to the latest version. Gradle, however, was retired[3] as
>  "out of date, broken, fails to build, basically unmaintainable".
>
>  Now, I know that following our system, one must package Gradle first but
>  given the retirement comment, packaging and then maintaining it does not
>  appear a simple task, and for one dependency only, it seems overkill.
>
>  Is there perhaps a way of bypassing that somehow? For example, is there
>  a way to use good old Maven to build a Gradle based project?
>
>  [1] https://docs.unidata.ucar.edu/netcdf-java/5.2/userguide/building_from_sou...
>  [2] https://bugzilla.redhat.com/show_bug.cgi?id=1797361
>  [3] https://src.fedoraproject.org/rpms/gradle/blob/master/f/dead.package
>
>  --
>  Thanks,
>  Regards,
>  Ankur Sinha "FranciscoD" (He / Him / His) |
> https://fedoraproject.org/wiki/User:Ankursinha
>  Time zone: Europe/London
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail] 


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

[Ankur Sinha]

Hi Mario,

On Thu, Feb 13, 2020 11:39:31 +0100, Mario Torre wrote:
>  The problem with Gradle as far as I'm aware is that it's a
> moving
>  target. It insist on updating itself when you have an incompatible
>  version and versions tend to break compatibility a lot, with new
>  features added often, all of which makes impossible for a Linux
>  distribution to keep up realiably. 
Thanks for that.

So, basically, packaging and maintaining Gradle are both not easily
doable, certainly not in the man-power we have.

So, I'll focus on converting Gradle projects to Maven as the short-term
solution. I'll start a new thread for that to see how other maintainers
currently go about it.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London

[Miro Hrončok]

On 14. 02. 20 12:45, Ankur Sinha wrote:
>  So, I'll focus on converting Gradle projects to Maven as the
> short-term
>  solution. I'll start a new thread for that to see how other maintainers
>  currently go about it. 
Thanks for doing this! You rock.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Mikolaj Izdebski]

On Sat, Feb 8, 2020 at 12:23 PM Ankur Sinha <sanjay.ankur(a)gmail.com&gt; wrote:
>  Hello,
>
>  netcdf-java[1] uses the Gradle build system, and is required to update
>  hdfview[2] to the latest version. Gradle, however, was retired[3] as
>  "out of date, broken, fails to build, basically unmaintainable".
>
>  Now, I know that following our system, one must package Gradle first but
>  given the retirement comment, packaging and then maintaining it does not
>  appear a simple task, and for one dependency only, it seems overkill.
>
>  Is there perhaps a way of bypassing that somehow? For example, is there
>  a way to use good old Maven to build a Gradle based project? 
There are several different ways to handle this problem. In this case
my recommendation is to port packages to be built with Maven instead
of Gradle. The exact way to do this varies between projects, but in
general you'd need to obtain Maven POMs for particular project (eg.
from Maven Central), add missing build instructions (<build> section
of POM files) and model composition/inheritance (<modules> and
<parent> elements of POM). There are several cases of packages that
are built this way in Fedora, which you can use as examples. Let me
know if you need more help.

--
Mikolaj Izdebski

[Jun Aruga]

Hi Mikolaj,

Thanks for your info and recommendation.

>  Currently I don't have time to maintain Gradle in Fedora. Several
> of 
my packages are built with Gradle by their upstreams, but currently it
is more feasible to port packages to be built with Maven rather than
maintaining Gradle in Fedora. But this may change in the future - as
more projects start to use Gradle I may decide to take up its
maintenance in upcoming years.

>  There are several different ways to handle this problem. In this case
my recommendation is to port packages to be built with Maven instead
of Gradle.

Shall we write something about the Gradle's situation to the wiki
Packaging:Java page?
https://fedoraproject.org/wiki/Packaging:Java

I think that it helps other Java packagers.

-- 
Jun | He - His - Him