On Sun, 2005-04-17 at 20:53 +0200, Vincent Massol wrote: > 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...
Weblogic is exactly where I'm doing this :-) There are all sort of things that need to be changed. The single archive contains the profiles for the environments and the within the archive I have a process which lays down file over top of the existing domain and opens up the EAR file and alters certain descriptors for security options. (In this particular organization I am not allow to regenerate the domains because they use Netegrity's SiteMinder and I'm not allowed to have the password. I generate the domain, they put in password and it is keyed to the domain so if I regenerate it the hash password won't work in the new domain. Long story, very annoying but what I have to deal with.) > > 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... :-) Expanding on what Michal was talking about in a previous email I think you could have a profile, whether it be for a internal environment or client, and have a process that produces a working application. I have a primitive way of doing this now but it works. I have a single archive which contains an EAR file destined for Weblogic and within that archive the tool that can modify the weblogic domain and swizzle the EAR file. I tried to avoid swizzling the EAR but that doesn't seem possible. > > 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. See, I execute this post build time at deployment. The process I use could be incorporated into a general deployment mechanism which could be tied into an installation procedure. Pick your db settings, security options like integration with SiteMinder policy services, LDAP directories or whatever, create the profile and then run the tool using the profile. I think you have to do this at deploy time because you don't know what the configuration options will be if you're deploying a product. I think having a profile can work. The deployment process may generate some properties that the application uses and the deployment process may have to alter the prototype application as sometimes there is just no way around this. But I think it is entirely possible and that's definitely one of the things I would like to pursue in a separate project and then integrate it into a process promoted by Maven. > > 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. For alterations in J2EE descriptors yes, but for everything else it's possible as I'm doing it now with Weblogic. > It would only work for everything that the application uses. Right. > 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. Ideally you should be able to store it anywhere and you should be able to modify them at runtime. It should be an integrated mechanism where the application can use the tool itself as the source of the configurations. I haven't looked at JConfig but ideally I don't just want to generate properties file. Ideally something that: o help you create the configuration profiles you need o helped you compare them easily (especially for localization) o provided a tool to embed in your application which can consume these profiles o provided an easy way to change them at runtime (like a reload mode) so this might be a application that can have a web view you can skin or a simple Swing/SWT panel you can embed. o provided an easy way to get the changes when back to your SCM (if you're working in an environment like mine where the app is developed internally and the only profiles you're working with are used internally) I've seen tools like commons-configuration (which came from Turbine so I'm familiar with it), and now I see JConfig but I'm not aware of a fully integrated solution like what I'm describing. > Thanks > -Vincent > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
