Peter Donald wrote:
>On Mon, 26 Aug 2002 21:56, Nicola Ken Barozzi wrote:
>
>
>>If yes, they should be in framework IMNSHO.
>>If no, it should be clearly stated that they are Phoenix-only compatible.
>>
>>
>
>Well given that cornerstone was designated a "Set of default services for
>Avalon/Phoenix" I think it is a given that they are only considered to be
>supported for Phoenix deployments. The link against Phoenix can be broken for
>some of them after the next evolution stage and most of the components will
>be migrated back into excalibur.
>
>
>
>>So you are saying that the Phoenix BlockContext has to be regarded as
>>the standard Container Context?
>>
>>
>
>Nope. I don't think anyone one has suggested that.
>
>However if a container needs to run components that were written to a
>particular containers API then they need to have a compatability layer. Much
>like if you use a bunch of components in excalibur you are still largely
>restricted to ECM/Fortress unless you want to extend your component or your
>container.
>
>Stephen has been suggesting that Phoenix should be maintaining a compatability
>layer for Merlin because Phoenix is legacy, badly written etc.
>
Pete - please can we try and stick with the facts!
Just because we disagree does not mean you need to make stuff up.
The term "legacy" does not mean badly written.
The term "legacy" means something you need to deal with that you inherit
from somewhere else. Cornerstone is legacy for any new container due to
the depedencies it contains towards the Phoenix container. I have
pointed out that much of cornestone can be made Phienix indepedent and
that cornerstone content can be enhanced to take advantage of recent
work in meta-info beyond block context.
>
>>Can we make this "spec" become more clearly defined and part of
>>framework somehow?
>>
>
>This is where things are going. Just need more time to experiment with things
>to make sure we are going in the right direction. The core ideas are
>relatively stable and are mostly derived and enhanced Phoenix ideas.
>
>See
>
>jakarta-avalon-excalibur/containerkit/src/java/org/apache/avalon/framework/info/
>
>
Just for everyone's reference - the piece of containerkit that Pete is
refering to is the equivalent of the excalibur/meta package. The
containerkit package - which is much more of a container architecture,
could very easily build above the excalibur/meta package. If fact there
are no technical obsticales whatsoever.
>For the "code" view of Component info (descendents of BlockInfo). They
>basically describe the requirements of a Component (ie what services it
>needs, services it exports, context entrys it requires, loggers it uses etc.
>
The equivalent excalibur/meta package also includes the ability for a
component to declare any extension ability or extension depedencies. It
does not require a container to provide support this functionality and
is completely seperate from extension implementation. In additon, the
excalibur/meta package incorporates ideas and suggestions introduced on
this list concerning teminology, firendliness of the API, and backward
compatibility with the blockinfo specifciation in Phoneix.
>
>Each aspect of component can be extended by "attributes". Attributes are
>key=value pairs that store extra information about the aspect and allow you
>to extend it in all sorts of ways.
>
>It is the attributes that are the things proving difficult to define as they
>require all sorts of experimentation. It is these attributes that are the
>causing the delay in it coming about.
>
>
On this I disagee.
There are some attributes that can be resolved relatively easily and can
enable the elimination of issues currently facing us.
>
>
>>I repeat myself, let's define the contracts and the boundaries well, and
>>I humbly suggest you to also tackle the block and SAR think, because I
>>think that they are valuable concepts that need to be integrated more at
>>a lower level.
>>
>>
>
>The notion of a Block disapears in next stage of evolution - there is just
>Components and all of them are really super-charged Blocks in current
>terminology.
>
Lets assume that Block dissapears in the stage of evolution - and that
there is just the defintion of a component type along the lines of
containerkit ComponentInfo or the excalibur/meta Type class. Lets
assume that this something worth discussing and reaching agreement on.
Refusal to even consider what others have being doing is really
difficult to work with.
>
>I don't think it is appropriate just yet to define the SAR deployment format
>(which includes all the assembly/configuration/environment data) because
>containers will definetly need different things in this area. It may be
>possible to define a package (jar) format. Possibly something like
>
>* standard naming convention for JDK1.3 Extensions in manifest
>
This is something I've been meaning to ask concerning sar deployment and
the assumptions being made about manifest extension jar depedecies in
the SAR-INF/lib?
>* standard mechanism for defining components (ie
>META-INF/avalon/components.xml)
>
As in meta-data directives?
Lets get a collaborative solution on meta-info that we are all
comfortable with first?
Cheers, Steve.
>* standard mechanism for defining factorys, resources and possibly "roles"[1]
>(ie META-INF/avalon/roles.xml, META-INF/avalon/resources.xml)
>
>[1] Note that this is partially inheriting from work in myrmidon and may not
>be so appropriate for phoenix and merlin. But it would be appropriate for
>Cocoon and Myrmidon. However this will take longer to figure out if we can
>figure it out at all.
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
