Bug#733234: Groovy fails with groovy.lang.MissingMethodException

Russel Winder russel at winder.org.uk
Fri Apr 18 15:18:20 UTC 2014

On Fri, 2014-04-18 at 00:44 +0100, Stephen Nelson wrote:
> I'm looking at this too, as it stops work on building Spring using
> Gradle. I updated groovy to 1.8.9, and still gradle fails. So I
> thought about including the required dependencies to enable the groovy
> tests. This will prove the software performs as originally intended.
> So far, I've got the tests to compile but not yet run with groovy
> 1.8.9. I can continue with that, but I agree getting a more recent
> groovy would be advantageous for reasons other than gradle.

I am a Debian Sid user and supporter (people keep trying to take me to
Fedora, but I resist :-) I am also on the Groovy development team, wrote
Gant and am driving the reworking of GPars. I am a Java 8 user, for me
all Javas prior to 8 no longer exist. I mention all this (that Miguel
already knows), to reinforce that I want to be constructive and
supportive in what is turning into a bit of a mess.

The core problem here with the Java and Groovy support on Debian is the
policy of one and only one version, and no use of Maven Central or
Bintray/jCentre for build.

The whole Java milieu revolves around concurrent multiple versions of
artefacts, with dependency management. People try and avoid multiple
versions of an artefacts running at the same time on a single JVM
instance, but when they do that then they use OSGi.

Frameworks like Gradle, Grails, Griffon generally carry their own
version of Groovy so as to ensure no incompatibilities or "dependency
hell".  Gradle is currently stuck on using Groovy 1.8.6 because of some
"breaking change" in 1.8.7 and later. The Gradleware folk are looking to
upgrade to Groovy 2.2.2 for Gradle 2.0 which will be the next release
after 1.12 in a few days. Gradleware have a timeboxed approach so 2.0 is
effectively imminent.

Most people these days are using GVM Tool (a bash script system) to
download Gradle, Grails, Groovy, Vert.x, Griffon, etc. This works well
and nigh on obviates the need for any of these to be packaged by Debian.

On the other hand Gradle is now the standard build framework for
Android, and AndroidStudio the default IDE. I mention this to suggest
that having up to date Gradle is probably more important than up-to-date
Groovy. This is reinforced because most people will use Maven Central to
get Groovy from for their projects anyway. So just because Gradle uses
Groovy 1.8.6, the systems built using Gradle are likely using Groovy
2.2.3 (or now 2.3.0-beta).

Gradle is also becoming a C++ build system to replace Make, CMake,
Autotools, and do battle with SCons and Waf. Like Waf, projects will use
the Gradle Wrapper so that the project can use the right version of
Gradle and thence Groovy to avoid problems. Of course this usage means
Gradle Wrapper falls into the same problem as Waf with respect to Debian
packaging policy.

Shortly Gradle will be using Groovy 2.2 and I think that is the right
point to get a Gradle/Groovy system into Jessie. I'm afraid there is no
point in trying to get any Groovy later than 1.8.6 in if Gradle 1.x is
in Debian and the "single version only" policy is to be maintained.

Do let me know what I can do to help here. Although I compile Groovy
master/HEAD for my use and use GVM for Gradle, I want to see a modern
Gradle (and Groovy) in Debian. The best thing of course would be to
allow the latest Gradle to use whichever Groovy it wants, and allow the
latest Groovy to be installed as well. However I understand this is
incompatible with Debian packaging policy. Thus the only feasble thing
to provide maximum benefit is to package the latest Gradle and just use
the dependencies it demands.

Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

More information about the pkg-java-maintainers mailing list