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_source... [2] https://bugzilla.redhat.com/show_bug.cgi?id=1797361 [3] https://src.fedoraproject.org/rpms/gradle/blob/master/f/dead.package
On Sat, Feb 8, 2020 at 6:23 AM Ankur Sinha sanjay.ankur@gmail.com 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_source... [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...
On Sat, Feb 8, 2020 at 10:44 AM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Feb 8, 2020 at 6:23 AM Ankur Sinha sanjay.ankur@gmail.com 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_source... [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?
On Sat, Feb 8, 2020 at 11:40 AM Nico Kadel-Garcia nkadel@gmail.com wrote:
On Sat, Feb 8, 2020 at 10:44 AM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Feb 8, 2020 at 6:23 AM Ankur Sinha sanjay.ankur@gmail.com 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_source... [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.
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@gmail.com wrote:
On Sat, Feb 8, 2020 at 10:44 AM Neal Gompa ngompa13@gmail.com wrote:
On Sat, Feb 8, 2020 at 6:23 AM Ankur Sinha < sanjay.ankur@gmail.com> 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_source... [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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Sat, Feb 8, 2020 at 5:08 PM Sérgio Basto sergio@serjux.com wrote:
and why gradle was retired ? is easy unretire it ?
Announced here (with reasons): https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapro...
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
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.
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.
On Sat, Feb 8, 2020 at 7:04 PM Gerald Henriksen ghenriks@gmail.com 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/gradle....
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).
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).
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,
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-po... 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.)
On Sun, Feb 9, 2020 at 8:49 AM Ankur Sinha sanjay.ankur@gmail.com 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-po... 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!
On Sun, Feb 9, 2020 at 2:49 PM Ankur Sinha sanjay.ankur@gmail.com 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-po... 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Sun, Feb 9, 2020 at 2:09 PM Fabio Valentini decathorpe@gmail.com wrote:
On Sun, Feb 9, 2020 at 2:49 PM Ankur Sinha sanjay.ankur@gmail.com 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-po... 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.
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
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.
On Sun, Feb 09, 2020 14:23:12 -0500, Neal Gompa wrote:
On Sun, Feb 9, 2020 at 2:09 PM Fabio Valentini decathorpe@gmail.com 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>
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@gmail.com 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.
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?
On Thu, Feb 13, 2020 at 11:33 AM Jun Aruga jaruga@redhat.com 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
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@redhat.com 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
On Tue, Mar 10, 2020 at 7:48 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl 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@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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@gmail.com 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_source... [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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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.
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.
On Sat, Feb 8, 2020 at 12:23 PM Ankur Sinha sanjay.ankur@gmail.com 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
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.
-
Ankur Sinha -
Fabio Valentini -
Gary Buhrmaster -
Gerald Henriksen -
Jun Aruga -
Mario Torre -
Mikolaj Izdebski -
Miro Hrončok -
Neal Gompa -
Nico Kadel-Garcia -
Nicolas Mailhot -
Sérgio Basto -
Zbigniew Jędrzejewski-Szmek