Re: [fedora-java] Gradle upgrade issues (#976330)
Mikolaj,
Thanks for taking the time to reply. I was in part seeking to find out
if the problems with packaging Gradle are something that I could spend
some time to help address, but it looks like they're significant enough
that I don't have the time to work on them right now.
Some more comments inline.
On Mon, 21 Oct 2013 17:55:47 +0200
Mikolaj Izdebski <mizdebsk(a)redhat.com>
wrote:
On 10/21/2013 05:11 PM, Michael Ekstrand wrote:
> - Incompatible dependencies (Gradle may require package versions no
> longer shipped in Fedora)
Gradle used to use (very) old versions of some dependencies, for
example legacy pre-1.0 alpha version of Plexus, released ~10 years
ago. It also used some Maven 2 APIs (Fedora ships Maven 3 only).
This was improved recently IIRC.
Gradle also uses Sonatype Aether, which is not in Fedora any longer.
Porting it to Eclipse Aether should be fairly straightforward, but
still, needs to be done.
It seems like that is potentially problematic - what if a build script
(unfortunately) depends on the fact that Gradle uses Sonatype Aether -
but also unavoidable. I would hope that the set of projects that would
be affected by this is minimal.
> - Bootstrapping problems (the Gradle 1.8 sources won't build
with
> Gradle 1.8, they seem to require 1.7)
These are IMO two separate problems.
1. Gradle breaks compatibility between releases. If package builds
with Gradle version X then it not necessarily builds with Gradle
version Y, Y
> X. This is a serious problem as Fedora may have to maintain
> multiple
versions of Gradle to build different projects. Other build systems
may have some incompatibilities too, but in case of Gradle they are
causing more problems. Additionally, Gradle build scripts are
written in fully-featured programming language and may not be so easy
to port to different version of Gradle.
2. Gradle is built with itself (as many build systems are), so it
needs bootstrapping. Upstream of majority of other build systems
(including Ant or Maven) are maintaining secondary ways of building
them (Ant can be built with javac, Maven can be built with Ant etc.),
but Gradle upstream does not provide any way to bootstrap Gradle.
Normally bootstrapping would need to be performed only once, but
because of 1. bootstrapping may be required more often, worst case
with every release.
If the general pattern is followed of Gradle X building with Gradle
X-1, then it shouldn't be too bad - once gradle18 is bootstrapped and
in, then gradle19 can Build-Require gradle18. Assuming multiple Gradle
versions, which seems nasty.
If this isn't the general pattern, then more bootstrapping with
backwards compatibility problems.
This does indeed feel like a colossal mess.
To sum up, Gradle maintainence requires substantial amount of work.
Currently only few packages in Fedora are using Gradle which means
that maintenance costs of Gradle outweight costs of porting other
packages to different build systems.
Thanks for elucidating just how much work. It does indeed seem to be
not worth the effort.
My personal interest is primarily in having Gradle available for use in
automating my various projects, but it looks like continuing to just
use Gradle's binary distributions is the best path forward for that.
Along with avoiding using Gradle as the (sole) build system for
software that I distribute with intent to see packaged in distributions.
- Michael
--
Michael Ekstrand — http://elehack.net/