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
- option 2 : use js packaged into a jar, and a custom plugin to unpack.
js:inplace to unpack into src/main/webapp, prior to lauching jetty:run
js:unpack to unpack during the package phase.
Option 2 is the preferred way for me, mostly because WAR overlaying can
only help with, well, web apps.
I'm working on that along with a ServletFilter that can be used as a
dependency (maybe war overlay?) in web projects. I'm not through with
the details though and was going to ask here for suggestions.
So, a very rough outline:
- Provide JS packaging of projects as JAR artifacts
- Provide a library that can be used as a dependency by web apps. The
lib contains, basically, a Servlet Filter listening to *.js and
builds/caches the HTTP response after pulling and maybe compressing the
JS code from the classpath
- Provide something equally useful for non-webapp projects
Some questions:
- What kind of metadata would be useful in what one would consider as
the standard way to package JS-based JAR artifacts?
- What kind of metadata would be useful for libs utilizing that packaging?
- Can WAR overlaying be used to bring that Servlet Filter in a web-app,
along with the appropriate web.xml markup?
There more details but that gives the general idea. I have not yet
formed an opinion on how useful knowledge on JS dependencies (i.e.
script1.js was requested but the client has not received a dependency,
sript2.js yet) is on runtime.
WDYT?
Many thanks,
Manos
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
