On Jan 24, 2006, at 11:52 AM, Aaron Mulder wrote:
All, There was some IRC talk but not a lot of list response to the configId versioning issue. Right now, it's kind of holding up 1.0.1 IMHO because I can't support releasing 1.0.1 until we resolve the compatibility issue somehow, and there's going to be a fair bit of work to get it going one way or another. Anyway, for the 1.0.1 release, please indicate your preference for: [+0 ] Change all configIds to 1.0 even though it's the 1.0.1 release [-1 ] Change all references to use no version and make that work [ +0.5] Something else (please explain)
I haven't had a chance to think about this thoroughly yet. I really really really don't want to rush into a solution that may get us into trouble later. I prefer the current hard coded version number solution to removing version entirely. Offhand I think making configuration object names have groupId, artifactId, and version keys might provide a partial solution.
Fundamentally the problem is that a configuration needs to be able to say, "I need services X Y and Z, at these levels" and we need to be able to supply them. The current hardcoded solution certainly does this but way too specifically, you have to name the exact implementation you want and the exact version. A possible far-off goal is that your web app configuration says, "I need servlet 2.4 support" and something else configures whether it is jetty or tomcat. Ideally I would like to have a plan for how to get to this particular piece of pie in the sky before starting to change what we have now: I don't know if this is remotely realistic.
thanks david jencks
For the second option, that means the configId for module would still be geronimo/foo/1.0.1/car but any parentId, import, or GBean reference would look like this: parentId="geronimo/foo//car" <import>geronimo/foo//car</import> <import> <groupId>geronimo</groupId> <artifactId>foo</artifactId> <type>car</type> </import> That is, the version would be omitted from the reference, and we'd somehow interpret that to mean "whatever version is present" or "use most current version". You still *could* use a specific version, we'd just emphasize the version-less option for maximum compatibility. I think this alternative would require more work but might be a better fit for a long-term strategy. Thanks, Aaron
