During the review to update processing 3 to JogAmp 2.3.2 it came to our attention that the src zip have grown a lot in size. https://github.com/processing/processing/issues/3979 Starting with JogAmp 2.3.2 we provide a "fat" jar, that is an all in one jar deployment option including all jogamp modules, with matching src zip. The source zip for the "fat" jar deployment option is "only" 5.8Mb containing the sources for all jogamp modules. http://jogamp.org/deployment/jogamp-current/fat/ jogamp-fat-java-src.zip 10-Oct-2015 05:02 5.8M However the source zip found inside the "slim" deployment option is much larger >25Mb! http://jogamp.org/deployment/jogamp-current/archive/jogamp-all-platforms.7z 4,0M gluegen-java-src.zip 76K joal-java-src.zip 196K jocl-java-src.zip 24M jogl-java-src.zip We need to look into it and check why the two deployment options "slim" vs "fat" source zip's differ that much in size. It is expected that the size of the sum of the "slim" src zips sizes to match the "fat" src zip size. +++ The fat jars src zip is also larger than expected a quick review of its contents reveal that 3Mb of the "fat" src zip is made up by bundling the ubuntu fonts inside the src zip. jogamp/graph/font/fonts/ubuntu/Ubuntu-*.ttf
Invalid criteria/metric, only LOC would be sufficient and only iff there is no duplication or intentional 'take out'.
I continue my rant here: Further more, the defect claim is not visible in the title of description. Wording like 'have grown lot in size' is too fuzzy -> LOC Wording 'differ' is also little qualifying and could be refined, since it forces one to _find_ a statement in the text. Note: A proper per module LOC analysis as well as a possible binary location should be performed. I did that for Fosdem 2013 I guess. Having above information, maybe there can be done a statement, whether a bug or of informal notion.
Unpacking the "slim" and "fat" src zip's reveal that they do contain the same files and have the same unpacked footprint. du -s -h slim/ 32M slim/ du -s -h fat/ 32M fat/ Conclusion: the jogamp-fat-java-src.zip have much better compression! Question: why is the compression of the "slim" zip's that bad?
The answer why the compression level of the "slim" src zips are bad is because we pass level=0 to ant when we create the "slim" zip's. Gluegen and JOGL uses level=0 compression http://jogamp.org/git/?p=gluegen.git;a=blob;f=make/build.xml;hb=HEAD#l1094 http://jogamp.org/git/?p=jogl.git;a=blob;f=make/build.xml;hb=HEAD#l267 JOAL and JOCL uses default compression http://jogamp.org/git/?p=joal.git;a=blob;f=make/build.xml;hb=HEAD#l811 http://jogamp.org/git/?p=jocl.git;a=blob;f=make/build.xml;hb=HEAD#l899 https://ant.apache.org/manual/Tasks/zip.html "level Non-default level at which file compression should be performed. Valid values range from 0 (no compression/fastest) to 9 (maximum compression/slowest)." The "fat" src zip is created by unpacking the four "slim" src zip's and creating a new zip using the zip commands default compression. http://jogamp.org/git/?p=jogamp-scripting.git;a=blob;f=jenkins-builds/funcs_promotion.sh;h=3896acbb4c8ff61baeef6a82cdb4ff545431badb;hb=HEAD#l294 Conclusion the difference in src zip sizes are caused by the compression level selected during creation of the "slim" src zip's.
The reason we pass level=0 is to allow 7z to archive better compression when build the final jogamp-all-platforms.7z file http://jogamp.org/git/?p=gluegen.git;a=commit;h=1d614e360b2018c7f4b70ebf2c9322cae5cc9c7f Thus it is expected that the src-zip's inside the "slim" jogamp-all-platforms.7z archive to be larger compared to the "fat" deployment option src zip.