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: organisation of avalon subprojects
Date Mon, 01 Jul 2002 08:06:19 GMT
Stephen McConnell wrote:
> Leo Sutic wrote:
>> As Pete C says, I think we should slim the Avalon project 
>> *significantly*. And now I am talking about some chainsaw-grade 
>> reduction.
> Put away the chainsaw and think instead about the words 
> "consolidation".

+1 It's a matter of terms ;-)

> Go back to MicroContainer and rip out the lifecycle 
> processing code - put in place something from a common codebase - reduce 
> the duplication.  Phoenix has already done this, Merlin is 
> transitioning, if you do it you reduce unnecessary code - that 
> simplifies things - lots of little actions like that will have a big 
> impact.  The second and really important thing to consider is community 
> growth. If you take a look at 
> http://home.osm.net/technical/avalon/trends.html you will see that the 
> Avalon project is steadily building.  With the resolution of reusable 
> components I'm very confident that we will see significant jump in 
> growth - because all of a sudden you will see components that are 
> formally complete and consistent and that means reuse and that means 
> value an value means attention and attention means commercially 
> interesting.  But we are not there yet - its still in the nurturing phase.
>> With MicroContainer a new possibility has emerged: All Avalon 
>> components previously in Excalibur can move to Commons. I am currently 
>> thinking through what restrictions MicroContainer puts on the 
>> components it manages, but it appears to be quite few. 
> Providing we limit ourselves to non-meta based components.  Sorry Leo, 
> but MicroContainer will not run ANY of my components - NONE. For the 
> sort of things I'm doing it is only valid for the simplest type of 
> component.  I'm not complaining about the work you have done - but its 
> way too focussed on the the ECM style/pattern of component usage to be 
> usafull in a general context - and that is the big concern - you end up 
> propagating the informal component model - and the proliferation of 
> components that will not work across other containers.  That's the 
> important thing right now - eliminating those "semantics" gray areas - 
> getting this stuff really solid so that users can use the tool that best 
> matches the task.

The idea is that MicroCont will run only the simplest components, and 
*must* avoid duplicating definitions-semantics.
It should not propagate informal component model, and I think that Leo 
Sutic agrees with this.
If you need more, get the next-level container.

>> I have already made DataSource work, and I think I can do the same for 
>> just about any component in Excalibur.
>> MicroContainer would work with Avalon/Apps, but it seems a bit silly 
>> and palindromic to provide a non-Avalon wrapper for a wrapper for 
>> non-Avalon applications...
> Slow down a bit.  MicroContainer has nothing to support components with 
> formal dependencies.  I can guarantee you that MicroContainer will not 
> support the Avalon/Apps suite of components because it has NO 
> letters because I really think that we should be a lot more strict about 
> addressing limitation and potential of different activities in a much 
> more consistent manner.  That is the critical all import key - 100% 
> reusable components - nothing less.

With this I don't fully agree.
Micro should not have to be able to run Merlin components, while the 
opposite being true.
No dependencies and starting? Use Micro.
Need more? Upgrade to the next-level container.

>> So I see:
>> 1. framework
>> Avalon Framework interfaces and reference implementation.
>> 2. containers
>> 2a. common container code (metainfo, etc.)
>> 2b. microcontainer
>> 2c. fortress
>> 2d. phoenix
>> Again, this is my 3-container approach.
> What about Merlin? - Shouldn't it be included with the three musketeers 
> - or I should I head over to the axis-of-evil?


Finally you step in!
I was wondering the day you came out of the dark and joined the 
container discussion :-)

>  Seriously - I would like 
> to throw the "three-container-approach" a long long way away.  I don't 
> want to think about different containers.  I do want a common container 
> solution and that would involve (a) completing the containerkit core (b) 
> building services around that core, and (c) providing tools that 
> leverage those services.  Those tools would provide solutions to 
> different users - tools such component documentors, application assembly 
> generators, validators, deployment packagers, component and application 
> execution for the developer, an application server, application and 
> component motoring and analysis, etc., etc. With any luck - Fortress 
> will be rebuilt or at least broken down into a set of services that 
> leverage the container core.
 >  MicroContainer needs to be reviewed in
> terms of its immediate value against potential damage through component 
> fragmentation.  


> Merlin (yes - its a container too) is already being 
> totally re-written to leverage containerkit and its structure is being 
> broken out into general assembly services with the objective of 
> eliminating the which-container issue.  Bottom line - Phoenix is 
> restructuring - Merlin is restructuring - Fortress needs to restructure 
> - is there a trend here ? ;-)

Yes, there is :-)

Please, explain me what Merlin gives us that Fortress doesn't or can't 
yet do, and the opposite.
If you can make a simple list of features that each container has more 
than the previous, it would be great for me.

- use single component
- run lifecycle
- ...

- adds also...

- adds also...

- adds also .sar server apps
- adds JMX support
- ...

>> 3. component directory
>> This is a list of components that work with Avalon containers. This is 
>> basically Apps + Excalibur + all components in Commons that we export 
>> from Excalibur with MicroContainer. The actual components are *not* 
>> stored here unless they are wrappers for non-avalon components (like 
>> some of the current Apps). It is basically a list of "this is the 
>> stuff you can put in your container. 
> I have to confess that my use of Excalibur has been limited to 
> utilities. Can you provide a summary of the different "components" that 
> exist in Excalibur.

easy, just look at the names of the dirs in CVS ;-)
Anyway, most are already moving to Commons, since they have no 
avalon.framework dependency.

>> 4. site
>> 5. sandbox
>> The 4 and 5 is basically just for developers. So a newbie user comes 
>> in and sees this:
>> 1. Get the framework.
>> 2. Check the list of containers (all 3 of them). Pick one that suits 
>> your needs.
>> 3. Pick all the stuff you want to put in your container.
>> 4. Good to go!
>> Like Pete, I'd prefer just one container. But given the different 
>> requirements for containers I don't think "one single container" will 
>> work. I do think that all containers will be able to run all 
>> components, but the way they are managed and the grade of committment 
>> to Avalon architecture differs - and I do not see how that can be 
>> avoided.
> This has to be solved - existance of different semantic approaches to 
> component management mean that components are designed and implememtated 
> today relative to a target container family.  We have two semantic 
> models - the ECM/Fortress/MicroContainer model and the 
> containerkit/Phoenix/Merlin.  Either of these two approaches must die or 
> we must make a formal distrinction between them and live with the 
> consequences. 


But what *could* be nice is that there are different profiles of the 
same semantical model, ie bigger containers implement more features.
This creates no overlap.

>> Maybe we can provide some three-point checklist for the containers. 
>> Like (I'm sure we can argue over the list below. I'm only quite 
>> certain about MicroContainer and its "upper limit" against Fortress. 
>> As for the upper limit of Fortress, I'm a bit unsure.):
>> MicroContainer
>>  + You are primarily interested in using one or two Avalon components 
>> in another architecture.
>>  + You are not interested in the Avalon architecture and would like to 
>> know as little as possible about it.
>>  + Basically: Just give me the darn component! 
> And hope like hell its not a component that expects anything substantial 
> from its container - i.e. no meta support. Very limited validation - no 
> enforcement of a formal compoenent defintion - usefull for lifecycle 
> handling.


>> Fortress
>>  + You are considering using Avalon for part or all of your application.
>>  + Your application is not a stand-alone server or server application.
>>  + Basically: You are writing a servlet. 
> And hope like hell its not a formal component that you using.

? Could you explain more in detail please?

>> Phoenix
>>  + You are considering using Avalon for a stand-alone server.
>>  + Basically: You are writing an entire server. 
> And hope like hell it is a formal component or your hosed.

? Same as above :-?

>> Maybe even a checklist. Check all checkboxes, click on submit, and 
>> we'll tell you what container you want. :) 
> Today - do the checklist and you will end up with one or more containers 
> YOU MUST USE because of inconsitent and incompatible component models.

Yes, this is the issue.
We must instead end up with the *minimum* required container to host 
your components.


> There are actually several Avalon Apps projects that could escalate - 
> but the bottom line here is that those issue noted above must be sorted 
> out. Those projects are reusable components and the infrastructure needs 
> to exit beta before the majority can consider exiting the Avalon.  That 
> means working on containerkit - it means re-engineering all of the 
> current containers (even MicroConbtainer:-) ).

I think so too.
Containerkit is in infancy though, let's see what happens.

> It means every component coming out of Avalon passes a component 
> conformance test-suite.

Good proposal, I like it :-)

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