From: "Chris Opacki" <[EMAIL PROTECTED]> > Configuration file control is always an issue.. Can't > win...just deal. I've always had separate config files > for different environments. Just something you have to > live with.
Well, I'll agree that most developers are going to have locally modified config files, but that doesn't preclude all version control. For example, a couple of weeks into a typical J2EE project, I might get around to hooking up a security manager. Ideally, the rest of the team should be able to pick that up in a CVS update/merge and run an Ant target to refresh their server config files, rather than having to manually update each of them. This sort of process works well with JBoss, but doesn't work with WebLogic. If we avoid casually reorganizing/reformatting config files, there's no reason it shouldn't work with Geronimo. The idea is to help people avoid those long Monday morning emails that go something like: "I checked in code over the weekend that relies on these 67 configuration changes. You won't be able to deploy until you cut and paste each of the snippets below into the relevant config file." Instead, that becomes, "Don't forget to update and run the 'copy-config' target this morning to get the latest security changes". Much better for productivity and the overall frustration level. And then, of course, coherent version control on config files for shared dev/test/prod servers is a very good thing. When you're diagnosing a problem, being able to use CVS diff to see that Bob changed thread pool sizes on Thursday and Sue changed the transaction timeout on Friday can save a lot of time. Bottom line is that Geronimo mgmt tools will be most useful if they don't mangle everything they touch, so this should be considered when choosing a synchronization framework. Erin
