On Fri, 2002-09-20 at 16:11, Jason van Zyl wrote: > > >Could someone post a short summary of what pieces in excalibur are being > > >considered for use in Avalon 5? > > > > > > > I would ignore A5 if I were you. Based on the discussions on A5, there > > were no convincing arguments for a major version increment over A4. My > > own conclusion is that 4.X is here to stay for a good time yet. > > That's fine then. A summary of all the activity and plans for the tools > that will be rolled into subsequent versions of avalon.
my take: not gonna happen (anytime so soon as to take it into account). Not with our meta model wars...... > > >I'm plugging away at making a container > > >and I would like to use as many of the standard building blocks as I can > > >but I still do not have a very good grasp on what in excalibur is going > > >to be used for what. > > > > Its simply a collections of tools and utilities that generally leverage > > Avalon Framework lifecycle patterns. They typically get used within > > component and container implementations. Excalibur can be viewed as the > > commons library for Avalon. > > Sure, but what I'm interested in are things like containerkit. I would > like to know if it's worth the time to try and integrate that code into > my container. Or the various meta models, or the interceptors. I'm just > looking for a short summary on where the desire lies to maintain all > these new packages that are cropping up and how they might fit into new > versions. No-one is quite sure on all this atm I think. I'm going to burn my hands trying to do this overview...this is very much IMHO. (everyone else, I'm okay if y'all want to add to this or go into long discussion, but I won't be watching ;) altrmi ------------- very cool, not used very much. Whether it'll live long depends on 'marketing' I think. assembly ------------- Really is "Merlin 2". Steve's doing a lot of work and as long as his company is going strong I suspect it'll stay for sure =) Other people are also interested and doing some stuff so Merlin will be around, though it might change substantially because of fortress integration. Wouldn't recommend it for production, definately for ideas and alpha/beta stuff. baxter ------------- Will live. Useful, stable. bzip2 ------------- Will move. Useful, stable. cache ------------- dunno. cli ------------- Will move. Useful, stable. collections ------------- Will move. Doesn't belong here. Useful, stable. component ------------- Will die. Useful, stable. concurrent ------------- dunno. configuration ------------- dunno. Useful. container ------------- dunno. containerkit ------------- Will be around. Sound idea, most important parts supported by merlin, PD pushing it in different areas. There's the meta model war problem though... converter ------------- dunno. csframework ------------- Might be the future for all of us in the end =) datasource ------------- Will stay. Useful, stable. event ------------- dunno. Very cool but definately alpha. extension ------------- dunno. Cool. Might move. fortress ------------- dunno. Very much useful, might merge with Merlin. I think it deserves an alpha release and more attention than it has been getting recently =) Though it has less functionality than merlin, it is good at what it does. Might be a good choice for you, as it is basically geared at cocoon-like stuff. i18n ------------- Should move, might stay. Useful, stable. info ------------- dunno. Likely meta model war casualty. Very nice otherwise. instrument ------------- Useful, stable, cool. instrument-client ------------- Useful, stable, cool. instrument-manager ------------- Useful, stable, cool. interceptor ------------- pre-alpha =) Would stay away for the next year =) io ------------- Useful, stable, should move. jprocess ------------- dunno. loader ------------- dunno. logger ------------- dunno. If you use component, use this. merlin ------------- Will die. Use the assembly package. meta ------------- dunno. Likely meta model war casualty. Very nice otherwise. monitor ------------- dunno. naming ------------- dunno. Seems useful. pool ------------- dunno. There are pooling impls all over the place. Hope this gets cleaned up ;) sourceresolve ------------- dunno. store ------------- Stable, useful. tar ------------- Will move. Stable, useful. testcase ------------- Hope it will be replaced with something more extensive and solid. Esential though. thread ------------- dunno. Yet more pooling. Useful. threadcontext ------------- dunno. tweety ------------- Will be around. Stable, useful, but don't use =) util ------------- dunno. Hope it moves. xmlbundle ------------- dunno. Hope it moves. xmlutil ------------- dunno. Hope it moves. zip ------------- Will move. Stable, useful. Quite a long list =) When I mention "useful", it means I've used it and it worked. When I mention "stable" it means I *think* the API won't change much anytime soon. When I mention "dunno" the package is short on docs and/or I haven't used it. Generally, for alpha development, I say use everything but the stuff dealing with meta models. For beta development I dare say these are okay: bzip2 cli i18n io naming zip fortress assembly cache datasource altrmi (not because it stable but because it fits a void) baxter cli collections configuration io i18n instrument-* testcase For stable development: bzip2 cli i18n io zip component baxter cli instrument-* testcase Not to say that packages not listed are not of good quality I just don't know enough to say so. I personally find that the excalibur package as a whole is still messy and there is a lot of documentation missing for many packages. This says little about the stability or usability of the code, but for larger projects with multiple people working on them, it is a serious problem and hence I stay clear of overything larger than a few classes in those. That's a big part in the above recommendations. > I'm not looking for a detailed roadmap as I'm fully aware how thing may > change and I'm fine with making alterations as necessary to keep up with > changes until a release. I just wanted to get a little better picture > for myself and hoped that a short one line summary of each package would > help. I hope so, though I doubt it ;) cheers, Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
