What would be the better way to package JS libs ?
- option 1 : use existing WAR packaging with war overlay
good : Works today with no change, just requires us to agree on a
common folder for scripts
bad : cannot be used with jetty:run as the weapp is not packaged
- option 2 : use js
nicolas de loof wrote:
What would be the better way to package JS libs ?
- option 1 : use existing WAR packaging with war overlay
good : Works today with no change, just requires us to agree on a
common folder for scripts
bad : cannot be used with jetty:run as the weapp is not packaged
-
I agree with the js packaging.
It works fine for js libs like prototype that is build based on
multiple JS but pakcage as a single file.
It works less with scriptaculous, dojo or yahooUI that comes with
multiple JS with a internal JS-level dependency loading strategy. For
those one, this would
I started tinkering with the war overlay method just a few days ago, so I
may be missing some things. But so far it seems like a flexible enough
solution that it would be a good way to go.
I like it because:
* can use it today
* flexibility to put resources anywhere in the app one might need
*
This is definitely I'm struggling with at the moment:
We have 2 artefacts for each js module:
1) one compressed module.js file
2) the source in multiple files, containing a module.js that
document.writes out script tags for each file. This is used for
debugging.
Currently I package with a zip
I myself like the war overlay idea as this allow not just JS to be
packaged, but also any static resources, like css stylesheets :
consider webapp skins, maanged as separate projects, and applied to
all apps in a company !
BUT I don't like that it cannot be used with lightweight servlet
engine