iirc there are some issues with the Apache license in GPLv2. GPLv3 however is fine with the Apache license.
As for dropping JSMin... I never really liked Crockford anyways, nor JSMin... so I don't really have any problem. I also don't like the idea of maintaining what's essentially a local fork from the upstream, so if this is a performance improvement and eliminates the need to fork something to get it to do what we want... perfect. Personally I always had a preference towards YUI's minifier. I haven't quite jumped onto closure just yet... in the early days I wasn't sure about trusting it to not introduce edge cases into code (since it basically does some rewriting of code above what other minifiers do and I wasn't sure about it's implementation. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] On 11-01-20 06:57 PM, Michael Dale wrote: > As mentioned in the bug, it would be nice to have configurable support > for the closure-compiler as well ;) ( I assume Apache licence is > compatible? ) > > Has anyone done any tests to see if there are any compatibility issues > with SIMPLE_OPTIMIZATIONS with a google closure minification hook? > > --michael > > On 01/20/2011 04:13 PM, Trevor Parscal wrote: >> For those of you who didn't see bug 26791, our use of JSMin has been >> found to conflict with our GPL license. After assessing other options ( >> https://bugzilla.wikimedia.org/show_bug.cgi?id=26791#c8 ) Roan and I >> decided to try and use the minification from JavaScriptPacker, but not >> its overly clever but generally useless packing techniques. The result >> is a minifier that outperforms our current minifier in both how quickly >> it can minify data and how small the minified output is. >> JavaScriptDistiller, as I sort of randomly named it, minifies JavaScript >> code at about 2x the speed of Tim's optimized version of JSMin, and 4x >> the speed of the next fastest PHP port of JSMin (which is generally >> considered the standard distribution). >> >> Similar to Tim's modified version of JSMin, we chose to retain vertical >> whitespace by default. However we chose not to retain multiple >> consecutive empty new lines, which are primarily seen where a large >> comment block has been removed. We feel there is merit to the argument >> that appx. 1% bloat is a reasonable price to pay for making it easier to >> read production code, since leaving each statement on a line by itself >> improves readability and users will be more likely to be able to report >> problems that are actionable. We do not however find the preservation of >> line numbers of any value, since in production mode most requests are >> for many modules which are concatenated, making line numbers for most of >> the code useless anyways. >> >> This is a breakdown based on "ext.vector.simpleSearch" >> >> * 3217 bytes (1300 compressed) >> * 2178 bytes (944) after running it through the version of JSMin that >> was in our repository. Tim modified JSMin to be faster and preserve line >> numbers by leaving behind all vertical whitespace. >> * 2160 bytes (938 compressed) after running it through >> JavaScriptDistiller, which applies aggressive horizontal minification >> plus collapsing multiple consecutive new lines into a single new line. >> * 2077 bytes (923 compressed) after running it through >> JavaScriptDistiller with the vertical space option set to true, which >> applies aggressive horizontal minification as well as some basic >> vertical minification. This option is activated through >> $wgResourceLoaderMinifyJSVerticalSpace, which is false by default. >> >> The code was committed in r80656. >> >> - Trevor (and Roan) >> >> >> _______________________________________________ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
