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

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

 



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