Bug#733234: Groovy fails with groovy.lang.MissingMethodException
On Fri, Apr 18, 2014 at 12:51:38AM +0200, Bálint Réczey wrote: When there is a groovy - gradle pair in the archive which can build itself I'll check back to this problem again. I believe gradle and groovy are now fixed in unstable, so please ping me when you have the chance to revisit this issue. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://db.debian.org/fetchkey.cgi?fingerprint=4CB7FE1E280ECC90F29A597E6E608B637D8967E9 Faith means not wanting to know what is true. -- Nietzsche signature.asc Description: Digital signature
Bug#733234: Groovy fails with groovy.lang.MissingMethodException
Hi Miguel, 2014-05-08 23:17 GMT+02:00 Miguel Landaeta nomad...@debian.org: On Fri, Apr 18, 2014 at 12:51:38AM +0200, Bálint Réczey wrote: When there is a groovy - gradle pair in the archive which can build itself I'll check back to this problem again. I believe gradle and groovy are now fixed in unstable, so please ping me when you have the chance to revisit this issue. The attached patch still makes the issue reproducible on xbmc 2:13.0+dfsg1-1: ... touch xbmc/interfaces/python/generated/doxygenxml mkdir -p xbmc/interfaces/python/generated /usr/bin/swig -w401 -c++ -o xbmc/interfaces/python/generated/AddonModuleXbmc.xml -xml -I./xbmc -xmllang python xbmc/interfaces/swig/AddonModuleXbmc.i # Work around potential groovy bug reported at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733234 # groovyc -cp /usr/share/java/groovy.jar:/usr/share/java/commons-lang-2.6.jar:./tools/codegenerator:xbmc/interfaces/python -d tools/codegenerator tools/codegenerator/Helper.groovy tools/codegenerator/SwigTypeParser.groovy xbmc/interfaces/python/MethodType.groovy xbmc/interfaces/python/PythonTools.groovy groovy -cp /usr/share/java/groovy.jar:/usr/share/java/commons-lang-2.6.jar:./tools/codegenerator:xbmc/interfaces/python \ ./tools/codegenerator/Generator.groovy xbmc/interfaces/python/generated/AddonModuleXbmc.xml xbmc/interfaces/python/PythonSwig.cpp.template xbmc/interfaces/python/generated/AddonModuleXbmc.cpp xbmc/interfaces/python/generated/doxygenxml org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: /«BUILDDIR»/xbmc-13.0+dfsg1/tools/codegenerator/Generator.groovy: 25: unable to resolve class Helper @ line 25, column 1. import Helper ^ 1 error make[2]: *** [xbmc/interfaces/python/generated/AddonModuleXbmc.cpp] Error 1 codegenerator.mk:35: recipe for target 'xbmc/interfaces/python/generated/AddonModuleXbmc.cpp' failed rm xbmc/interfaces/python/generated/AddonModuleXbmc.xml ... Cheers, Balint From bf79793de645a2d1c71c18da0483084ac6ce7193 Mon Sep 17 00:00:00 2001 From: Balint Reczey bal...@balintreczey.hu Date: Thu, 8 May 2014 23:30:16 +0200 Subject: [PATCH] XXX disable groovy workaround --- debian/patches/07-use-system-groovy.patch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/patches/07-use-system-groovy.patch b/debian/patches/07-use-system-groovy.patch index 1c1de64..bee19de 100644 --- a/debian/patches/07-use-system-groovy.patch +++ b/debian/patches/07-use-system-groovy.patch @@ -15,7 +15,7 @@ index 6689777..6afaa7d 100644 - org.codehaus.groovy.tools.FileSystemCompiler -d $(TOPDIR)/tools/codegenerator $(TOPDIR)/tools/codegenerator/Helper.groovy $(TOPDIR)/tools/codegenerator/SwigTypeParser.groovy $(INTERFACES_DIR)/python/MethodType.groovy $(INTERFACES_DIR)/python/PythonTools.groovy - $(JAVA) -cp $(GROOVY_DIR)/groovy-all-2.1.7.jar:$(GROOVY_DIR)/commons-lang-2.6.jar:$(TOPDIR)/tools/codegenerator:$(INTERFACES_DIR)/python \ - groovy.ui.GroovyMain $(TOPDIR)/tools/codegenerator/Generator.groovy $ $(INTERFACES_DIR)/python/PythonSwig.cpp.template $@ $(DOXY_XML_PATH) -+ groovyc -cp /usr/share/java/groovy.jar:/usr/share/java/commons-lang-2.6.jar:$(TOPDIR)/tools/codegenerator:$(INTERFACES_DIR)/python -d tools/codegenerator tools/codegenerator/Helper.groovy tools/codegenerator/SwigTypeParser.groovy $(INTERFACES_DIR)/python/MethodType.groovy $(INTERFACES_DIR)/python/PythonTools.groovy ++ # groovyc -cp /usr/share/java/groovy.jar:/usr/share/java/commons-lang-2.6.jar:$(TOPDIR)/tools/codegenerator:$(INTERFACES_DIR)/python -d tools/codegenerator tools/codegenerator/Helper.groovy tools/codegenerator/SwigTypeParser.groovy $(INTERFACES_DIR)/python/MethodType.groovy $(INTERFACES_DIR)/python/PythonTools.groovy + groovy -cp /usr/share/java/groovy.jar:/usr/share/java/commons-lang-2.6.jar:$(TOPDIR)/tools/codegenerator:$(INTERFACES_DIR)/python \ + $(TOPDIR)/tools/codegenerator/Generator.groovy $ $(INTERFACES_DIR)/python/PythonSwig.cpp.template $@ $(DOXY_XML_PATH) rm $ -- 2.0.0.rc0
Bug#733234: Groovy fails with groovy.lang.MissingMethodException
On Sat, 2014-05-03 at 16:03 -0300, Miguel Landaeta wrote: […] FYI: If there are not objections and I don't stumble upon any other blocker issue, I intend to upload groovy2 package during the next week to unstable. That works for me. Gradle 1.12 was released a few days ago. It will be the last in the 1.x series, the next Gradle will be 2.0 and it will depend on Groovy 2, probably 2.2.2. My guess is that it will be 4 to 8 weeks, but I am not a Gradle insider. I can find out more if that would help. As far as I am aware no other mainstream Groovy-based system depends on Groovy 1: Griffon, Grails, Gant, Lazybones, GroovyFX, all work on Groovy 2.2. Groovy 2.3 is in release candidate cycle, and is the first Groovy to officially support Java 8, though it still works with Java 6 for those who have not yet realized that 6 is a dead version of Java :-) Personally I only use Java 8 and have done for many, many months. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733234: Groovy fails with groovy.lang.MissingMethodException
tags 746253 + pending tags 744337 + pending tags 745815 + pending thanks On Sat, Apr 19, 2014 at 10:00:33AM -0300, Miguel Landaeta wrote: I just raised the voice on this gradle/groovy situation because after my groovy 1.8.6-2 upload gradle is not working anymore and I'm looking for more eyaballs on this issue. Getting groovy 1.8.6 working again is needed to advance with groovy2. FYI: If there are not objections and I don't stumble upon any other blocker issue, I intend to upload groovy2 package during the next week to unstable. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://db.debian.org/fetchkey.cgi?fingerprint=4CB7FE1E280ECC90F29A597E6E608B637D8967E9 Faith means not wanting to know what is true. -- Nietzsche signature.asc Description: Digital signature
Bug#733234: Groovy fails with groovy.lang.MissingMethodException
Thanks everybody for their input. On Fri, Apr 18, 2014 at 05:54:17PM +0200, Emmanuel Bourg wrote: Thanks to your explanations it becomes clear I think that we must package groovy 2 separately, and keep the original groovy package at version 1.8.6 until the transition to Gradle 2 is complete. Miguel are you ok with this plan? Initially I wasn't OK with this but given the approaching deadlines I think this is our best option at this point, to have a separate groovy2 package. BTW, this is almost done because since many months ago I maintain a package for groovy 2.x branch in experimental. I just raised the voice on this gradle/groovy situation because after my groovy 1.8.6-2 upload gradle is not working anymore and I'm looking for more eyaballs on this issue. Getting groovy 1.8.6 working again is needed to advance with groovy2. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://db.debian.org/fetchkey.cgi?fingerprint=4CB7FE1E280ECC90F29A597E6E608B637D8967E9 Faith means not wanting to know what is true. -- Nietzsche signature.asc Description: Digital signature
Bug#733234: Groovy fails with groovy.lang.MissingMethodException
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. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733234: Groovy fails with groovy.lang.MissingMethodException
Hi, On 18/04/14 17:18, Russel Winder wrote: 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. I am not aware of any such policy as one and only one version: one could have a groovy and a groovy2 package and hence both could be packaged (and used) in parallel (or not, if one decides that both can't exist on the same machine at the same time). It's just not automatic, someone needs to take the decision and make sure the dependencies and paths are set right. Cheers, Eric -- I'm subscribed on debian-java, debian-mentors, pkg-java-maintainers and pkg-vdr-dvb-devel. No need to CC me on these lists. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733234: Groovy fails with groovy.lang.MissingMethodException
On Fri, 2014-04-18 at 17:54 +0200, Emmanuel Bourg wrote: Thank you for stepping in Russel. No problem, glad to help. Just to clarify the unique version policy isn't an absolute requirement. If it's necessary multiple versions of an application or library can be packaged (for example JUnit 3 and 4, Maven 2 and 3, Tomcat 678, ASM 3 and 4, etc). Thanks to your explanations it becomes clear I think that we must package groovy 2 separately, and keep the original groovy package at version 1.8.6 until the transition to Gradle 2 is complete. This (mostly) works for me. If there is (Groovy|Gradle|Grails|Griffon) (1|2|3) then the dependency problem becomes a lot less painful. PS I am fairly sure we've collaborated before, was it something such as Commons CLI? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733234: Groovy fails with groovy.lang.MissingMethodException
Thank you for stepping in Russel. Just to clarify the unique version policy isn't an absolute requirement. If it's necessary multiple versions of an application or library can be packaged (for example JUnit 3 and 4, Maven 2 and 3, Tomcat 678, ASM 3 and 4, etc). Thanks to your explanations it becomes clear I think that we must package groovy 2 separately, and keep the original groovy package at version 1.8.6 until the transition to Gradle 2 is complete. Miguel are you ok with this plan? Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733234: Groovy fails with groovy.lang.MissingMethodException
tags 733234 + moreinfo thanks Hi Bálint, On Fri, Dec 27, 2013 at 04:28:39PM +0100, Bálint Réczey wrote: Package: groovy Version: 1.8.6-1 Severity: normal Hi, Using groovy to generate code in XBMC build fails. Sorry for my delay to handle this bug. To be honest, I'm not an expert about groovy or xbmc internals, so I was wondering if you can provide me with a more succint explanation about what you think is broken with groovy. In your first message I saw you satisfied xbmc build-depends from experimental but your classpath had references to the version from unstable. Right now I have a grave bug in groovy/gradle (#744337) since it looks like I'm unable to build a working package for 1.8.6 release with current default JDK and libraries from unstable. 1.8.6-1 used to work for a long time but as soon as I recompiled for 1.8.6-2 I'm seeing breakage in several places so I'm unable to even reproduce this bug right now. Maybe this is just 1.8.6 showing its age and I should focus on getting 2.x in unstable on time for jessie. Sorry I can't be more useful for this bug at this moment. Cheers, -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://db.debian.org/fetchkey.cgi?fingerprint=4CB7FE1E280ECC90F29A597E6E608B637D8967E9 Faith means not wanting to know what is true. -- Nietzsche signature.asc Description: Digital signature
Bug#733234: Groovy fails with groovy.lang.MissingMethodException
Hi Miguel,
2014-04-17 20:33 GMT+02:00 Miguel Landaeta nomad...@debian.org:
tags 733234 + moreinfo
thanks
Hi Bálint,
On Fri, Dec 27, 2013 at 04:28:39PM +0100, Bálint Réczey wrote:
Package: groovy
Version: 1.8.6-1
Severity: normal
Hi,
Using groovy to generate code in XBMC build fails.
Sorry for my delay to handle this bug.
To be honest, I'm not an expert about groovy or xbmc internals, so I
was wondering if you can provide me with a more succint explanation
about what you think is broken with groovy.
In your first message I saw you satisfied xbmc build-depends from
experimental but your classpath had references to the version from
unstable.
Right now I have a grave bug in groovy/gradle (#744337) since it
looks like I'm unable to build a working package for 1.8.6 release
with current default JDK and libraries from unstable.
1.8.6-1 used to work for a long time but as soon as I recompiled for
1.8.6-2 I'm seeing breakage in several places so I'm unable to even
reproduce this bug right now.
Maybe this is just 1.8.6 showing its age and I should focus on getting
2.x in unstable on time for jessie.
Sorry I can't be more useful for this bug at this moment.
I tried building groovy 2.2.1 on testing and it failed, too. I agree
that 2.x is the way to go and I think you could find a state of sid on
snapshots.debian.org, which lets you build 2.2.1 (2.2.2?) and latest
gradle as well.
When there is a groovy - gradle pair in the archive which can build
itself I'll check back to this problem again.
Cheers,
Balint
BTW I started playing with this patch to disable the DGM stuff, but
since groovy itself does not build I will return to this later:
---
src/main/org/codehaus/groovy/runtime/metaclass/MetaClassRegistryImpl.java.orig
2014-04-17 21:57:53.386313813 +0200
+++ src/main/org/codehaus/groovy/runtime/metaclass/MetaClassRegistryImpl.java
2014-04-17 21:58:42.353618465 +0200
@@ -90,7 +90,7 @@
final MapCachedClass, ListMetaMethod map = new
HashMapCachedClass, ListMetaMethod();
// let's register the default methods
-registerMethods(null, true, true, map);
+registerMethods(null, false, true, map);
final Class[] additionals = DefaultGroovyMethods.additionals;
for (int i = 0; i != additionals.length; ++i) {
createMetaMethodFromClass(map, additionals[i]);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733234: Groovy fails with groovy.lang.MissingMethodException
Hi Bálint, On Fri, Apr 18, 2014 at 12:51:38AM +0200, Bálint Réczey wrote: Sorry I can't be more useful for this bug at this moment. I tried building groovy 2.2.1 on testing and it failed, too. I agree that 2.x is the way to go and I think you could find a state of sid on snapshots.debian.org, which lets you build 2.2.1 (2.2.2?) and latest gradle as well. I committed to repo git://anonscm.debian.org/pkg-java/groovy.git a small fix that should allow to build 2.2.1 in unstable. I didn't test it in testing. I agree 2.x is the way to go but iff upstream release Gradle 2.0 buildable with Groovy 2.x on time for us to package it for jessie. If this doesn't happen, the alternatives are to fix 1.8.6 or drop groovy from jessie but this would be painful and I don't know if it's feasible at this point. When there is a groovy - gradle pair in the archive which can build itself I'll check back to this problem again. You can use 1.8.6-1 from jessie, that groovy version is known to work. PS. If I uploaded groovy 2.2.1 to unstable now I would break gradle and groovy itself by causing FTBFS on both packages. To summarize this mess: * gradle build-depends on itself. * AFAICT, gradle only works with groovy 1.8.x, 6 = x = 9. * groovy 1.8.6 is buildable with ant. * groovy 2.x build-depends on gradle. * gradle has an FTBFS already (#744337) caused by a bug introduced in groovy 1.8.6-2. Evidently, groovy (and software depending on it) can't advance on this situation. I appreciate help and comments from the team on this issue. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://db.debian.org/fetchkey.cgi?fingerprint=4CB7FE1E280ECC90F29A597E6E608B637D8967E9 Faith means not wanting to know what is true. -- Nietzsche signature.asc Description: Digital signature
Bug#733234: Groovy fails with groovy.lang.MissingMethodException
On Fri, Apr 18, 2014 at 12:33 AM, Miguel Landaeta nomad...@debian.org wrote: Hi Bálint, On Fri, Apr 18, 2014 at 12:51:38AM +0200, Bálint Réczey wrote: Sorry I can't be more useful for this bug at this moment. If I uploaded groovy 2.2.1 to unstable now I would break gradle and groovy itself by causing FTBFS on both packages. To summarize this mess: * gradle build-depends on itself. * AFAICT, gradle only works with groovy 1.8.x, 6 = x = 9. * groovy 1.8.6 is buildable with ant. * groovy 2.x build-depends on gradle. * gradle has an FTBFS already (#744337) caused by a bug introduced in groovy 1.8.6-2. Evidently, groovy (and software depending on it) can't advance on this situation. I appreciate help and comments from the team on this issue. Hi Miguel, 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. Many thanks Stephen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733234: Groovy fails with groovy.lang.MissingMethodException
Package: groovy Version: 1.8.6-1 Severity: normal Hi, Using groovy to generate code in XBMC build fails. Steps to reproduce: apt-get -t experimental groovy apt-get build-dep xbmc dget http://http.debian.net/debian/pool/main/x/xbmc/xbmc_12.3+dfsg1-1.dsc # if extraction fails dpkg-source -x xbmc_12.3+dfsg1-1.dsc cd xbmc-12.3+dfsg1/ sed -i 's/groovyc/# groovyc/' codegenerator.mk make -f codegenerator.mk Result: ... groovy -cp /usr/share/java/groovy-all-1.8.6.jar:/usr/share/java/commons-lang-2.6.jar:./tools/codegenerator:xbmc/interfaces/python \ ./tools/codegenerator/Generator.groovy xbmc/interfaces/python/generated/AddonModuleXbmc.xml xbmc/interfaces/python/PythonSwig.cpp.template xbmc/interfaces/python/generated/AddonModuleXbmc.cpp xbmc/interfaces/python/generated/doxygenxml [xbmc/interfaces/python/generated/AddonModuleXbmc.xml, xbmc/interfaces/python/PythonSwig.cpp.template, xbmc/interfaces/python/generated/AddonModuleXbmc.cpp, xbmc/interfaces/python/generated/doxygenxml] Caught: groovy.lang.MissingMethodException: No signature of method: java.lang.String.name() is applicable for argument types: () values: [] Possible solutions: take(int), any(), any(groovy.lang.Closure), wait(), size(), next() groovy.lang.MissingMethodException: No signature of method: java.lang.String.name() is applicable for argument types: () values: [] Possible solutions: take(int), any(), any(groovy.lang.Closure), wait(), size(), next() at Helper$_retrieveDocStringFromDoxygen_closure1.doCall(Helper.groovy:109) at Helper.retrieveDocStringFromDoxygen(Helper.groovy:108) at Helper$_transformSwigXml_closure14.doCall(Helper.groovy:484) at Helper.transformSwigXml(Helper.groovy:479) at Helper$transformSwigXml$0.call(Unknown Source) at Generator.run(Generator.groovy:61) make: *** [xbmc/interfaces/python/generated/AddonModuleXbmc.cpp] Error 1 groovy 1.8.6-1 from unstable fails differently: ... groovy -cp /usr/share/java/groovy-all-1.8.6.jar:/usr/share/java/commons-lang-2.6.jar:./tools/codegenerator:xbmc/interfaces/python \ ./tools/codegenerator/Generator.groovy xbmc/interfaces/python/generated/AddonModuleXbmc.xml xbmc/interfaces/python/PythonSwig.cpp.template xbmc/interfaces/python/generated/AddonModuleXbmc.cpp xbmc/interfaces/python/generated/doxygenxml org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: /root/xbmc-12.3+dfsg1/tools/codegenerator/Generator.groovy: 26: unable to resolve class Helper @ line 26, column 1. import Helper ^ 1 error make: *** [xbmc/interfaces/python/generated/AddonModuleXbmc.cpp] Error 1 But it gives less clue about the actual problem. Trying different JREs gives more hint: gij-4.8 -cp /usr/share/java/groovy-all-1.8.6.jar:/usr/share/java/commons-lang-2.6.jar:./tools/codegenerator:xbmc/interfaces/python groovy.ui.GroovyMain ./tools/codegenerator/Generator.groovy xbmc/interfaces/python/generated/AddonModuleXbmc.xml xbmc/interfaces/python/PythonSwig.cpp.template xbmc/interfaces/python/generated/AddonModuleXbmc.cpp xbmc/interfaces/python/generated/doxygenxml java.lang.ExceptionInInitializerError at java.lang.Class.initializeClass(libgcj.so.14) at org.codehaus.groovy.reflection.ReflectionCache.getCachedClass(ReflectionCache.java:107) at org.codehaus.groovy.reflection.ReflectionCache.clinit(ReflectionCache.java:52) at java.lang.Class.initializeClass(libgcj.so.14) at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.registerMethods(MetaClassRegistryImpl.java:161) at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.init(MetaClassRegistryImpl.java:83) at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.init(MetaClassRegistryImpl.java:61) at groovy.lang.GroovySystem.clinit(GroovySystem.java:29) at java.lang.Class.initializeClass(libgcj.so.14) at org.codehaus.groovy.runtime.InvokerHelper.clinit(InvokerHelper.java:49) at java.lang.Class.initializeClass(libgcj.so.14) at groovy.lang.GroovyObjectSupport.init(GroovyObjectSupport.java:32) at groovy.lang.Binding.init(Binding.java:34) at groovy.lang.GroovyShell.init(GroovyShell.java:70) at groovy.ui.GroovyMain.processOnce(GroovyMain.java:544) at groovy.ui.GroovyMain.run(GroovyMain.java:337) at groovy.ui.GroovyMain.process(GroovyMain.java:323) at groovy.ui.GroovyMain.processArgs(GroovyMain.java:120) at groovy.ui.GroovyMain.main(GroovyMain.java:100) Caused by: java.lang.NullPointerException at java.lang.ref.Reference.init(libgcj.so.14) at java.lang.ref.WeakReference.init(libgcj.so.14) at org.codehaus.groovy.reflection.ClassInfo.clinit(ClassInfo.java:413) at java.lang.Class.initializeClass(libgcj.so.14) ...18 more Caught: java.lang.NoClassDefFoundError: org.codehaus.groovy.reflection.ReflectionCache java.lang.NoClassDefFoundError: org.codehaus.groovy.reflection.ReflectionCache No stacktrace available I started working on a fix handling the exceptions somewhere, but now I think caching
Bug#733234: Groovy fails with groovy.lang.MissingMethodException
Hi, On 12/27/2013 04:28 PM, Bálint Réczey wrote: Package: groovy Version: 1.8.6-1 Severity: normal Hi, Using groovy to generate code in XBMC build fails. Steps to reproduce: apt-get -t experimental groovy apt-get build-dep xbmc dget http://http.debian.net/debian/pool/main/x/xbmc/xbmc_12.3+dfsg1-1.dsc # if extraction fails dpkg-source -x xbmc_12.3+dfsg1-1.dsc cd xbmc-12.3+dfsg1/ sed -i 's/groovyc/# groovyc/' codegenerator.mk make -f codegenerator.mk Result: ... groovy 1.8.6-1 from unstable fails differently: ... groovy -cp /usr/share/java/groovy-all-1.8.6.jar:/usr/share/java/commons-lang-2.6.jar:./tools/codegenerator:xbmc/interfaces/python \ ./tools/codegenerator/Generator.groovy xbmc/interfaces/python/generated/AddonModuleXbmc.xml xbmc/interfaces/python/PythonSwig.cpp.template xbmc/interfaces/python/generated/AddonModuleXbmc.cpp xbmc/interfaces/python/generated/doxygenxml org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: /root/xbmc-12.3+dfsg1/tools/codegenerator/Generator.groovy: 26: unable to resolve class Helper @ line 26, column 1. import Helper ^ 1 error make: *** [xbmc/interfaces/python/generated/AddonModuleXbmc.cpp] Error 1 Based on suggestion at http://trac.xbmc.org/ticket/13394 I tried removing the '+' sign from the directory name and it solved the problem for 1.8.6, but not for 2.2.1. Cheers, Balint signature.asc Description: OpenPGP digital signature
