I believe that this should be mentioned on Mojo site instead of mailing list in order to prevent future confusions and emails about this.
On Thu, Nov 3, 2011 at 15:38, Christopher Hunt <[email protected]>wrote: > 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/ -- Best regards, Evgeny Mandrikov aka Godin <http://godin.net.ru> http://twitter.com/_godin_
