cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: Getting rid of deprecated Interfaces/Classes/Methods
Date Fri, 27 Sep 2002 19:52:08 GMT

Ok, this thread had made alot of people think about it and the conclusion
is that we should not switch to a newer/better container at least until a
2.1 release is out, right?

I've allready commited the step 1 (Loggable -> LogEnabled).

Now I'm on step 2 (as there has not been any -1). This can be done while
we stay with ECM for now and have still backward compatability for all
custom Components somebody has around for his private projects.

But I have some questions about this move. We have classes named after
the deprecated Interfaces (ie. CocoonComponentManger, ComposerAction). I'd
like to hear your suggestion how we should deal with those:

1. don't change the names
2. rename them to appropriate names like CocoonServiceManager
3. create new one and deprecate the old ones

What is your oppinion?


On Mon, 23 Sep 2002, Giacomo Pati wrote:

> Hi Team
> I'll have some spare time this week and thought of moving the HEAD branch
> away from deprecated stuff from newest Avalon Framework/Excalibur jars.
> My plan will be:
>    1.  Get rid of Loggable in favor of LogEnabled
>    2.  Get rid of Component and move to Service infrastructure
> 1. is straight forward and doesn't need any voting I think
> 2. can be done in two steps:
>    a. move from Component to Service infrastructure as the
> ExcaliburComponentManager supports this.
>    b. use Fortress/Merlin (don't know the status of those and which one
> makes more sense for Cocoon to be used, so I need some advice of
> Avalonians here)
> Ok, can those of you more familiar with Fortress/Merlin (Berin?) give some
> status about those ServiceManagers and also a suggestion to move the b.
> step or to postpone it for later because of the status of hose
> ServiceManagers?
> I know using one of these ServiceManagers means rewriting the
> configuration files and/or use additional tools like phoenix-xdoclet
> NB: why is that tool so phoenix specific? Should be a avalon-doclet more
> appropriate or have I missed some discussion on Avalonland?
> What are the drawbacks I will face?
> What do I have missed in my reflections?
> Giacomo
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message