That would be fine, providing it doesn't overly affect those hacking the
wro4j stuff (I'm not personally working with it, and don't expect to for
a while.) I'm not sure there's much with wro4j left to be
coded/configured, so that shouldn't be a problem anyway. Only issue is
that our local builds will no longer use the minimized stuff, OK with me
but may bring up differences between release and what we've tested with.
Glen
On 11/10/2013 04:35 PM, Juan Pablo Santos RodrÃguez wrote:
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
