Reinhard Poetz wrote:
Von: Carsten Ziegeler <[EMAIL PROTECTED]>
Yes, true. What about extending the deployer (or creating another
plugin) which by default rewrites the web.xml and adds all required
wrappers (paranoid servlet etc.) and also moves the jars to a different
directory? With a plugin-configuration this can be turned off.
(We don't need this for b1)
At the weekend I was thinking about this and using different locations for lib and
classes and extending the existing functionality of the maven-war-plugin can be achieved
by renaming them after the "original" methods have been called. That's easy :-)
Having a configuration that can turn on/off the support for paranoid
classloading is the way to go. The default value is, as proposed by Carsten,
true and then the deployer checks whether all necessary configurations in
web.xml are set correctly or if not set it adds them.
I don't think that we have to (and should) provide any patching functionality
to the deployer as people are in control of the content of WEB-INF and its
subdirectories. If they add some file there which has the same name as a file
in one of the blocks, it overrides the original version. The only thing that we
should do is splitting up our configuration files in smaller chunks so that we
get one configuration file for one component so that people get fine-grained
control.
One additional thought:
Maven 2 has the concept of profiles. Profiles make it possible to customize the
build process and that's what we need to provide configurations for different
environments.
Suppose you have two environments: development (dev) and production (prod). If
you create the web application, you might need different .xconf (database
connections, root sitemap, ...) values and different properties.
In your src/main/webapp directory, you have for example
src/main/webapp/WEB-INF/xconf/cocoon-sitemap.xconf
src/main/webapp/WEB-INF/properties/core.properties
I propose that we have a directory "src/main/webapp-profiles" that contains all
files for different profiles:
src/main/webapp-profiles/dev/WEB-INF/xconf/cocoon-sitemap.xconf
src/main/webapp-profiles/prod/WEB-INF/conf/cocoon-sitemap.xconf
src/main/wenbapp-profiles/dev/WEB-INF/properties/core.properties
src/main/wenbapp-profiles/prod/WEB-INF/properties/core.properties
This way we can create environment specific web applications by calling
"mvn cocoon:deploy -P dev" or "mvn cocoon:deploy -P dev,prod"
As mentioned in my previous message, this make it necessary to split up
cocoon.core in small chunks (every component get's its own configuration file)
so that the override mechanism works smoothly.
WDYT?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
