Hi Glenn, another solution could be moving the wro4j plugin into the apache-release profile, so the minimizing stuff would only get done when we're about to release. WDYT?
br, juan pablo On Sun, Nov 10, 2013 at 9:49 PM, Glen Mazza <glen.ma...@gmail.com> wrote: > Hi Team, presently whenever building JSPWiki via "mvn clean install" or > even running a single JUnit test via "mvn test -Dtest=xxxx" I lose about > 20-25 seconds compiling and compressing the JavaScript stuff (jslint and > wro4j and seeing the output of the various mootools errors), code which I'm > never touching or altering. It's an annoying time tax to keep paying with > each build. > > I'd like to split out the jslint and wro4j processes into a separate Maven > module, something I need to compile once and I'm done, leaving my build > time just to the compilation of the Java code and building of a new WAR. > (This is assuming no one knows how to make an "mvn install" work without > firing up the wro4j/jslint stuff every time.) I see two options: > > 1.) We could do jspwiki-jar and jspwiki-war, with the Java code in the > former and the CSS/JS stuff in the latter, that would partially fix the > problem in that unit tests run from the jspwiki-jar submodule would no > longer trigger the WRO4J stuff (although regular WAR builds would always > trigger it). This is preferred if most changes are UI and not Java (as you > can now build the WAR without needing to recompile the JAR each time), but > I think most of our changes will be Java-related, and testing and > prototyping of CSS/JavaScript stuff generally doesn't require as many > builds because hot deployment via tomcat:run allows people to work on > CSS/JS stuff without recompilation. > > 2.) We can also do WAR overlays, in which we have jspwiki-ui WAR > containing the CSS/JS stuff and a jspwiki-war WAR containing the Java code, > with the former being absorbed into the latter, similar to what we already > do with our integration tests. This would allow us to create WARs from the > jspwiki-war folder without needing to rebuild JSPWiki-UI each time. This > is not as intuitive as (1) and would need additional checking to confirm it > works but best for rapid deployment of WARs during Java debugging without > needing to fire up the wro4j stuff each time. However, I am unsure whether > hot deployment of CSS/JS stuff would work with this configuration. > > I have a preference for (2) right now, possibly switching to (1) later, > but either is an improvement. Thoughts? > > Thanks, > Glen > >
