You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2004/03/03 22:31:02 UTC
Re: [avalon] roadmap - library criteria
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. 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.
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [avalon] roadmap - library criteria
Posted by Stephen McConnell <mc...@apache.org>.
Carsten Ziegeler wrote:
> 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.
I've just committed an example of embedding merlin so that you can get
an idea of things (available in avalon/merlin/platform/tutorials/main).
The example goes through the following steps:
1. setup an application cache -- 4 lines
2. build the application classloader -- 3 lines
3. parameterize and deploy the application -- 3 lines
In general the same pattern applies for any repository enabled
application. The demonstration will run with or without a merlin
install. If merlin is installed the demo will use the existing merlin
system repository, otherwise a new system repository will be created and
populated automatically. The actual bootstrapping is taken care of by
the single jar file avalon-repository-main.
Cheers, Steve.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [avalon] roadmap - library criteria
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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