Vincent Massol wrote:
I've used Maven in the past to do that and it worked very well. I'd like to
understand better what alternatives you're suggesting?
Note for versioning: we have that by storing the config in the SCM.
I'm curious to know which tool you're using in the J2EE space for doing
"versioning and deployment". I don't know any.
My point was similar to Steve's. Yes, we can provide tools to help, but
I don't see us coming up with the grand unified theory of configuration
management. We used to store our configs in SCM and have some simple
server side tools (that a deployer could use, as developers certainly
weren't getting up in the middle of the night for releases :)
* support deploying config and J2EE modules to a container
Cargo, right?
Yes and no. Cargo does this for sure. However I'm still pondering whether
it's interesting to bring Cargo to the runtime vs storing shell scripts.
Cargo could be used to generate the config at build time. Now for run time
we could also bring it by having a cargo-execution.jar for example (java
-jar cargo-execution.jar start cargo.xml). Not sure yet if it's useful when
compared with a shell script.
I was really looking at the deployment aspect here, rather than creating
shell scripts.
* support automated functional tests execution
Cactus, right? :)
Nope. Cargo :-)
But cargo isn't doing the actual testing, its just starting and stopping
the server and setting up the environment. What do you use for the
testing aspect?
It's just a convenient way of separating them. Putting them all at the same
level would just be confusing.
ok.
The extra jars directories (ejbs/, ears/, etc) are not really required. They
may be required if you have a big applications with lots of ejbs, wars, etc.
I'm not recommending a fixed structure with this additional directory level.
I'm just saying it can exist.
Well, anything can exist, I'm just not sure we'd recommend that layout
(which is what I thought this was :)
I'm not sure what this is about?
In any case a nested directory structure such as:
ear/
|_ war/
|_ jar1/
|_ ejb/
|_ jar2/
Wouldn't really work, as J2EE modules are created by composition and not by
inheritance.
I don't know if you're referring to this or not.
Yes, this is what I was referring to. I see this as composition with the
ear as the end result. I understand that the jars might go directly in
the EAR though and so be at the same level.
I'm not certain of the cirucmstances under which either would be needed,
and I'm happy to have the ear as a sibling to the others, I just
remembered the aggregation alternative had been discussed.
Note: I've also tried some other solution. One of them was to have a
configuration module in charge of generating the configuration for a given
server and a given environment. A centralized configuration. It didn't work
too well. It was too hard to keep it centralized. We didn't use any tool. We
built our solution based on templates/velocity. I've had better success with
a distributed configuration approach where each module is in charge of
generating its configuration per environment. But I'm interested in other
people's feedback on this!
Yes, I agree with this approach too. About the only time centralised
configuration might make sense is if you are talking about application
configuration via LDAP or a database, for example.
Overall sounds pretty good, I'd probably understand more from seeing it
in action and fine tuning it by tinkering with it and oing through the
process of doing deployments, etc.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
