And another thing :-)
Just how serious is this problem anyway? 99% of j2ee apps should not
be specifying a parentId themselves at all, and if our documentation
suggests it that is a bug. I don't think we are going to have binary
compatibility between a config built for 1.0 and a config built for
1.0.1 anyway, so unless we have a testing program to prove that that
is likely to work, we are going to ask everyone to redeploy their
apps on 1.0.1, and if they don't have a parentId IMO that should
proceed without a plan change.
I think the best thing to do is to make sure that no one is
specifying parentIds and declare this a non-problem. Why won't that
work?
thanks
david jencks
On Jan 24, 2006, at 12:50 PM, Aaron Mulder wrote:
OK, I don't mean to encourage "rushing in", but the original goal for
1.0.1 was to freeze around the end of January...
Thanks,
Aaron
On 1/24/06, David Jencks <[EMAIL PROTECTED]> wrote:
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
