Brett Porter wrote:
Vincent Massol wrote:
* support storing in the project the container's configuration files
- for weblogic that's the domain config
- for jboss that's the server config
- for tomcat that's server.xml, tomcat-users.xml, etc
I usually put this in a separate module (which I think agrees with
this), or omit it altogether opting to set it up manually for the target
environment or use defaults for testing (where the config for each
webapp would go in src/deployment/tomcat-5/context.xml for example). I
know this doesn't work for all of the servers though.
* support building for different target environments
- support container-specific deployment descriptor for example
- support container config files that depend on the environment. For
example you may want to run on port 8080 in your dev env and on port
80 in
your production env. You may want to run on a single server in the dev
env
but in cluster on the production env, etc.
I think at least at this point configuration management is out of scope
for Maven. We could use archetypes or similar to generate appropriate
config files, but in general I've found the differences go beyond
templating and its best to have a general versioning and deployment
mechanism for your server setup.
I have to agree.
I actually work full time on complex system deployment, of which the
core runtime. SmartFrog, is LGPL-licensed and sourceforge hosted
(http://smartfrog.org/). If you want to know more, the latest slides are
http://people.apache.org/~stevel/slides/oscon.pdf
Key things about configuring production systems are that
-you have many systems, all slightly different
-ops dont always let engineering near them
-every part of a system needs to be configured consistently, and their
start/stop choreographed properly
Maven, like ant is a build tool. Its used by developers; not
operations. Its certainly something that can
-take configuration hints from developers
-populates deployment descriptors from this data. e.g. libraries &
versions used at build times
However, it cannot be the tool used by operations, and should not try to
do this. its a different problem, arguably a more complex one.
Generating stub web.xml, ear.xml config files is something that build
tools (and xdoclet) try and do. But there the problem is really that a
build time artifact (the WAR and EAR file) also contains late-binding,
often cluster-specific, configuration data alongside static stuff like
the names of servlets.
- support different deployment models per environment. For example
in one
environment you may want to have the web server and EJB server on the
same
machine and in another environment you may want them located on 2
different
machines.
That is exactly the kind of stuff we can do in smartfrog. If you want to
do the maven/maven2 plugin, I will help you test it.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
