Steve Loughran wrote: > The thing to remember about WAR files is that they are a packaging > format that is intended to make it easy to deploy web apps. Not > distribute, but deploy. The old WAR/EAR use cases always had the > 'assembler' who would be some person who would somehow assemble WARs > and EJB beans to make a working app, presumably through some GUI that > required the same work to be repeated every release. > > If you are doing lots of late binding tuning to the WAR file, then > perhaps build time is the wrong place to do it; it should really be > done as part of the deployment process, where per machine > optimisations can go in. In this world what you want from the outset > is the exploded WAR, which is then taken with server-specific options > to create the target WAR for the target system. It's not late binding tuning with custom parameters. For example the cocoon plugin was ment to unpack and write some configuration files in the WAR, configuration files which are not bindings to external servers, but settings for the internal servlets. In that case, it is a build problem, and not a configuration one. Also, the web.xml often contains directives which are "configuration" in the strict sense (like various init parameters), but also contains all the assembly informations of a web application, being unable to write plugins that can manipulate these file in the build phase is, IMMO, a problem.
Simone --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
