avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: Summary of excalibur wrt Avalon 5
Date Fri, 20 Sep 2002 15:20:53 GMT
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:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message