You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ryan Hoegg <rh...@isisnetworks.net> on 2003/10/08 19:22:54 UTC
[RT] Separation of Blocks and Avalon
Hi,
I've been following the block design discussion and wiki evolution with
great interest for a couple months now (blame Geoff). Blocks look
wonderful, and I can't wait to develop my cocoon based applications as
blocks.
I have a concern about the bundling of exposed avalon services with
blocks. Specifically, in the recent thread about "Finishing the First
Phase of Block Design" and on
http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition I see some
duplicated effort. As Stephen McConnell noticed, some of this
functionality is already built, tested, and maintained in several avalon
containers. Why not package avalon blocks/services/components in the
way the container expects, and include them somewhere like /COB-INF/lib
or /COB-INF/public/lib? Or, even cleaner separation can be had in some
cases by deploying them to the avalon container independently.
If things are done this way, the problem noted in the thread I mentioned
above could be completely avoided. There would be no need to expose
classes through the block interface because all java would be exposed as
avalon services.
I think this would simplify the block design greatly, and allow us to
focus on cocoon-specific aspects.
Thoughts?
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: [RT] Separation of Blocks and Avalon
Posted by Upayavira <uv...@upaya.co.uk>.
Stefano Mazzocchi wrote:
...
> if Fortress was there, admittedly, things would be easier... but then
> again, lots of talks, but nobody is able, wants or has
> time/energy/braveness to do the migration.
My impression is that Berin is willing, but he's just waiting on the 2.2
repository.
Regards, Upayavira
Re: [RT] Separation of Blocks and Avalon
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Berin Loritsch wrote:
> Stefano Mazzocchi wrote:
>
>> if Fortress was there, admittedly, things would be easier... but then
>> again, lots of talks, but nobody is able, wants or has
>> time/energy/braveness to do the migration.
>
> Huh? I have offered, and have been told to wait until Cocoon 2.2.
>
> So, is the repository ready? A can take care of it fairly quickly if so.
>
I'll offer my help here, if there's something I can help with. Feel
free to e-mail me personally, Berin.
--
Ryan Hoegg
Re: [RT] Separation of Blocks and Avalon
Posted by Stefano Mazzocchi <st...@apache.org>.
On Thursday, Oct 9, 2003, at 22:52 Europe/Rome, Berin Loritsch wrote:
> Stefano Mazzocchi wrote:
>
>
>> if Fortress was there, admittedly, things would be easier... but then
>> again, lots of talks, but nobody is able, wants or has
>> time/energy/braveness to do the migration.
>
> Huh? I have offered, and have been told to wait until Cocoon 2.2.
>
> So, is the repository ready? A can take care of it fairly quickly if
> so.
no, it's not, but it's time we start. I'll ask infrastructure to create
it, then start to move stuff around (from the server, so we don't loose
CVS history).
I'll ring the bell when I'm done and the repository is ready.
--
Stefano.
Re: [RT] Separation of Blocks and Avalon
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
>
> if Fortress was there, admittedly, things would be easier... but then
> again, lots of talks, but nobody is able, wants or has
> time/energy/braveness to do the migration.
Huh? I have offered, and have been told to wait until Cocoon 2.2.
So, is the repository ready? A can take care of it fairly quickly if so.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [RT] Separation of Blocks and Avalon
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
> Stephen McConnell wrote:
>
>>The million little details that cocoon assumes on top of ECM is also the
>>thing that scares me the most.
>>
>
> Me, too. And I'm really wondering if we can keep our nice little additions
> if we move away from ECM.
You may be able to, but they will be done differently. For instance, Merlin
and Fortress use the Lifecycle Extensions API which can be used for most of
the special things you are doing.
>>Is there someone who provide the breakdown of what Cocoon is doing over
>>and above ECM? However things roll out - one of the biggest obsticles I
>>see is that we need to move away from ECM/Fortress extension and to a
>>solution where Cocoon does not need to access container APIs. With that
>>information the Avalon crowd can address how to addres these
>>requirements in a way that makes the concern indpendent of the container
>>implementaiton.
>>
>
> We extend the ECM with our CocoonComponentManager, you can have a look
> at that class. All the features (hacks?) in there have to be somehow
> available using fortress, merlin or whatever.
> We have another lifecycle type, the request lifecycle component. This is
> an extension to poolable and means that per request only one instance
> of this component is used. So if two other components lookup this
> request lifecycle component, they get the same instance.
> The implementation of this extension is a little bit difficult as we
> have sub requests that run in the same thread but have a different
> set of request lifecycle components.
> In addition it's possible to process on request multi threaded which
> makes this even more difficult.
You might be able to get around this with a PerThread model, as I am
not aware of any Java Servlet container that shares the same thread
between multiple requests.
We will have to look at what options are available to implement this.
> There are some other important extensions like the environment handling
> for the source resolver and the sitemap configurable components. They
> use more or less the same technique used for the request lifecycle
> components.
Right.
>
> I'm more and more thinking that we should do one thing after the other:
> first creating our blocks and than moving to fortress or merlin.
> Or the other way round, if someone things that it makes more sense.
> But we should avoid doing both at the same time.
> I mean, we are currently happy with ECM - it works, it's stable and the
> only real concern we have is the big cocoon.xconf which is solved with
> blocks anyway. (I don't want to say that fortress/merlin are not stable
> with this).
ECM is ok when you already have an infrastructure built with it. However,
maintaining the roles file and the component source code can let things
get out of sync--esp. if you are refactoring. Fortress and Merlin will
allow you to change EVERYTHING about the implementated component--including
the package it resides in--without requiring changes anywhere else. Try
that with ECM.
It opens up the doors to refactoring a bit wider.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
RE: [RT] Separation of Blocks and Avalon
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Giacomo Pati wrote:
>
> > We extend the ECM with our CocoonComponentManager, you can have a look
> > at that class. All the features (hacks?) in there have to be somehow
> > available using fortress, merlin or whatever.
> > We have another lifecycle type, the request lifecycle component. This is
> > an extension to poolable and means that per request only one instance
> > of this component is used. So if two other components lookup this
> > request lifecycle component, they get the same instance.
> > The implementation of this extension is a little bit difficult as we
> > have sub requests that run in the same thread but have a different
> > set of request lifecycle components.
> > In addition it's possible to process on request multi threaded which
> > makes this even more difficult.
>
> IIRC Fortress can handle this with a special Handler we have to supply
> (instead of subclassing the hole Container class). Remeber that in
> Fortress Object handling is separated into meta data instead of
> additional marker interfaces. There is no Poolable, ThreadSafe, etc. any
> more but ThreadSafeComponentHandler, PoolableComponentHandler instead.
>
Yes, I know - and I saw the handlers of fortress and it should work.
> > There are some other important extensions like the environment handling
> > for the source resolver and the sitemap configurable components. They
> > use more or less the same technique used for the request lifecycle
> > components.
>
> I'm sure there is a way for this also and with the help of a Handler it
> can be made with IOC in mind.
I'm not sure for the source resolver part. The other things should work,
yes.
>
> Yes, but the world is still spinning and there are alot of other
> Component out there that don't follow the ECM style because it's
> deprecaded for long time now and every time we want to use such a
> component we have to extend the working interface to make it a
> 'Component' for ECM and extend the implementation to have our interface
> implemented (do you remember the Cornerstone Scheduler?). That's ugly!
>
Definitly. Ok, that's a point.
> As a side note: I got the impression (and that supprises me alot) there
> is too little knowledge around here what Avalon is doing and where it is
> moving in the so central Component Container discipline. This IMHO led
> to this 'we think Avalon cannot supply what we want' situation and so we
> are ignoring the helping hand Avalon people put forth several times now.
>
At least for me it's not the 'we think Avalon cannot supply what we want'
that I fear of. It's more a "can the Avalon community support the version
for us and for how long".
Carsten
RE: [RT] Separation of Blocks and Avalon
Posted by Giacomo Pati <gi...@apache.org>.
On Fri, 10 Oct 2003, Carsten Ziegeler wrote:
> Stephen McConnell wrote:
> >
> > The million little details that cocoon assumes on top of ECM is also the
> > thing that scares me the most.
Absolutely right! IMHO we've ridden our own train for too long and am
now in the situation where we are far from what Avalon can supply to
Cocoon in the Container arena.
> >
> Me, too. And I'm really wondering if we can keep our nice little additions
> if we move away from ECM.
See below.
> > Is there someone who provide the breakdown of what Cocoon is doing over
> > and above ECM? However things roll out - one of the biggest obsticles I
> > see is that we need to move away from ECM/Fortress extension and to a
> > solution where Cocoon does not need to access container APIs. With that
> > information the Avalon crowd can address how to addres these
> > requirements in a way that makes the concern indpendent of the container
> > implementaiton.
> >
> We extend the ECM with our CocoonComponentManager, you can have a look
> at that class. All the features (hacks?) in there have to be somehow
> available using fortress, merlin or whatever.
> We have another lifecycle type, the request lifecycle component. This is
> an extension to poolable and means that per request only one instance
> of this component is used. So if two other components lookup this
> request lifecycle component, they get the same instance.
> The implementation of this extension is a little bit difficult as we
> have sub requests that run in the same thread but have a different
> set of request lifecycle components.
> In addition it's possible to process on request multi threaded which
> makes this even more difficult.
IIRC Fortress can handle this with a special Handler we have to supply
(instead of subclassing the hole Container class). Remeber that in
Fortress Object handling is separated into meta data instead of
additional marker interfaces. There is no Poolable, ThreadSafe, etc. any
more but ThreadSafeComponentHandler, PoolableComponentHandler instead.
> There are some other important extensions like the environment handling
> for the source resolver and the sitemap configurable components. They
> use more or less the same technique used for the request lifecycle
> components.
I'm sure there is a way for this also and with the help of a Handler it
can be made with IOC in mind.
> I'm more and more thinking that we should do one thing after the other:
> first creating our blocks and than moving to fortress or merlin.
My hope was that the hole Classloader stuff could be delegated to one of
the new Containers.
> Or the other way round, if someone things that it makes more sense.
> But we should avoid doing both at the same time.
> I mean, we are currently happy with ECM - it works, it's stable and the
> only real concern we have is the big cocoon.xconf which is solved with
> blocks anyway. (I don't want to say that fortress/merlin are not stable
> with this).
Yes, but the world is still spinning and there are alot of other
Component out there that don't follow the ECM style because it's
deprecaded for long time now and every time we want to use such a
component we have to extend the working interface to make it a
'Component' for ECM and extend the implementation to have our interface
implemented (do you remember the Cornerstone Scheduler?). That's ugly!
As a side note: I got the impression (and that supprises me alot) there
is too little knowledge around here what Avalon is doing and where it is
moving in the so central Component Container discipline. This IMHO led
to this 'we think Avalon cannot supply what we want' situation and so we
are ignoring the helping hand Avalon people put forth several times now.
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: [RT] Separation of Blocks and Avalon
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Reinhard Poetz wrote:
...
> ...if anybody thinks Berin shouldn't do it he should speak *now*!
:-$
;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Separation of Blocks and Avalon
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Oct 14, 2003, at 15:29 Europe/Rome, Berin Loritsch wrote:
> Stefano Mazzocchi wrote:
>
>> Potentially possible, but I wouldn't do it, we need to be able to
>> keep the 2.1 tree clean.
>> Berin, how long would you think it would take you to do the migration?
>
> The simple migration will be fairly quick. For instance, it would take
> a couple of hours. The additional features, however, would take a bit
> more
> time. 90% could be worked around initially just by taking advantage
> of the
> way current Servlet containers work.
Can you be more precise on this? I'm not sure I'm following you.
>> do you have a list of things that worry you most?
>
> With help, I think we can migrate and stablize Cocoon 2.2 rather
> quickly.
> Cocoon would still need to extend Fortress a little to get the
> dynamically
> compiled generators (XSP) and such.
XSP will probably be moved into a block, we might want to focus on the
core stuff first.
> We also might need to create a new
> LifecycleHandler for Request bound components. The thing is passing
> the
> request object to the handler. We could do this with a more dynamic
> Context object, or we could use the Lifecycle Extensions API, or we
> could
> do a bit more like current ECM is operating.
I'd like to follow the lifecycle extensions, if that was an option.
from what I recall, it was implemented more or less exactly for those
situations.
> These things will take some time to shake out the details for a
> better/pure
> environment, but Cocoon would be usable after the initial port. The
> XSP
> might be a disabled for a day or two, though.
this is *not* a problem. the 2.2 tree can stay up in the air for as
long as it takes. this is the reason why we made a different module.
the day 2 day work continues on cocoon-2.1
>> BTW, why can't we do the migration *after* we implement the blocks?
>
> We can do it whenever you like. I just need to know when you guys
> want it.
> When I have the green light, I will start working on it.
You have green light from me.
>> I mean, we have a system that works and a design that improves.
>> cocoon needs block far more than it needs a migration to a more
>> modern avalon container.
>
> :) You know, I have a feeling that the more modern Avalon container
> will
> open up the doors to things you may not have thought possible
> beforehand.
True
> I think you will find the new container and blocks will have a
> symbiotic
> relationship. Whichever you choose to implement first is up to you.
Up to *US*, please. :-)
Anyway, I think your volunteering deserves trust.
for me: go!
[please keep up posted with progess and, in case, request for help]
--
Stefano.
Re: [RT] Separation of Blocks and Avalon
Posted by Berin Loritsch <bl...@apache.org>.
Reinhard Poetz wrote:
>
> The 2.2 CVS repository already exists (cocoon-2.2) - currently the
> rights are not set correctly. Stefano has already written a mail to
> Apache infrastructure to solve this issue.
>
PMC Chairs should be able to administer their own repository's AVAIL
info....
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
RE: [RT] Separation of Blocks and Avalon
Posted by Reinhard Poetz <re...@apache.org>.
From: Berin Loritsch
> Reinhard Poetz wrote:
>
> > From: Berin Loritsch
> >
> > <snip/>
> >
> >>We can do it whenever you like. I just need to know when you
> >>guys want it. When I have the green light, I will start
> working on it.
> >
> >
> > We already voted on this
> >
> (http://marc.theaimsgroup.com/?l=xml->
cocoon-dev&m=106217462427048&w=2)
> > and we had some talks at the GetTogether in Gent.
> > There has been no -1 (and I didn't meet anybody in Gent who was
> > against
> > it) so just do it!
> >
> > ...if anybody thinks Berin shouldn't do it he should speak *now*!
>
> The only thing raised is when to start. The Cocoon community
> has not yet voted to open up the Cocoon 2.2 repository--if
> they have, I missed it. I know I should wait until the Cocoon
> 2.2 is set up as a clean slate.
The 2.2 CVS repository already exists (cocoon-2.2) - currently the
rights are not set correctly. Stefano has already written a mail to
Apache infrastructure to solve this issue.
HTH
Reinhard
Re: [RT] Separation of Blocks and Avalon
Posted by Berin Loritsch <bl...@apache.org>.
Reinhard Poetz wrote:
> From: Berin Loritsch
>
> <snip/>
>
>>We can do it whenever you like. I just need to know when you
>>guys want it. When I have the green light, I will start working on it.
>
>
> We already voted on this
> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106217462427048&w=2)
> and we had some talks at the GetTogether in Gent.
> There has been no -1 (and I didn't meet anybody in Gent who was against
> it) so just do it!
>
> ...if anybody thinks Berin shouldn't do it he should speak *now*!
The only thing raised is when to start. The Cocoon community has not
yet voted to open up the Cocoon 2.2 repository--if they have, I missed it.
I know I should wait until the Cocoon 2.2 is set up as a clean slate.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
RE: [RT] Separation of Blocks and Avalon
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Berin Loritsch wrote:
>
> Carsten Ziegeler wrote:
>
> > Berin Loritsch wrote
> >
> >>
> >>We can do it whenever you like. I just need to know when you
> >>guys want it. When I have the green light, I will start working on it.
> >>
> >
> > Great, Berin! In the meantime, we had discussed that we don't want
> > to do blocks and fortress at the same time, but one after the other.
> > So, we have just to decide the order, I guess.
> >
> > I have the perception, that you Berin, can start right now. Is
> this right?
>
> essentially. I'll have a brief refamiliarization period though.
>
Yes, of course. But "right now" I meant "as soon as you well you
can do it".
Regards
Carsten
Re: [RT] Separation of Blocks and Avalon
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
> Berin Loritsch wrote
>
>>
>>We can do it whenever you like. I just need to know when you
>>guys want it. When I have the green light, I will start working on it.
>>
>
> Great, Berin! In the meantime, we had discussed that we don't want
> to do blocks and fortress at the same time, but one after the other.
> So, we have just to decide the order, I guess.
>
> I have the perception, that you Berin, can start right now. Is this right?
essentially. I'll have a brief refamiliarization period though.
> And I also have the perception that blocks could in theory start right now
> but perhaps need some more pollishing before really touching code.
> So from my POV: fortress first then blocks.
>
> What do others think?
>
> Carsten
>
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [RT] Separation of Blocks and Avalon
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Oct 14, 2003, at 16:12 Europe/Rome, Carsten Ziegeler wrote:
> Berin Loritsch wrote
>>
>> We can do it whenever you like. I just need to know when you
>> guys want it. When I have the green light, I will start working on it.
>>
> Great, Berin! In the meantime, we had discussed that we don't want
> to do blocks and fortress at the same time, but one after the other.
> So, we have just to decide the order, I guess.
>
> I have the perception, that you Berin, can start right now. Is this
> right?
> And I also have the perception that blocks could in theory start right
> now
> but perhaps need some more pollishing before really touching code.
> So from my POV: fortress first then blocks.
>
> What do others think?
+1
Let me remind you that work on all the block infrastructure *outside*
cocoon can happen at the very same time.
Look at the phases plan on the wiki: once we have the object model, we
can start working on the block deployment tool (which lives completely
outside cocoon) and on the block librarian (which is going to be itself
a cocoon web app, but may be implemented without any block-specific
feature).
SoC at work!
--
Stefano.
RE: [RT] Separation of Blocks and Avalon
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Berin Loritsch wrote
>
> We can do it whenever you like. I just need to know when you
> guys want it. When I have the green light, I will start working on it.
>
Great, Berin! In the meantime, we had discussed that we don't want
to do blocks and fortress at the same time, but one after the other.
So, we have just to decide the order, I guess.
I have the perception, that you Berin, can start right now. Is this right?
And I also have the perception that blocks could in theory start right now
but perhaps need some more pollishing before really touching code.
So from my POV: fortress first then blocks.
What do others think?
Carsten
RE: [RT] Separation of Blocks and Avalon
Posted by Reinhard Poetz <re...@apache.org>.
From: Berin Loritsch
<snip/>
> We can do it whenever you like. I just need to know when you
> guys want it. When I have the green light, I will start working on it.
We already voted on this
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106217462427048&w=2)
and we had some talks at the GetTogether in Gent.
There has been no -1 (and I didn't meet anybody in Gent who was against
it) so just do it!
...if anybody thinks Berin shouldn't do it he should speak *now*!
Cheers,
Reinhard
Re: [RT] Separation of Blocks and Avalon
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
>
> Potentially possible, but I wouldn't do it, we need to be able to keep
> the 2.1 tree clean.
>
> Berin, how long would you think it would take you to do the migration?
The simple migration will be fairly quick. For instance, it would take
a couple of hours. The additional features, however, would take a bit more
time. 90% could be worked around initially just by taking advantage of the
way current Servlet containers work.
> do you have a list of things that worry you most?
With help, I think we can migrate and stablize Cocoon 2.2 rather quickly.
Cocoon would still need to extend Fortress a little to get the dynamically
compiled generators (XSP) and such. We also might need to create a new
LifecycleHandler for Request bound components. The thing is passing the
request object to the handler. We could do this with a more dynamic
Context object, or we could use the Lifecycle Extensions API, or we could
do a bit more like current ECM is operating.
These things will take some time to shake out the details for a better/pure
environment, but Cocoon would be usable after the initial port. The XSP
might be a disabled for a day or two, though.
>
> BTW, why can't we do the migration *after* we implement the blocks?
We can do it whenever you like. I just need to know when you guys want it.
When I have the green light, I will start working on it.
>
> I mean, we have a system that works and a design that improves. cocoon
> needs block far more than it needs a migration to a more modern avalon
> container.
:) You know, I have a feeling that the more modern Avalon container will
open up the doors to things you may not have thought possible beforehand.
I think you will find the new container and blocks will have a symbiotic
relationship. Whichever you choose to implement first is up to you.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [RT] Separation of Blocks and Avalon
Posted by Geoff Howard <co...@leverageweb.com>.
Giacomo Pati wrote:
> On Fri, 10 Oct 2003, Geoff Howard wrote:
>
>>How about this proposal:
>>
>>If Berin feels the migration can be quick (1 week?) we start a 2.2 repo,
>
> I would give him even 2 weeks ;-)
:)
Clarification:
- We give _it_ x amount of time not him. I think we ought to be as
involved as possible.
- 1 week was really tossed out as a question to the one(s) who are in a
position to guess what it will take and to start to define what "quick"
would mean. 6 months of hard work is not quick. 1 day is quick.
In-between is a judgement call we'll have to make and that's where I'd
expect it to be.
Geoff
Re: [RT] Separation of Blocks and Avalon
Posted by Giacomo Pati <gi...@apache.org>.
On Fri, 10 Oct 2003, Geoff Howard wrote:
> How about this proposal:
>
> If Berin feels the migration can be quick (1 week?) we start a 2.2 repo,
I would give him even 2 weeks ;-)
> and let that be the only work that happens for that quick time frame in
> the 2.2 repo. If possible we should all help with aspects of the
> migration so we don't "come home to a strange house" so to speak.
+1!
> If it bogs down, reveals nightmarish problems, etc. we have the option
> of wiping clean, moving on with blocks immediately on ECM and worry
> about the migration later.
Yes.
> In any case, we have to (don't we?) regard the migration off ECM as
> inevitable and a little pain now is better than a lot of pain later. A
Exactly!
> lot of pain now is not better than the same amount of pain later. Which
> case we're in should be apparent if we try the path proposed above.
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: [RT] Separation of Blocks and Avalon
Posted by Berin Loritsch <bl...@apache.org>.
Geoff Howard wrote:
> Berin has expressed several times a confidence that the migration to
> Fortress could be relatively quick (though apparently he's suffered a
> minor back injury and is not completely convinced of his own sanity!).
I am much better now. The pain is mostly gone, and I am only a bit stiff.
>
> How about this proposal:
>
> If Berin feels the migration can be quick (1 week?) we start a 2.2 repo,
> and let that be the only work that happens for that quick time frame in
> the 2.2 repo. If possible we should all help with aspects of the
> migration so we don't "come home to a strange house" so to speak.
Absolutely. I can outline what would need to be done to the components
so that the Roles file will not be necessary at all. That way you guys
can take care of that detail while I work on the core infrastructure.
>
> If it bogs down, reveals nightmarish problems, etc. we have the option
> of wiping clean, moving on with blocks immediately on ECM and worry
> about the migration later.
True.
>
> In any case, we have to (don't we?) regard the migration off ECM as
> inevitable and a little pain now is better than a lot of pain later. A
> lot of pain now is not better than the same amount of pain later. Which
> case we're in should be apparent if we try the path proposed above.
Fortress does get you further away from a whitebox kernel, and closer to
a more modular system. For more complex things like Cocoon that has customized
ECM a bit, it isn't fully black box yet. We will get there though.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [RT] Separation of Blocks and Avalon
Posted by Geoff Howard <co...@leverageweb.com>.
Stefano Mazzocchi wrote:
>
> On Friday, Oct 10, 2003, at 10:44 Europe/Rome, Ryan Hoegg wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>>
>>> On Friday, Oct 10, 2003, at 09:44 Europe/Rome, Carsten Ziegeler wrote:
>>>
>>>> I'm more and more thinking that we should do one thing after the other:
>>>> first creating our blocks and than moving to fortress or merlin.
>>>> Or the other way round, if someone things that it makes more sense.
>>>> But we should avoid doing both at the same time.
>>>
>>> +10000000
>>>
>> In that case, is it possible to incrementally develop the blocks in
>> the 2.1 repository while Berin works on the container in the
>> soon-to-be 2.2 repository?
>
> Potentially possible, but I wouldn't do it, we need to be able to keep
> the 2.1 tree clean.
>
> Berin, how long would you think it would take you to do the migration?
> do you have a list of things that worry you most?
>
> BTW, why can't we do the migration *after* we implement the blocks?
>
> I mean, we have a system that works and a design that improves. cocoon
> needs block far more than it needs a migration to a more modern avalon
> container.
Well, there is still the hope that a new container will solve some of
our problems for us and the danger that solving them ourselves will make
the migration more painful. I think no one knows whether either will
happen because those who know Avalon best are a little shaky on Cocoon
and vice-versa.
Berin has expressed several times a confidence that the migration to
Fortress could be relatively quick (though apparently he's suffered a
minor back injury and is not completely convinced of his own sanity!).
How about this proposal:
If Berin feels the migration can be quick (1 week?) we start a 2.2 repo,
and let that be the only work that happens for that quick time frame in
the 2.2 repo. If possible we should all help with aspects of the
migration so we don't "come home to a strange house" so to speak.
If it bogs down, reveals nightmarish problems, etc. we have the option
of wiping clean, moving on with blocks immediately on ECM and worry
about the migration later.
In any case, we have to (don't we?) regard the migration off ECM as
inevitable and a little pain now is better than a lot of pain later. A
lot of pain now is not better than the same amount of pain later. Which
case we're in should be apparent if we try the path proposed above.
Geoff
Re: [RT] Separation of Blocks and Avalon
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Stefano Mazzocchi wrote:
> BTW, why can't we do the migration *after* we implement the blocks?
>
> I mean, we have a system that works and a design that improves. cocoon
> needs block far more than it needs a migration to a more modern avalon
> container.
>
> --
> Stefano.
>
This sounds like a good idea, since we seem to have a much more mature
idea of what the blocks implementation entails than the container change.
One reason we might consider a new container first is that it might
simplify the block design. One thread that is still active talks about
how to expose classes to other blocks. This requirement might go away
completely if blocks can access java in other blocks only through the
avalon container, and we decide that any java code the block wants to
provide must be packaged using a standard format.
The risk is that the container upgrade is very complex and time
consuming, causing all the good ideas about blocks to be put on hold.
Of course ultimately the people doing the work will make the decision :)
--
Ryan Hoegg
RE: [RT] Separation of Blocks and Avalon
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> >>
> > In that case, is it possible to incrementally develop the blocks in
> > the 2.1 repository while Berin works on the container in the
> > soon-to-be 2.2 repository?
>
> Potentially possible, but I wouldn't do it, we need to be able to keep
> the 2.1 tree clean.
>
> Berin, how long would you think it would take you to do the migration?
> do you have a list of things that worry you most?
>
> BTW, why can't we do the migration *after* we implement the blocks?
>
> I mean, we have a system that works and a design that improves. cocoon
> needs block far more than it needs a migration to a more modern avalon
> container.
>
Amen :)
Carsten
Re: [RT] Separation of Blocks and Avalon
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Oct 10, 2003, at 10:44 Europe/Rome, Ryan Hoegg wrote:
> Stefano Mazzocchi wrote:
>
>>
>> On Friday, Oct 10, 2003, at 09:44 Europe/Rome, Carsten Ziegeler wrote:
>>
>>> I'm more and more thinking that we should do one thing after the
>>> other:
>>> first creating our blocks and than moving to fortress or merlin.
>>> Or the other way round, if someone things that it makes more sense.
>>> But we should avoid doing both at the same time.
>>
>>
>> +10000000
>>
> In that case, is it possible to incrementally develop the blocks in
> the 2.1 repository while Berin works on the container in the
> soon-to-be 2.2 repository?
Potentially possible, but I wouldn't do it, we need to be able to keep
the 2.1 tree clean.
Berin, how long would you think it would take you to do the migration?
do you have a list of things that worry you most?
BTW, why can't we do the migration *after* we implement the blocks?
I mean, we have a system that works and a design that improves. cocoon
needs block far more than it needs a migration to a more modern avalon
container.
--
Stefano.
RE: [RT] Separation of Blocks and Avalon
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Reinhard Poetz wrote:
> > PLEASE, don't start this discussion over and over again. We
> > have (after
> > a long painful discussion period) decided (or better reassured) that
> > we create a new repository for 2.2. And Stefano wanted to contact
> > infrastructure to create the 2.2 one.
>
> I hope my comment wasn't misleading. I support fully the community
> decision to create new repositories instead of branches and I'm not
> interested in leading this discussion again and again.
>
No, your comment wasn't misleading and as we talked at the GT about
this I know your opinion.
I just want to avoid starting this discussion again, perhaps I
shoudn't have quoted you which had made things clearer. Sorry!
Carsten
RE: [RT] Separation of Blocks and Avalon
Posted by Reinhard Poetz <re...@apache.org>.
From: Carsten Ziegeler
>
> Reinhard Poetz wrote:
> > > > we need the 2.1 repository to be able to do 2.1.x releases.
> > > Otherwise
> > > > we would ship alpha code and I think people building their
> > > > applications upon 2.1 wouldn't be very happy with this.
> > >
> > > That's one reason why CVS has branches.
> >
> > a new branch or a new repository? IIRC we decided *not* to
> create any
> > branches but to create new repositories instead.
> >
>
> PLEASE, don't start this discussion over and over again. We
> have (after
> a long painful discussion period) decided (or better reassured) that
> we create a new repository for 2.2. And Stefano wanted to contact
> infrastructure to create the 2.2 one.
I hope my comment wasn't misleading. I support fully the community
decision to create new repositories instead of branches and I'm not
interested in leading this discussion again and again.
Reinhard
RE: [RT] Separation of Blocks and Avalon
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Reinhard Poetz wrote:
> > > we need the 2.1 repository to be able to do 2.1.x releases.
> > Otherwise
> > > we would ship alpha code and I think people building their
> > > applications upon 2.1 wouldn't be very happy with this.
> >
> > That's one reason why CVS has branches.
>
> a new branch or a new repository? IIRC we decided *not* to create any
> branches but to create new repositories instead.
>
PLEASE, don't start this discussion over and over again. We have (after
a long painful discussion period) decided (or better reassured) that
we create a new repository for 2.2. And Stefano wanted to contact
infrastructure to create the 2.2 one.
Carsten
RE: [RT] Separation of Blocks and Avalon
Posted by Reinhard Poetz <re...@apache.org>.
From: giacomo@lapgp.otego.com
> > > In that case, is it possible to incrementally develop the
> blocks in
> > > the 2.1 repository while Berin works on the container in the
> > > soon-to-be 2.2
> > > repository?
> >
> > -1
> > we need the 2.1 repository to be able to do 2.1.x releases.
> Otherwise
> > we would ship alpha code and I think people building their
> > applications upon 2.1 wouldn't be very happy with this.
>
> That's one reason why CVS has branches.
a new branch or a new repository? IIRC we decided *not* to create any
branches but to create new repositories instead.
Reinhard
RE: [RT] Separation of Blocks and Avalon
Posted by Giacomo Pati <gi...@apache.org>.
On Fri, 10 Oct 2003, Reinhard Poetz wrote:
>
> > From: Ryan Hoegg
> >
> >
> > Stefano Mazzocchi wrote:
> >
> > >
> > > On Friday, Oct 10, 2003, at 09:44 Europe/Rome, Carsten
> > Ziegeler wrote:
> > >
> > >> I'm more and more thinking that we should do one thing after the
> > >> other: first creating our blocks and than moving to fortress or
> > >> merlin. Or the other way round, if someone things that it
> > makes more
> > >> sense. But we should avoid doing both at the same time.
> > >
> > >
> > > +10000000
> > >
> > In that case, is it possible to incrementally develop the
> > blocks in the
> > 2.1 repository while Berin works on the container in the
> > soon-to-be 2.2
> > repository?
>
> -1
> we need the 2.1 repository to be able to do 2.1.x releases. Otherwise we
> would ship alpha code and I think people building their applications
> upon 2.1 wouldn't be very happy with this.
That's one reason why CVS has branches.
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
RE: [RT] Separation of Blocks and Avalon
Posted by Reinhard Poetz <re...@apache.org>.
> From: Ryan Hoegg
>
>
> Stefano Mazzocchi wrote:
>
> >
> > On Friday, Oct 10, 2003, at 09:44 Europe/Rome, Carsten
> Ziegeler wrote:
> >
> >> I'm more and more thinking that we should do one thing after the
> >> other: first creating our blocks and than moving to fortress or
> >> merlin. Or the other way round, if someone things that it
> makes more
> >> sense. But we should avoid doing both at the same time.
> >
> >
> > +10000000
> >
> In that case, is it possible to incrementally develop the
> blocks in the
> 2.1 repository while Berin works on the container in the
> soon-to-be 2.2
> repository?
-1
we need the 2.1 repository to be able to do 2.1.x releases. Otherwise we
would ship alpha code and I think people building their applications
upon 2.1 wouldn't be very happy with this.
Cheers,
Reinhard
Re: [RT] Separation of Blocks and Avalon
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Stefano Mazzocchi wrote:
>
> On Friday, Oct 10, 2003, at 09:44 Europe/Rome, Carsten Ziegeler wrote:
>
>> I'm more and more thinking that we should do one thing after the other:
>> first creating our blocks and than moving to fortress or merlin.
>> Or the other way round, if someone things that it makes more sense.
>> But we should avoid doing both at the same time.
>
>
> +10000000
>
In that case, is it possible to incrementally develop the blocks in the
2.1 repository while Berin works on the container in the soon-to-be 2.2
repository?
Re: [RT] Separation of Blocks and Avalon
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Oct 10, 2003, at 09:44 Europe/Rome, Carsten Ziegeler wrote:
> I'm more and more thinking that we should do one thing after the other:
> first creating our blocks and than moving to fortress or merlin.
> Or the other way round, if someone things that it makes more sense.
> But we should avoid doing both at the same time.
+10000000
> I mean, we are currently happy with ECM - it works, it's stable and the
> only real concern we have is the big cocoon.xconf which is solved with
> blocks anyway. (I don't want to say that fortress/merlin are not stable
> with this).
Amen.
--
Stefano.
RE: [RT] Separation of Blocks and Avalon
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephen McConnell wrote:
>
> The million little details that cocoon assumes on top of ECM is also the
> thing that scares me the most.
>
Me, too. And I'm really wondering if we can keep our nice little additions
if we move away from ECM.
> Is there someone who provide the breakdown of what Cocoon is doing over
> and above ECM? However things roll out - one of the biggest obsticles I
> see is that we need to move away from ECM/Fortress extension and to a
> solution where Cocoon does not need to access container APIs. With that
> information the Avalon crowd can address how to addres these
> requirements in a way that makes the concern indpendent of the container
> implementaiton.
>
We extend the ECM with our CocoonComponentManager, you can have a look
at that class. All the features (hacks?) in there have to be somehow
available using fortress, merlin or whatever.
We have another lifecycle type, the request lifecycle component. This is
an extension to poolable and means that per request only one instance
of this component is used. So if two other components lookup this
request lifecycle component, they get the same instance.
The implementation of this extension is a little bit difficult as we
have sub requests that run in the same thread but have a different
set of request lifecycle components.
In addition it's possible to process on request multi threaded which
makes this even more difficult.
There are some other important extensions like the environment handling
for the source resolver and the sitemap configurable components. They
use more or less the same technique used for the request lifecycle
components.
I'm more and more thinking that we should do one thing after the other:
first creating our blocks and than moving to fortress or merlin.
Or the other way round, if someone things that it makes more sense.
But we should avoid doing both at the same time.
I mean, we are currently happy with ECM - it works, it's stable and the
only real concern we have is the big cocoon.xconf which is solved with
blocks anyway. (I don't want to say that fortress/merlin are not stable
with this).
Carsten
Re: [RT] Separation of Blocks and Avalon
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
>
> On Thursday, Oct 9, 2003, at 17:15 Europe/Rome, Ryan Hoegg wrote:
>
>> Rather than have cocoon blocks extend avalon blocks, I think cocoon
>> blocks could use avalon blocks.
>
>
> Ok, I see your point.
>
>> Instead of having a /COB-INF and a /BLOCK-inf, perhaps we include
>> avalon blocks in /COB-INF/lib and delegate their deployment to the
>> avalon container. This could even allow cocoon blocks to provide
>> avalon blocks to the container, as well as require them.
>
>
> I would not know how to do this! I'm not scared by merlin, I'm scared
> about the million little details that cocoon assumes on top of ECM and
> that are now considered deprecated by the "modern" containers.
The million little details that cocoon assumes on top of ECM is also the
thing that scares me the most.
>
> if Fortress was there, admittedly, things would be easier... but then
> again, lots of talks, but nobody is able, wants or has
> time/energy/braveness to do the migration.
Is there someone who provide the breakdown of what Cocoon is doing over
and above ECM? However things roll out - one of the biggest obsticles I
see is that we need to move away from ECM/Fortress extension and to a
solution where Cocoon does not need to access container APIs. With that
information the Avalon crowd can address how to addres these
requirements in a way that makes the concern indpendent of the container
implementaiton.
>
>> It may help to distinguish between different types of dependencies:
>> 1. Block dependency. As described in
>> http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition and
>> specified in http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring .
>> What we (I think) have been talking about in several threads.
>> 2a. Avalon dependency by block. This would be some avalon
>> service/component that is required by the block, and would be
>> explicitly declared. An example might be a Transformer or the Flow
>> engine.
>> 2b. Avalon dependency by avalon block/component/service. This would
>> be some avalon service that is required by an avalon service or block
>> that is included with the cocoon block. For example, I have a
>> UserManager service that depends on a UserRepository service, which
>> could be implemented by an OJBUserRepository. If the cocoon block
>> included the UserManager block, it might ask the Parent Component
>> Manager for a UserManager, and might be provided with the
>> OJBUserRepository.
>
>
> I fear the complexity of such a move.
Break the complexity down into managable chunks.
1. migrate from Component to Object
2. migrate from roles files to meta
Just achiving the above opens up a much broader spectrum of
possibilities and the question become much more concrete and substantive
(from both sides of the equation). We have been discussing this over on
Avalon land - subjects such as transition vehicles, migration tools,
etc. these are way up on the agenda.
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: [RT] Separation of Blocks and Avalon
Posted by Stefano Mazzocchi <st...@apache.org>.
On Thursday, Oct 9, 2003, at 17:15 Europe/Rome, Ryan Hoegg wrote:
> Rather than have cocoon blocks extend avalon blocks, I think cocoon
> blocks could use avalon blocks.
Ok, I see your point.
> Instead of having a /COB-INF and a /BLOCK-inf, perhaps we include
> avalon blocks in /COB-INF/lib and delegate their deployment to the
> avalon container. This could even allow cocoon blocks to provide
> avalon blocks to the container, as well as require them.
I would not know how to do this! I'm not scared by merlin, I'm scared
about the million little details that cocoon assumes on top of ECM and
that are now considered deprecated by the "modern" containers.
if Fortress was there, admittedly, things would be easier... but then
again, lots of talks, but nobody is able, wants or has
time/energy/braveness to do the migration.
> It may help to distinguish between different types of dependencies:
> 1. Block dependency. As described in
> http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition and specified
> in http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring . What we (I
> think) have been talking about in several threads.
> 2a. Avalon dependency by block. This would be some avalon
> service/component that is required by the block, and would be
> explicitly declared. An example might be a Transformer or the Flow
> engine.
> 2b. Avalon dependency by avalon block/component/service. This would
> be some avalon service that is required by an avalon service or block
> that is included with the cocoon block. For example, I have a
> UserManager service that depends on a UserRepository service, which
> could be implemented by an OJBUserRepository. If the cocoon block
> included the UserManager block, it might ask the Parent Component
> Manager for a UserManager, and might be provided with the
> OJBUserRepository.
I fear the complexity of such a move.
> 2b is the situation in which I think we could leverage the work being
> done by the various avalon containers. We would not have to
> explicitly define transitive avalon dependencies, as the avalon
> container can infer those from the avalon block that we give to it.
True and what you describe is a sane and balanced proposal.
I just think that we should keep going with the design with have and
with the use of the component model that we are used to and move on
incrementally.
The machinery required to implement a component manager that is
block-aware is very simple, probably a few lines on top of what we
already have. even classloading should be trivial since dependencies
are explicit.
but changing the way cocoon works in respect of component model, well,
that's touching every single class!!! most of the cocoon developers are
scared by this (me included), as this is the main reason why it didn't
happen yet.
I'm willing to implement blocks, even if this means to rewrite some
code that is already somewhere else. I might be wrong, but the
implementation should be relatively easy (Sylvain and I discussed
things in detail).
But moving from ECM to Fortress and from Fortress to Merlin for the
entire cocoon component model? well, that scares the crap out of me in
terms of number of lines of code to modify and potential bugs to
introduce.
But if someone more knowledgble wants to do the transition, I'd be more
than happy to be proven wrong and have cocoon move to a technology that
is supported actively and not considered obsolete by the community
around it.
Note, also, that your proposal is orthogonal to the implementation of
cocoon blocks: today we use ECM and we keep use the same approach for
java components provided by the cocoon blocks.
if in the future we change to a different java component model, we
change it everywhere, including blocks.
if the migration is painless for cocoon own components (as it should
be), it will be for blocks too.
the two things are, IMO, independent and can happen at different times.
--
Stefano.
Re: [RT] Separation of Blocks and Avalon
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Stefano Mazzocchi wrote:
> On Wednesday, Oct 8, 2003, at 19:22 Europe/Rome, Ryan Hoegg wrote:
>
>> Hi,
>>
>> I've been following the block design discussion and wiki evolution
>> with great interest for a couple months now (blame Geoff). Blocks
>> look wonderful, and I can't wait to develop my cocoon based
>> applications as blocks.
>>
>> I have a concern about the bundling of exposed avalon services with
>> blocks. Specifically, in the recent thread about "Finishing the
>> First Phase of Block Design" and on
>> http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition I see some
>> duplicated effort. As Stephen McConnell noticed, some of this
>> functionality is already built, tested, and maintained in several
>> avalon containers. Why not package avalon blocks/services/components
>> in the way the container expects, and include them somewhere like
>> /COB-INF/lib or /COB-INF/public/lib? Or, even cleaner separation can
>> be had in some cases by deploying them to the avalon container
>> independently.
>>
>> If things are done this way, the problem noted in the thread I
>> mentioned above could be completely avoided. There would be no need
>> to expose classes through the block interface because all java would
>> be exposed as avalon services.
>> I think this would simplify the block design greatly, and allow us to
>> focus on cocoon-specific aspects.
>
>
> Let me see if I get this right: you are proposing that we make cocoon
> blocks
> somewhat extend avalon blocks and we have /block-inf/ for information
> on the java components and /cob-inf/ for all the remainding
> cocoon-specific things, in order to be able to reuse existing avalon
> code?
>
> But how can I describe dependencies if one part uses implicit ones and
> the rest uses explicit ones?
>
> --
> Stefano.
>
Rather than have cocoon blocks extend avalon blocks, I think cocoon
blocks could use avalon blocks. Instead of having a /COB-INF and a
/BLOCK-inf, perhaps we include avalon blocks in /COB-INF/lib and
delegate their deployment to the avalon container. This could even
allow cocoon blocks to provide avalon blocks to the container, as well
as require them.
It may help to distinguish between different types of dependencies:
1. Block dependency. As described in
http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition and specified
in http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring . What we (I
think) have been talking about in several threads.
2a. Avalon dependency by block. This would be some avalon
service/component that is required by the block, and would be explicitly
declared. An example might be a Transformer or the Flow engine.
2b. Avalon dependency by avalon block/component/service. This would be
some avalon service that is required by an avalon service or block that
is included with the cocoon block. For example, I have a UserManager
service that depends on a UserRepository service, which could be
implemented by an OJBUserRepository. If the cocoon block included the
UserManager block, it might ask the Parent Component Manager for a
UserManager, and might be provided with the OJBUserRepository.
2b is the situation in which I think we could leverage the work being
done by the various avalon containers. We would not have to explicitly
define transitive avalon dependencies, as the avalon container can infer
those from the avalon block that we give to it.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: [RT] Separation of Blocks and Avalon
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Oct 8, 2003, at 19:22 Europe/Rome, Ryan Hoegg wrote:
> Hi,
>
> I've been following the block design discussion and wiki evolution
> with great interest for a couple months now (blame Geoff). Blocks
> look wonderful, and I can't wait to develop my cocoon based
> applications as blocks.
>
> I have a concern about the bundling of exposed avalon services with
> blocks. Specifically, in the recent thread about "Finishing the First
> Phase of Block Design" and on
> http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition I see some
> duplicated effort. As Stephen McConnell noticed, some of this
> functionality is already built, tested, and maintained in several
> avalon containers. Why not package avalon blocks/services/components
> in the way the container expects, and include them somewhere like
> /COB-INF/lib or /COB-INF/public/lib? Or, even cleaner separation can
> be had in some cases by deploying them to the avalon container
> independently.
>
> If things are done this way, the problem noted in the thread I
> mentioned above could be completely avoided. There would be no need
> to expose classes through the block interface because all java would
> be exposed as avalon services.
> I think this would simplify the block design greatly, and allow us to
> focus on cocoon-specific aspects.
Let me see if I get this right: you are proposing that we make cocoon
blocks
somewhat extend avalon blocks and we have /block-inf/ for information
on the java components and /cob-inf/ for all the remainding
cocoon-specific things, in order to be able to reuse existing avalon
code?
But how can I describe dependencies if one part uses implicit ones and
the rest uses explicit ones?
--
Stefano.