avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Date Tue, 27 Aug 2002 07:40:43 GMT

Peter Donald wrote:
> On Tue, 27 Aug 2002 04:03, Stephen McConnell wrote:
>>>>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.
>>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.
> Hmmm. You mean when I indicate that it is premature to adopt a convention that 
> specifies container architecture for extensions and that is not a technical 
> obstacle? Hmmmm.

I think that adopting a convention that specifies container architecture 
for extensions *is* a technical obstacle.

But the extension stuff started *after* this all started, and should be 
kept specific to Merlin, as it has been quite agreed.

What we *must* adopt, and you said it too, is a convention for declaring 
that there is something else that the Container must supply, then it's 
up to the specific container understand how; with Merlin it would be 

>>>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?
> what about it.
>>>* standard mechanism for defining components (ie
>>As in meta-data directives?
> as in a way of indicating the components stored in a jar.
>>Lets get a collaborative solution on meta-info that we are all
>>comfortable with first?
> If you are comfortable with what you have done then go with it. I am 
> comfortable with what I have done so I am going with it. Time will tell who 
> was right and who was wrong.

I don't care who is right and who is wrong.

Ego ego ego egoooooooooo

Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message