geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Poll: Resolve configId Versions for 1.0.1
Date Tue, 24 Jan 2006 20:50:27 GMT
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 <david_jencks@yahoo.com> 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
>
>

Mime
View raw message