[cosmo-dev] r6735 plus important note for JS dev!

[Travis Vachon]

Hi folks

I landed the dojo 1.0 branch this morning and will begin trunk testing  
in anticipation of branching and releasing in a week or so.

r6735, the merge commit, was too large to show up on the commits list  
so I wanted to copy the commit message here:

Merge dojo 1.0 branch to trunk.

This change carries with it numerous changes to both our javascript  
code and build
processes. While most of the code changes have been documented at least
minimally in commit messages, one of the most noticable differences to
developers will be the location that we grab code from by default.

When running with djConfig.isDebug == false, the web app now
grabs JS source files from js/lib/dojo/cosmo. This is a result
of differences in the dojo build process, and is advantageous in some  
ways, mostly
related to stability. This means, however, that changes made in the  
local
source tree WILL NOT BE SEEN in the web application when running outside
of debug mode.

This is easily fixed by setting isDebug to true in

cosmo/src/main/webapp/WEB-INF/tags/dojoBoilerplate.tag on line 48.

A couple of useful aliases for dealing with this look like:

alias debug_js="cd $COSMO_HOME/cosmo/active/cosmo/src/main/webapp/WEB- 
INF/tags; sed -e 's/isDebug: false/isDebug: true/' dojoBoilerplate.tag  
 > tmp; mv tmp dojoBoilerplate.tag; cd -"
alias undebug_js="cd $COSMO_HOME/cosmo/active/cosmo/src/main/webapp/ 
WEB-INF/tags; sed -e 's/isDebug: true/isDebug: false/'  
dojoBoilerplate.tag > tmp; mv tmp dojoBoilerplate.tag; cd -"

We should probably think about treating dojoBoilerplate.tag as a build  
resource that
can be filtered depending maven variables to support developers  
leaving isDebug: true on
at all times (instead of switching it off to commit).


The note about djConfig.isDebug is very important for Javascript  
developers, as it will seem impossible to edit the javascript when not  
in debug mode. I'm going to take a second look at the build process in  
the next week to see if we can rationalize this a little more, and  
comments and suggestions are welcome. I've found that once the two  
aliases I mention are in place, dev is not significantly more painful  
than it was before, so unless there's either major discord or an easy  
improvement I'll probably leave things the way they are. I'll deploy  
trunk JS periodically, but the important takeaway is that unless you  
perform a local Dojo build, by default you'll be running with non- 
trunk javascript unless a developer has deployed a Dojo jar for the  
current revision.

-Travis