geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Poll: Resolve configId Versions for 1.0.1
Date Tue, 24 Jan 2006 21:16:16 GMT
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  

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 <> 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

View raw message