> From: Peter Donald [mailto:[EMAIL PROTECTED]]
>
> On Mon, 19 Aug 2002 23:44, Nicola Ken Barozzi wrote:
> > We want to get an agreement on what to do for the present
> and future
> > with regards to unified Component Model, Merlin, Fortress,
> Phoenix, et
> > all.
> >
> > "Discussions get forgotten, just code remains."
> >
> > I will strongly oppose and veto any "compromise".
> > I want the *solution*.
>
> The only real solution is to use the ContainerKit model. With
> it you get will
> compatability between all the containers. Phoenix will use it
> directly while
> Merlin will load it through its own Type loader. If you
> choose to use Merlin
> specific xml format then you will be bound to Merlin.
>
> What is the problem with that?
I would like to detail the differences between ContainerKit and
Merlin's Type model. What are the benefits, and what are the
bad points?
BTW, is the XDoclet support for the *.info files going to move
to Excalibur? I would really like to see that in ContainerKit
or something so that we don't have to write all kinds of XINFO
files.
I also would like to know how to best apply the javadoc additions.
For instance, I see stuff like this in Cornerstone:
/**
* @phoenix:block
* @phoenix:service
org.apache.avalon.cornerstone.services.connect.ConnectionManager
*/
class DefaultConnectionManager implements ConnectionManager //, ....
{/* ... */}
But to me it would be more intuitive to have the interface marked
with an "@avalon:service" and the implementation marked with an
"@avalon:component".
That way, any component that extends a service interface will have
its entry added in the <services/> element automatically. It makes
sense to me--much more than seeing it on one block's javadoc but not
on another.
These things will also allow us to update the Excalibur components
so that they use the metainfo additions in the javadocs--and make it
easier to migrate Cocoon to a proper container system.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
