Jason van Zyl wrote:
Are you just describing generic situation or just simple dev/qa/prod situation where environments are almost identical?On Sun, 2005-04-17 at 17:20 +0200, Vincent Massol wrote:
The way I've been doing it so far is by having:
project1 |_ src/resources |_ env1 |_ [files or env1] |_ envN |_ [files or envN] |_ shared |_ [files shared by all envs] |_ [...]
And then having the logic to choose the resource files based on a env.name=env1|envN property.
See http://www.pivolis.com/pdf/Enterprise_Builds_V1.0.pdf, pages 9 to 11.
However, I have always thought this selection of resource files based on a
deployment environment is something that the build system should help with
(which was not really the case with m1 where you had to implement it in an
ad-hoc fashion). Hence my question for m2: is m2 going to help in this
domain?
I have the start of some tools that I've been working on for the current
contract I'm working on and the approach I've been taking is that that
same archive is used across all environments. I package the resources
for each of the environments inside the one archive and use an external
property to signal to the application which set of resources to use. I
think building archives for each environment is not only time consuming
but dangerous. Before I started taking that approach an archive was
taken and deployed to the wrong environment causing great amounts of
wonder.
I have a real life use case when we deploy the same application to approximately 30 banks.
There is only one application and approximately 50-60 environments. Differences between those environments are huge:
- different operating system, different databases, different jvm, different application servers (ours or j2ee) .
We don't actually use clustering but I imagine that people who deploy the same application to multiple cluster nodes in the same location can easily have couple dozen of environments more, which they need to support. This really requires a scalable solution.
If you will put all that to one archive not only it would be couple of megabytes larger but you risk to ship to clients the knowledge which should be protected (e.g. digital certificates, harcoded passwords (yes it happens :( )).
In a case when you are using j2ee and build-in security mechanism (declarative security in deployment descriptors)
you really need to replace fragments of web.xml, ejb-jar.xml application.xml files. If you deploy j2ee applications
(war, ear) to different application server you will also need to add application server specific descriptor.
I don't really see how you could activate some settings, which are stored in the some archive in such case.
I find it more scalable to have app-node1, app-node2, app-node-N artifacts in repository and to have some qa practices in place
which are assuring that right archive (more often archive of archives) is shipped to the right customer.
I haven't really had problem which you described nad never an archive was sent to the wrong place (and as you can see number of that places is quite big). Archive names which are clearly describing the environment name where this archive should be used are really helpful. So the conventions like myapp-clientX-nodeY-1.0.war are really priceless.
And don't get me wrong: you approach looks really interesting in certain circumstances. I just want to point that there are sometimes far more complex but not so unusual situations which would be nice to have covered in m2.
michal
---------------------------------------------------------------------- Wszystko o MOTORYZACJI >>> http://link.interia.pl/f186a
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
