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. This also really makes you think hard about externalizing all your configurations which I believe is a good thing. The particular tool I've been working on is a tool that allows you to easily compare what configuration values you have across all environments so you can compare them and make sure they are correct. I would like to make a simple webapp so you can modify them and track them easily. Then the kicker would be to allow a runtime version of the this tool to be deployed with your application so that this tool could be used to dish out your configuration values. Think of it as a smarter resource bundle (it would even be made to have the interface of a resource bundle). Then the pie-in-the-sky feature would be to allow users to modify these values at runtime, because you always find thing wrong during testing, and have Maven SCM plugged into it so that when modifying your changes they went right back to your SCM so that the next time you deployed all your changes are there :-) -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
