On Tue, Mar 10, 2020 at 7:48 PM Zbigniew Jędrzejewski-Szmek
<zbys...@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 <jar...@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-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
