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@xxxxxxxxxx> 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/ -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
