Bug#745815: libjarjar-java: generate jars with invalid information
On Sun, May 25, 2014 at 01:11:39PM +0200, Damien Raude-Morvan wrote: > Hi Miguel, hi Emmanuel ! > > Sorry to come back to you so late... Hi Damien, No problem. I'm also very slow with my email lately. > I've cherry-picked this patch after having issues with some maven plugins > but you're right it might introduce more issues than it solved. > They were repacking themself using jarjar but it won't update references in > META-INF/plexus/components.xml. > > > Maybe recent releases of Gradle might not needed this tricks anymore. I believe this is not needed anymore so I disabled it. Otherwise, jarjar was causing Groovy broken builds. I'll keep an eye on Gradle as usual but I think this should not be an issue anymore. Cheers, PS. Guys, are you planning to attend DebConf14? -- 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#745815: libjarjar-java: generate jars with invalid information
Hi Miguel, hi Emmanuel ! Sorry to come back to you so late... 2014-05-03 19:50 GMT+02:00 Miguel Landaeta : > On Sat, May 03, 2014 at 07:30:20PM +0200, Emmanuel Bourg wrote: > > Le 03/05/2014 18:41, Miguel Landaeta a écrit : > > > > > Well, the bug was not introduced by upstream as I thought. > > > I can only reproduce this bug when patch szzepiq_jar_resources.diff is > applied. > > > When I remove that patch, jarjar works OK for me. > > > > Interesting, the question is to know what issue this patch fixed. There > > is no mention of a bug in the changelog. > > > > However, the patch itself contains these headers: > > Description: Create patch from fork at https://github.com/szczepiq/jarjar>. > which resolve the issue with jarjar not updating the fully qualified > class names > in the jar's resources. > For instance, with this patch jarjar is able to replace classname (based > on requested > rules) in META-INF/plexus/components.xml files. > Source: https://github.com/szczepiq/jarjar > Author: Szczepan Faber > Author: Damien Raude-Morvan > Last-Update: 2013-01-08 > > Damien, do you remember what issue fixed this patch in jarjar package? > > I think there is a serious issue with this patch. Any file not > matching .class, .java or MANIFEST.MF ends being treated like a text > file so it ends modifying .groovy, .png, .properties, anything under > META-INF, etc. I've cherry-picked this patch after having issues with some maven plugins but you're right it might introduce more issues than it solved. They were repacking themself using jarjar but it won't update references in META-INF/plexus/components.xml. As you can see from Gradle debian/changelog : gradle (1.4-1) unstable; urgency=low * d/control: Build-Depends on libjarjar-java (>= 1.4+svn142-1) to build Gradle with jarjar which handle correctly updating the fully qualified class names in the jar's resources. Otherwise, we get errors during plexus startup. Maybe recent releases of Gradle might not needed this tricks anymore. Cheers, -- Damien - Debian Developper http://wiki.debian.org/DamienRaudeMorvan
Bug#745815: libjarjar-java: generate jars with invalid information
On Sat, May 03, 2014 at 02:50:29PM -0300, Miguel Landaeta wrote: > > Any opinion about disabling this? I'm uploading a new release of jarjar disabling the problematic patch. I rebuilt all its reverse dependencies and everything builds without issues. If that patch is really needed please file a new bug report to review that 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#745815: libjarjar-java: generate jars with invalid information
On Sat, May 03, 2014 at 07:30:20PM +0200, Emmanuel Bourg wrote: > Le 03/05/2014 18:41, Miguel Landaeta a écrit : > > > Well, the bug was not introduced by upstream as I thought. > > I can only reproduce this bug when patch szzepiq_jar_resources.diff is > > applied. > > When I remove that patch, jarjar works OK for me. > > Interesting, the question is to know what issue this patch fixed. There > is no mention of a bug in the changelog. > However, the patch itself contains these headers: Description: Create patch from fork at https://github.com/szczepiq/jarjar>. which resolve the issue with jarjar not updating the fully qualified class names in the jar's resources. For instance, with this patch jarjar is able to replace classname (based on requested rules) in META-INF/plexus/components.xml files. Source: https://github.com/szczepiq/jarjar Author: Szczepan Faber Author: Damien Raude-Morvan Last-Update: 2013-01-08 Damien, do you remember what issue fixed this patch in jarjar package? I think there is a serious issue with this patch. Any file not matching .class, .java or MANIFEST.MF ends being treated like a text file so it ends modifying .groovy, .png, .properties, anything under META-INF, etc. This looks broken to me and this was not accepted at upstream anyway. Upstream is very inactive nowadays but still. Any opinion about disabling this? -- 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#745815: libjarjar-java: generate jars with invalid information
Le 03/05/2014 18:41, Miguel Landaeta a écrit : > Well, the bug was not introduced by upstream as I thought. > I can only reproduce this bug when patch szzepiq_jar_resources.diff is > applied. > When I remove that patch, jarjar works OK for me. Interesting, the question is to know what issue this patch fixed. There is no mention of a bug in the changelog. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745815: libjarjar-java: generate jars with invalid information
On Fri, May 02, 2014 at 06:35:25PM -0300, Miguel Landaeta wrote: > > So, I guess to fix this I'll have to check all the commits since > jarjar 1.1 to determine which is the breaking change. Well, the bug was not introduced by upstream as I thought. I can only reproduce this bug when patch szzepiq_jar_resources.diff is applied. When I remove that patch, jarjar works OK for me. -- 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#745815: libjarjar-java: generate jars with invalid information
owner 745815 ! thanks miguel@nina:~/packages/groovy/bug/groovy-1.8.6$ dpkg-query -l groovy | grep ^ii ii groovy 1.8.6-3~miguel1 all Agile dynamic language for the Java Virtual Machine miguel@nina:~/packages/groovy/bug/groovy-1.8.6$ dpkg-query -l libjarjar-java | grep ^ii ii libjarjar-java 1.1-4~miguel1 all repackage third-party jars miguel@nina:~/packages/groovy/bug/groovy-1.8.6$ groovy -cp "/usr/share/java/groovy-all-1.8.6.jar" -e 'println 1' 1 I'm taking ownership of this bug. To debug this, I rebuilt jarjar 1.1 in unstable and I used that package to rebuild groovy 1.8.6 and groovy-all.jar was correctly generated. So, I guess to fix this I'll have to check all the commits since jarjar 1.1 to determine which is the breaking change. -- 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#745815: libjarjar-java: generate jars with invalid information
On Fri, Apr 25, 2014 at 04:10:25PM +0200, Emmanuel Bourg wrote: > I compared the dgminfo files from groovy-all.jar in stable and unstable, > in unstable the 0x0D bytes have been replaced by 0x0A. It looks like the > file was erroneously processed as a text file and the line terminators > were transformed. > > I fail to see what change in jarjar 1.4 caused this though. Thanks for the info Emmanuel. I'm also trying to review the changes and see if/how I can make jarjar function like it did 1.1 for groovy. I thought I could work around this in gradle by using groovy jar instead of groovy-all one but this doesn't work because that tool depends closely on -all.jar. -- 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#745815: libjarjar-java: generate jars with invalid information
I compared the dgminfo files from groovy-all.jar in stable and unstable, in unstable the 0x0D bytes have been replaced by 0x0A. It looks like the file was erroneously processed as a text file and the line terminators were transformed. I fail to see what change in jarjar 1.4 caused this though. 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#745815: libjarjar-java: generate jars with invalid information
Package: libjarjar-java Version: 1.4+svn142-1 Severity: important groovy package generates two jar files during build time and one of them (groovy-all.jar) is manipulated with libjarjar-java during its creation. This worked OK until 1.1-3 but stopped working on 1.4+svn142-1 with the inclusion of libasm4-java among libjarjar-java dependencies. Example: miguel@nina:~/packages/groovy$ groovy -cp "/usr/share/java/groovy-all-1.8.6.jar" -e 'println 1' java.lang.OutOfMemoryError: Java heap space at java.util.ArrayList.(ArrayList.java:144) at org.codehaus.groovy.reflection.GeneratedMetaMethod$DgmMethodRecord.loadDgmInfo(GeneratedMetaMethod.java:193) at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.registerMethods(MetaClassRegistryImpl.java:155) at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.(MetaClassRegistryImpl.java:83) at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.(MetaClassRegistryImpl.java:61) at groovy.lang.GroovySystem.(GroovySystem.java:29) at org.codehaus.groovy.runtime.InvokerHelper.(InvokerHelper.java:49) at groovy.lang.GroovyObjectSupport.(GroovyObjectSupport.java:32) at groovy.lang.Binding.(Binding.java:34) at groovy.lang.GroovyShell.(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) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:108) at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:130) 1 I also took a look at groovy source code on that file GeneratedMetaMethod.java at line 193 and I found this call: List res = new ArrayList(size); On normal circumstances 'size' variable contains the size of dgminfo (jar:file:/usr/share/java//groovy-all-1.8.6.jar!/META-INF/dgminfo) contained on the groovy jar file and we are talking about 1072 elements. However when groovy-all.jar is generated with recent libjarjar-java versions, the .jar contains invalid information and 'size' variable ends with an insanely high value, ending with a memory error and triggering the described error, e.g.: List res = new ArrayList(570428522); If I find more information I'll post it here, in the meantime, as workaround I had to avoid any usage on groovy-all.jar if possible. -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-0.bpo.1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash -- 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
