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
