> -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: lundi 18 avril 2005 05:40 > To: Maven Developers List > Subject: RE: [M2] filter definition > > 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.
Well, this is not always possible. Also you're talking about archives whereas I'm talking about artifacts in the large. For example creating a weblogic domain configuration. In that case you cannot signal to the application which config.xml to use because it's the container that hosts the application, right? Or you would need to build a environment selector wrapping the container which makes it way to complex for the purpose. Also I don't find it nice to release to production artifacts containing all possible configurations when only one is used in production... > This also really makes you think hard about externalizing all your > configurations which I believe is a good thing. Hmm... This sentence make me realize we may not be talking about the same 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. I remember in one of my projects I had created a special project (I had called it Babylon because the tower of Babylon (or tower of Babel) is the place where God had tried to gather all cultures and languages of the world in one place... Unfortunately, as in the myth (the tower fell down) the Babylon project did not succeed... (it was well named after all!). The goal of this Babylon project was to create configurations for all the other projects. You would call it and ask it for (say) "the weblogic config.xml file for the demo environment" and it would create it using templates (I had used velocity templates) and XML files containing the configuration data for the full project). Basically Babylon was controlling the full config. It was executing at build time only. > 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 :-) Sure but that doesn't work for everything. Again, I'll use my example of a weblogic domain. This needs to be created before you can run the application. It would only work for everything that the application uses. For this, configuration data are usually stored in the database because if they need to be changed they're part of the business use case (the admin use cases for example). Having an app that does it is cool thought but I think that's what http://www.jconfig.org/ does. Thanks -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
