2011/11/3 Evgeny Mandrikov <[email protected]>: > Could someone explain what's the difference > between http://mojo.codehaus.org/webminifier-maven-plugin/ and > http://alchim.sourceforge.net/yuicompressor-maven-plugin/ ? > Seems that they both rely on YUI Compressor.
and... On 03/11/2011, at 3:03 AM, Olivier Lamy wrote: > and with this one > http://svn.codehaus.org/mojo/trunk/sandbox/javascript-maven-tools/javascript-compressor/ Disclosure: I'm the author of JS Import, JSLint Maven Plugin, Webminifer and JS Test Runner. I see the largest point of difference in being the factoring out of specific functionality into one plugin i.e. the yuicompressor-maven-plugin does more than just compression - it offers a jslint goal as well. I created a separate jslint-maven-plugin for that. Each JS plugin I've written can be used in isolation. Another yet smaller difference is that Webminifier is agnostic to the type of compressor and supports the YUI Compressor and Google's Closure compiler presently (favouring the latter by default given its exceptional compression). The compressor that's part of the javascript-maven-tools project is also part of a larger project. Again, I'm looking at smaller plugins that can be executed in isolation from the rest. I believe the developer should be able to choose which plugin should be used within the Maven lifecycle; just as you can do for Java development. Another important difference is the assumption made on how js projects are laid out. The world I'm focused on is a JS centric one where html and css are resources to JS, and not the other way round as has been typical. In being consistent with Java development, src/main/js files ultimately end up in classes/js by convention and may or may not be packaged as a war file (that's up to the assembly plugin). The following plugins are now following this convention by default: - JS Import Plugin (1) - JSLint Maven Plugin (2) - Webminifier (3) - JS Test Runner (4) I'm also going to be producing an umbrella plugin that will provide a "js" packaging so that the above are bound by convention along with the appropriate resource copying. In a nutshell, your entire project ends up in target/classes and target/min/classes; the latter being for the minified version. target/test-classes also exists for test resources. Jetty will also be configured by default to serve classes and test-classes up under the same context; thus facilitating testing and debugging. I'm thinking of a proposal around the sandbox/javascript-maven-tools such that the plugins are removed from it and this becomes a loosely coupled umbrella project that includes only the packaging plugin. I think that this would remove some of the confusion here and be a great starting point for those wishing to use Maven for JS development. sandbox/javascript-maven-tools has some nice documentation and it already offers a packaging plugin that may be leveraged. 'hope that this provides a little foresight into the strategy that I've been working toward for the last year or two. Kind regards, Christopher (1) http://mojo.codehaus.org/js-import-plugin/ (2) http://mojo.codehaus.org/jslint-maven-plugin/index.html (3) http://mojo.codehaus.org/webminifier-maven-plugin/index.html (4) http://js-testrunner.codehaus.org/ --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
