Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: "'Avalon Developers List'" <dev@avalon.apache.org>
Subject: RE: [avalon] roadmap - library criteria
Date: Wed, 3 Mar 2004 22:45:17 +0100
Organization: S&N AG
MIME-Version: 1.0
In-Reply-To: <40464E96.6030407@apache.org>
Thread-Index: AcQBZax2FP8g9dnVRHuWJ+8Q2Wq+fwAAbvcg
Message-ID: <OF631DBDF1.32078147-ONC1256E4C.0076DAB8@sundn.de>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"

Stephen McConnell wrote: 
> 
> Carsten Ziegeler wrote:
> > And make sure that the components run out-of the box in the most 
> > recent containers including at least Fortress (ECM would be good as 
> > well, but perhaps we can forget that one)
> 
> Carsten:
> 
> Thanks for the email - there are several points I would like 
> to expand on but that's for another thread.  Concerning the 
> above - I would like to figure out a way in which we move you 
> from a implementation dependency to a service dependency.  
> I.e. I don't want you to be dependent on Fortress.  
Yes, I understand.

> I want 
> you to be dependent on an API.  If you can define that API, 
> I'm ready to take a shot a delivering an implementation 
> solution.  Even better - if you can provide some test cases, 
> I'm ready to spend some time making sure we provide a 
> sustainable solution.
> 
The most problematic area I currently see is Configuration. For
example in Cocoon we are using the ECM with three configuration
files: a roles configuration containg all roles, the component
configuration, containg the configuration for some components
in addition with some new components that are not in the roles
file and the logkit configuration.

Now Fortress is using a different approach, I uses for some
aspects Meta-Information and for some other aspects configuration
files that are not compatible with ECM. But you can use ECM
configuration files with Fortress but can't additionally use
the new configuration things from Fortress. So it's currently
an all or nothing approach (old or new, but not both) which
makes a smooth upgrade strategy impossible.

And if I peek at Merlin I fear that this is even worse - don't
get me wrong, I don't say Merlin is worse or Merlin is bad or
something like that. It's just that migration with regards
to Configuration is very hard.
So, this area lacks currently I think.

In addition, what I meant with my above statement is that you
should make sure that components in a component library not only
use all the latest available features of the latest container
version. They should also be runnable in older containers. For
example, if a component uses meta-info then it's not usable with
ECM. If a component uses meta-info that only Merlin supports,
than it's not useable with Fortress and so on.

The more I think about it, the more I come to the conclusion that
the current situation is bad. People, currently using ECM can
choose between Fortress and Merlin, but if they choose Fortress
they already know that they have to migrate sooner or later
to Merlin anyway.
People writing components have to choose for which container they
write components - obviously the container they are using.
So, perhaps it would really be better to forget Fortress and move
everything into Merlin but of course maintain the simplicity of
Fortress. Embedding Fortress into an own application is four or
five lines of Java code and some simple configuration file. That's
it.

Carsten


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