Re: recommandation for JS packaging ? (was Using maven for JavaScript projects)
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]
Re: recommandation for JS packaging ? (was Using maven for JavaScript projects)
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 require one artifact per js file, and maybe a parent POM to declare all of them as dependencies. I'm writing a js:inplace Mojo based on this idea. Nico. 2007/9/28, Richard Chamberlain [EMAIL PROTECTED]: 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 and a task to unzip when retrieved. I'd be interested if this could be made neater. One option (touched on before on this list) is to only ever produce a single .js file for each module and have js packaging. Unfortunately there would still need to be a copy task to move it from your local repository under your web context. Cheers, Rich -Original Message- From: nicolas de loof [mailto:[EMAIL PROTECTED] Sent: 28 September 2007 15:10 To: Maven Users List Subject: recommandation for JS packaging ? (was Using maven for JavaScript projects) 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. - other ? Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: recommandation for JS packaging ? (was Using maven for JavaScript projects)
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 * there needs to be an accepted convention, as you say, which may be an argument for custom packaging plug-in * solution could be a 'scriptDirectory' or similar attribute in war plugin configuration. * webapp and script artifact can use the same testing tools (jsunit, selenium, etc) without duplicating effort. The first is important for me because I have software that I want to ship. The second is important because there are lots of use cases to take into consideration for packaging. What if somebody wants resources outside of their script directory? That may not be accepted for a general purpose script artifact, but I can see that being a common want for in-house or application-specific artifacts. What if somebody wants a servlet that goes with their script, with configuration? I suppose they could put it into a separate artifact (I'm not completely familiar with best practice for that sort of thing), but I can see times when that would be annoying. The third is the biggest win for war packaging, IMO. With the war plugin, it's only a matter of making conventions, not thinking out logistics of what the packaging should do. It would also allow normal web artifact to take advantage of any testing tools such as jsunit or selenium in the same way as a script artifact would. There are some cons to it too though: * Must use 'test' scope for dependencies to be available when jsunit is run (or 'provided' works when there are no tests); either of these packs the dependencies into the final war. But if you use 'runtime', all dependencies are packed into the dependent artifact. This could be a win for custom packaging. * Burden is on plug-in developers to follow whatever convention is schemed up. To sum it up, I think a balanced solution would be to add a 'scriptDirectory' or similar attribute to the war plugin, with a sensible default like src/main/webapp/scripts, which any script library such as jsunit or yuicompressor could use. It would save effort of developing the packaging, and it would save effort for plugin developers like selenium and jsunit from having to support two different packagings. Harlan On 9/28/07, nicolas de loof [EMAIL PROTECTED] 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. - other ? Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Harlan Iverson http://blog.devspan.com
RE: recommandation for JS packaging ? (was Using maven for JavaScript projects)
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 and a task to unzip when retrieved. I'd be interested if this could be made neater. One option (touched on before on this list) is to only ever produce a single .js file for each module and have js packaging. Unfortunately there would still need to be a copy task to move it from your local repository under your web context. Cheers, Rich -Original Message- From: nicolas de loof [mailto:[EMAIL PROTECTED] Sent: 28 September 2007 15:10 To: Maven Users List Subject: recommandation for JS packaging ? (was Using maven for JavaScript projects) 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. - other ? Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: recommandation for JS packaging ? (was Using maven for JavaScript projects)
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 jetty using the jetty:run goal... Nico. 2007/9/28, Manos Batsis [EMAIL PROTECTED]: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
