Vincent Massol wrote:
-----Original Message-----
From: Steve Loughran [mailto:[EMAIL PROTECTED]
Sent: lundi 24 octobre 2005 12:52
To: Maven Developers List
Subject: Re: [M2][Proposal] J2EE builds best practices and conventions
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
Cool. I'll be reading this and checking out the smartfrog project. More
specifically I need to find out if the open source part of smartfrog is
enough to satisfy the needs for deploying a J2EE system or if it requires
people to buy additional things.
to be honest, right now, there is no direct support in our code for
jboss or geronimo. I tried to persuade the geronimo people last week
that they need to think about it. But there is
-JMX control
-war deploy to jetty+tomcat
-a jboss component from Brazil to do
Ear support is on my todo list, Jboss being the obvious target. The goal
is to decouple configuring the app from the server, so you can switch
from app server provider just by changing an option in a deployment
descriptor and redeploying -or better yet, creating a new descriptor
that extends a base one for use on a different cluster. That todo list
is budy with core work related stuff, which is primarily dull Ws-* and
grid related things.
NB, there is no business model of paid-for-premium things. We are part
of a research lab. Once you have automated deployment to the extent that
you need 10 boxes + the option of 500 more for peak loads, then you have
the option of talking to the bit of HP that sells CPU time on demand.
But that is merely an option.
Incidentally, on the subject of testing, Vmware are now giving away free
vmware runtimes. This lets you test more deployments on a single host,
so even the developers can have multi-server deployments on their
laptops. slick.
That said, it seems to me that there are maybe different levels:
- the poor man's solution which could be implemented using Maven. Again this
is what I've done at several places and I know several others who have done
the same successfully. I'm not saying this is the best, I'm just saying that
it can work in some circumstances.
Oh I agree, it works just like shell scripts and ant or custom RPMs. The
problem is that you cannot easily transfer all the configuraton work
into a production system, so the only thing that gets carried over from
dev to staging to live systems is experience in debugging configuration
problems.
Even small projects have repeated and different deployments. It just
doesnt hurt as much doing it by hand as it does on large scale 100+node
systems, where manual intervention is clearly impossible.
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
