avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Assembly and meta stuff released ??
Date Tue, 18 Feb 2003 16:38:02 GMT


dvillevalois@phpapp.org wrote:

>Hello,
>
>I'm an Avalon new-commer. I do want my app container-independant. Sor i'm
>designing some lightweight lifecycle/lifestyle helper components for my
>container components. In order to implement them well, here are some few questions:
>
>* I would like to know the current status of the assembly and meta stuff that is
>in the avalon sandbox ?? I can see this is refactoring from work comming from
>the various home container. When do you plan to release it in the framework ?
>Does Phoenix, Fortress and Merlin plan to rebase their source code on it and when ?
>

Meta - has been stable for a few months.  Is used within the Assembly system
and the Merlin container.  Is also used in the enterprise project 
(avalon apps). 
Documentation is not bad - still room for improvement (some changes from 
about
three months ago are not reflected in the docs yet (mainly XML external 
format
stuff).  There are no supporting tools however I've started on a maven 
POM that
will handle things like meta data generation, block packaging, verification,
etc.  Some of the content needs to be tightened up - in particular the 
object
model for introduction of specialized meta types is supported, but its 
not as
clean as I would like.  Secondly, I would like to see this package grow to
include the ability for one meta type to extend another (but that's somewhat
in the future).

When is largely a factor of participation.  The more people get 
involved, the
better the product will be, an the more community support, the faster the
integration process into the framework layer.  If your interested in going
over documentation on Meta that would be really helpful - stuff like 
validation
of what is written, checking consistency of XML descriptions, addition of
code examples into the javadoc, etc. (plus checking some of my English for
some of the those very occasional slightly overly complex descriptions).

Phoenix <--> Merlin is initially about achieving a common substrate - namely
a common meta model. That will take a process of lots of discussions and I
think we will see a lot of focus on enabling differences without breaking
component portability. The Merlin <--> Fortress relationship is much more
about isolation and integration of a ECM style component semantics into the
assembly framework.  This could be achieved without too much difficulty
once people get engaged in the process and thare is a broader understanding
of the assembly package. Keep in mind that Assembly is still moving around
(not as much as Merlin) mainly in getting concepts and abstractions better
seperated and more consistent.  My guess is that we will be looking at a
stable assembly package in couple of months  following which it will be a
lot easier for people to get in deep.

>
>* I can't find a clear recent road map for the whole Avalon project on the web
>site. I know you are in the process to move to avalon.apache.org but maybe i did
>not search enough. Do you have one ? What are the priorities ?
>

What is reasonably safe to say is that there is convergence process 
ahead of us.
The most promising (IMHO) is the notion of profiled containers. What I 
envisage
is a core set of APIs that make up Avalon Facilities, Avalon Component 
Model, and and
Avalon Application Framework.  The facilities correspond loosely to
the utilities in Excalibur.  The Component Model would cover the framework,
meta and containment API (something like assembly after all of the guys 
have ripped
it apart and put it back together again).  A variety of deployment 
models (this is
where I believe we will see convergence/synergy with Fortress and 
Merlin), and
other important container side abstractions such as packaging models 
(e.g. like the
Phoenix sar model), better security tools - again leveraging the Phoenix 
work, and
possibly the notion of blocks as proposed by Merlin at some time in the 
future.

Given all of the above you have everything you need to literally 
assembly your
container of choice without sacrificing portability.  Its not really an
application - but instead I like to think of this as "an application 
management
scenario".  The solution is as light or as heavy as you want it to be.


>
>* When will the Component stuff be depricated ??? This seems to be a long while
>this code is deprecated... The first time i looked for documentation, i began to
>implement a Composable component. Is there a documentation update process
>started ? Who can i join on this if i want to help ? What needs first to be
>updated ???
>
>Just a note in comment to an exchange on the list about Avalon on servlet or
>servlets on Avalon. I do agree the best way would be servlets on Avalon but the
>fact is there a need in the first solution. The reason : we can rarely change a
>hoster's software choices.
>

I agree with all of the comments on this topic - being in control is 
great but its
not always feasible or practical. We need good solutions for both.

Cheers, Steve.


>
>
>Thanks for your help. A+. Didier.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>  
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message