splitting out the UI stuff from JSPWiki war?

[Glen Mazza]

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