Harmeet Bedi [mailto:[EMAIL PROTECTED]] wrote:
[snip]
> I think Avalon is great.
Me too!!
> It just needs to get into stabilization phase and
> brand building phase. I think individuals in different
> companies would get it. My fear is that Avalon could get
> too complicated.
I think this is a question of "brand management" .. here are
the things that I have in mind when I look at the "Avalon
big-picture"
Phoenix
- a server activation framework - makes life easier
because I can use a "quasi-standard" model for
configuration of different blocks, deployment under
a .sar, etc.
- feels incomplete because of the lack of a management
interface (even a little local command line interface
to start the server, reconfigure, stop, etc. would
complete the picture)
- biggest benefit is "potential" to re-use third-party
blocks but (although this hasn't materialised yet)
Avalon
- a set of interfaces that a project can use to improve
code quality and consistency .. its kind of like going
beyond coding practices and saying, ok, this is a set
of patterns that will be used on project X - based
on our experience that patterns work nicely (although
I think the Cascading exception model is insufficiently
exploited)
Cornerstone
- confusing, on one hand it looks like a set of
demonstrations on how to build a block, and the
demonstration were questionable a couple of months ago,
which lead to the assumption that "ok, that's nice, so
lets focus on the real things - Avalon core and Phoenix -
however, James used cornerstone components in a real context
which doesn't sit well with this theory - hence a little
confusion - maybe "demo" content should be slit out
away from real re-usable Cornerstone blocks?
Each of these packages target distinctly different in the types of users.
In the Phoenix case its the server administrator and his problem is
configuration, deployment, management, etc. In the Avalon case the target
is the "responsible" for project policy, coding standards, object model,
etc. In the Cornerstone case its the developer who wants to be able to
re-use existing components - but the bottom line here is that these
components are only as good as the documentation supplying the code as a
fallback position does not cut it IMNSHO) - but before someone jumps on me
for saying this, I have to confess that I haven't really check the javadoc
on the cornerstone blocks in at least a couple of months - maybe things
have been updated.
Conclusions ....
(1) move demo stuff out of Cornerstone if Cornerstone is
more than a demo
(2) focus Phoenix "brand" as the runtime server deployment framework
- should be enhanced to handle ".sar"/".bar" declaration of the
version of Phoenix need for deployment (if you have
any doubts about this, just try plying around with
Avalon CVS, Jakarta James, Jakarta Tomcat and the
eas.betaversion.org blocks :-)
(3) focus Avalon on best-of-breed software practice
Cheers, Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
