Leo Simons wrote:
Berin Loritsch wrote:
_It has already been taken care of_
just because it is possible and advisable for cocoon to remove the
reference to Component from their sources doesn't mean we should push
them or our other users into doing so. What about picking a current
cocoon binary release and replacing the avalon-framework binary in there
(or perhaps I always put avalon into my tomcat and jbuilder lib/ dir and
so that overrides the classes in cocoon, and I get a deprecation warning
all the time)? Not taken care of.
Heck, there's an important avalon-using project asking for the removal
of a few '@' characters in the avalon-framework javadocs, and they have
a reasonably good reason (confused users).
Why put your foot down on this? I see zero benefit and unhappy faces
(well, imagined unhappy faces).
My foot is not down. I needed to see where the technical flaw was in
the solution we chose for upgrading Avalon based containers. Today
we had some arguments that do make sense. I still think that the
direness of removing the Component interface is not nearly as bad
as the Cocoon folks would have use believe, but they do have a point.
To make my position clear, I am not now, nor have I ever advocated
removing the Component interface from the Avalon Framework JAR.
I only advocated removing it from the interfaces of the Generator,
et. al.
To help clarify the issue even more, the problem is *not* with the
component writers. People who are writing components won't need
or want to implement the Component interface. They won't even really
need to acknowledge its existence. The issue is with Container
writers. Folks who write containers for Cocoon blocks, etc. might
experience some problems. Especially those that are outside our
control.
Nevertheless, to help the Cocooners in their goal, we have to
consider the removal of the deprecation warning as a Javadoc,
and change its representation to the user.
Armed with the information here, I will make the official vote
to change the @deprecation to another form of marking it
deprecated. If we have consensus, the next version of Framework
will have the classes marked as out of favor but not using the
@deprecated tag.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
