You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/02/01 19:47:59 UTC
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Nicola Ken Barozzi wrote:
>
> Peter Donald wrote:
>
>> On Thu, 30 Jan 2003 08:05, Leo Sutic wrote:
>>
>>> I'd just like to see what you in Avalon-dev have to say about this:
>>
>>
>>
>> Update Cocoon to latest Avalon code and remove Component from the
>> Cocoon codebase (A 30 min job?) and the deprecation warnings will go
>> away.
Right.
> We have to provide full backward compatibility in 2.x series; all
> Components and Composables must be honored; core interfaces like
> Generator, Transformer, Serializer all extend Component and this can not
> be changed.
Keep in mind the following:
#1 The Composables *will* be honored.
#2 The Component interface does *not* add any functionality. It can
also be added _dynamically_.
#3 We can safely remove the Component interface (the source for most
deprecation warnings).
#4 We can move to using the Serviceable components instead of the
Composables so that all _Cocoon_ code can properly mark deprecation
on components itself without any deprecations comming from the Avalon
code.
All this can be done with the current CVS version of ECM and Fortress.
Currently it requires JRE 1.3 or higher. If JRE 1.3 is unnacceptable,
then *please* let us know, and we will make ECM 1.2 compatible by using
the CGLIB library with a drop in replacement for JRE 1.3 dynamic
proxies.
>
> This will make sense for 3.0.
It even makes sense in the real short term. As soon as ECM is released,
you will be able to use the *same* code, and not worry about the
Component/Composable interfaces. THey *will* be supported.
>
> As Vadim pointed outm, OTOH, timing for such changes is really not good
> - we just have 3 books published recently.
And another one that should be done around April (for Avalon and
component oriented programming).
>
> From an engineering POV removing @deprecated sucks. But it's also true
> that from a user perspective, having deprecation warnings on core Cocoon
> components, ant that is all of them simce we use Avalon heavily, sucks
> even more.
The user won't have to worry about them.
>
> I'm mildly in favor of removing the @deprecation tag and putting it in
> the docs, but I'm not sure either.
>
I'm not. We just need an ECM released RSN. THe Avalon team is putting
together releases for everything. We just need to know if it is
acceptable with the Cocoon folks if JRE 1.3 is the minimum or not.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Berin Loritsch <bl...@apache.org>.
Vadim Gritsenko wrote:
> Berin Loritsch wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Berin,
>>>
>>> Please see example sent in response to Ken's question:
>>>
>>> Generator g;
>>> Component c = g;
>>>
>>> This *will* fail to compile.
>>
>
>
>> However, when would this ever happen?
>
>
> When, say, you happen to collect components in an array. Or see below.
How about an array of Objects? It works just as well. Although if it
is an array that will be used at runtime, a fully typed aray is better.
>> Who ever goes from an interface with methods to one without methods?
>
> Avalon does ;-)
> Or any avalon-like code, like CocoonComponentManager (which means
> chances are there is MyCompanyComponentManager somewhere out there).
Well in Avalon they go to Object, not Component.
>> This only seems to be an accademic issue, and not a real world code
>> example.
>
>
>
> Berin, that was you who taught us to work hard to keep backward
> compatibility. It should be you who should argue on this point instead
> of me! But if you want to go down the road of "academic" and "practical"
> backward compatibility, then I rest my case.
And I am trying to point out that we have a backwards compatible
approach that allows for a smooth migration from not needing the
Component interface.
All expected uses of the Component interface have been accounted
for.
Yes we should try to keep backwards compatibility. You can go crazy
trying to think of every bastardization of the accepted use and corner
yourself into ineffectualness.
>> IOW, what does it buy you to perform the bad code snippet above?
>>
>> For all practical and real requirements, it is safe to remove the
>> Component interface from the Generator interface, et. al.
>>
>> Upgrading to Fortress or the CVS version of ECM, and then removing
>> the Component interface from the core interfaces should give you
>> the piece of mind that everything should compile and run.
>>
>> Try it as an experiment.
>
>
>
> I'm planning to. Really. When fortress is "ready" - or, better one -
> when beta release is due?
> But do not complain when it breaks compilation of your favorite client's
> code ;-)
It *shouldn't*.
I have not had any problems to date.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Vadim Gritsenko <va...@verizon.net>.
Berin Loritsch wrote:
> Vadim Gritsenko wrote:
>
>> Berin,
>>
>> Please see example sent in response to Ken's question:
>>
>> Generator g;
>> Component c = g;
>>
>> This *will* fail to compile.
>
>
> Of course if it was written explicitly like a good programmer should,
> it would compile:
>
> Generator g = // ... lookup of Generator
> Comonent c = (Component) g;
I guess you know that modern IDEs do not appreciate this code style
(unnecessary class cast). And after removing Component from Generator
and all implementing classes (you are not in favour of keeping
deprecated interface there, are you? the whole point was in reducing
amount of deprecations) this will become dangerous class cast.
> However, when would this ever happen?
When, say, you happen to collect components in an array. Or see below.
> Who ever goes from an interface with methods to one without methods?
Avalon does ;-)
Or any avalon-like code, like CocoonComponentManager (which means
chances are there is MyCompanyComponentManager somewhere out there).
> This only seems to be an accademic issue, and not a real world code
> example.
Berin, that was you who taught us to work hard to keep backward
compatibility. It should be you who should argue on this point instead
of me! But if you want to go down the road of "academic" and "practical"
backward compatibility, then I rest my case.
> IOW, what does it buy you to perform the bad code snippet above?
>
> For all practical and real requirements, it is safe to remove the
> Component interface from the Generator interface, et. al.
>
> Upgrading to Fortress or the CVS version of ECM, and then removing
> the Component interface from the core interfaces should give you
> the piece of mind that everything should compile and run.
>
> Try it as an experiment.
I'm planning to. Really. When fortress is "ready" - or, better one -
when beta release is due?
But do not complain when it breaks compilation of your favorite client's
code ;-)
PS If any part of this email sounds offensive it means I have to take
english classes ;-)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Berin Loritsch <bl...@apache.org>.
Vadim Gritsenko wrote:
> Berin Loritsch wrote:
>
>> Vadim Gritsenko wrote:
>>
>> > Berin Loritsch wrote:
>> >
>> >> #3 We can safely remove the Component interface (the source for most
>> >> deprecation warnings).
>> >
>> >
>> > I'm trying to be cautious about removing it from public well-known
>> interfaces. Users are writing code with assumption that they won't
>> change, but once you remove Component interface from, say, Generator,
>> it means user's code won't compile anymore without change.
>>
>>
>> What do you mean it won't compile anymore without change?
>
>
>
> Berin,
>
> Please see example sent in response to Ken's question:
>
> Generator g;
> Component c = g;
>
> This *will* fail to compile.
Of course if it was written explicitly like a good programmer should,
it would compile:
Generator g = // ... lookup of Generator
Comonent c = (Component) g;
However, when would this ever happen? Who ever goes from an interface
with methods to one without methods? This only seems to be an accademic
issue, and not a real world code example.
IOW, what does it buy you to perform the bad code snippet above?
For all practical and real requirements, it is safe to remove the
Component interface from the Generator interface, et. al.
Upgrading to Fortress or the CVS version of ECM, and then removing
the Component interface from the core interfaces should give you
the piece of mind that everything should compile and run.
Try it as an experiment.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Vadim Gritsenko <va...@verizon.net>.
Stefano Mazzocchi wrote:
> Vadim Gritsenko wrote:
>
>> PS As JDK1.2 Poll goes, nobody reported to be using Cocoon with JDK
>> 1.2 so far... Let's wait till the end of the week.
>
>
> Shouldn't we ask *users* instead of developers?
We've asked on cocoon-users. :)
Who else shall we ask?
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
...
>> PS As JDK1.2 Poll goes, nobody reported to be using Cocoon with JDK
>> 1.2 so far... Let's wait till the end of the week.
>
> Shouldn't we ask *users* instead of developers?
We did, they are already replying.
Only one IIUC is still using 1.2 till now.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Stefano Mazzocchi <st...@apache.org>.
Vadim Gritsenko wrote:
> Berin Loritsch wrote:
>
>> Vadim Gritsenko wrote:
>>
>> > Berin Loritsch wrote:
>> >
>> >> #3 We can safely remove the Component interface (the source for most
>> >> deprecation warnings).
>> >
>> >
>> > I'm trying to be cautious about removing it from public well-known
>> interfaces. Users are writing code with assumption that they won't
>> change, but once you remove Component interface from, say, Generator,
>> it means user's code won't compile anymore without change.
>>
>>
>> What do you mean it won't compile anymore without change?
>
>
>
> Berin,
>
> Please see example sent in response to Ken's question:
>
> Generator g;
> Component c = g;
>
> This *will* fail to compile.
>
>
> PS As JDK1.2 Poll goes, nobody reported to be using Cocoon with JDK 1.2
> so far... Let's wait till the end of the week.
Shouldn't we ask *users* instead of developers?
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine neccesitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Vadim Gritsenko <va...@verizon.net>.
Berin Loritsch wrote:
> Vadim Gritsenko wrote:
>
> > Berin Loritsch wrote:
> >
> >> #3 We can safely remove the Component interface (the source for most
> >> deprecation warnings).
> >
> >
> > I'm trying to be cautious about removing it from public well-known
> interfaces. Users are writing code with assumption that they won't
> change, but once you remove Component interface from, say, Generator,
> it means user's code won't compile anymore without change.
>
>
> What do you mean it won't compile anymore without change?
Berin,
Please see example sent in response to Ken's question:
Generator g;
Component c = g;
This *will* fail to compile.
PS As JDK1.2 Poll goes, nobody reported to be using Cocoon with JDK 1.2
so far... Let's wait till the end of the week.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Berin Loritsch <bl...@apache.org>.
Vadim Gritsenko wrote:
> Berin Loritsch wrote:
>
>> #3 We can safely remove the Component interface (the source for most
>> deprecation warnings).
>
>
>
>
> I'm trying to be cautious about removing it from public well-known
interfaces. Users are writing code with assumption that they won't
change, but once you remove Component interface from, say, Generator, it
means user's code won't compile anymore without change.
What do you mean it won't compile anymore without change?
Of course it will. You can remove interfaces at will. If the class
still implements all the methods that are part of that interface, the
class will still compile.
The Component class is *still part* of the Framework JAR. It isn't
going away until the Avalon 5.0 release which won't be here for quite
a while.
Do a little experiment. Have an interface that implements Serializable,
which is also a marker interface. Now have a class that implements the
new interface. Next remove the Serializable interface from the new
interface. Recompile. Hmmm. The class still compiles.
The only time you are going to have a compile time problem is when
the original interface is removed completely from the classpath.
That is not happening.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Vadim Gritsenko <va...@verizon.net>.
Vadim Gritsenko wrote:
> Nicola Ken Barozzi wrote:
>
>>
>> Vadim Gritsenko wrote:
>>
>>> Berin Loritsch wrote:
>>>
>>>> #3 We can safely remove the Component interface (the source for most
>>>> deprecation warnings).
>>>
>>>
>>>
>>> I'm trying to be cautious about removing it from public well-known
>>> interfaces. Users are writing code with assumption that they won't
>>> change, but once you remove Component interface from, say,
>>> Generator, it means user's code won't compile anymore without change.
>>
>>
>>
>> Can you please post a code example about this? I'm a bit confused...
>
>
>
> Sure... Here it is:
>
> Component c = ((ComponentSelector)manager.lookup(Generator.ROLE +
> "Selector")).select("something");
Or this one, is even better:
Generator g = null;
Component c = g;
See also recent thread "what is parser" - seems like changes are already
affecting existing code.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Vadim Gritsenko <va...@verizon.net>.
Nicola Ken Barozzi wrote:
>
> Vadim Gritsenko wrote:
>
>> Berin Loritsch wrote:
>>
>>> #3 We can safely remove the Component interface (the source for most
>>> deprecation warnings).
>>
>>
>> I'm trying to be cautious about removing it from public well-known
>> interfaces. Users are writing code with assumption that they won't
>> change, but once you remove Component interface from, say, Generator,
>> it means user's code won't compile anymore without change.
>
>
> Can you please post a code example about this? I'm a bit confused...
Sure... Here it is:
Component c = ((ComponentSelector)manager.lookup(Generator.ROLE +
"Selector")).select("something");
Vadim
> Thanks :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Vadim Gritsenko wrote:
> Berin Loritsch wrote:
>
>> #3 We can safely remove the Component interface (the source for most
>> deprecation warnings).
>
> I'm trying to be cautious about removing it from public well-known
> interfaces. Users are writing code with assumption that they won't
> change, but once you remove Component interface from, say, Generator, it
> means user's code won't compile anymore without change.
Can you please post a code example about this? I'm a bit confused...
Thanks :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Vadim Gritsenko <va...@verizon.net>.
Berin Loritsch wrote:
> #3 We can safely remove the Component interface (the source for most
> deprecation warnings).
I'm trying to be cautious about removing it from public well-known
interfaces. Users are writing code with assumption that they won't
change, but once you remove Component interface from, say, Generator, it
means user's code won't compile anymore without change.
...
> We just need to know if it is
> acceptable with the Cocoon folks if JRE 1.3 is the minimum or not.
Let's see results of the poll...
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Berin Loritsch <bl...@apache.org>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Berin Loritsch <bl...@apache.org>.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Leo Simons <le...@apache.org>.
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).
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
> Nicola Ken Barozzi wrote:
> >
> > Berin Loritsch wrote:
> >
> >> Nicola Ken Barozzi wrote:
> >>
> >> >
> >> > Berin Loritsch wrote:
> >> >
> >> >
> >> > What about all the client code that checks for Component and won't
> >> find it in the Cocoon components, and the ones that extend Cocoon
> >> components?
> >>
> >>
> >> It won't break compilation. Cocoon component interfaces extend the
> >> (Component) interface so all the clients have to do to release is
> >> m_manager.release(foo);
> >
> >
> > You lost me here.
> >
> > We want to remove depecation warnings. Or we remove @deprecated, or we
> > remove Component from the Cocoon component interfaces.
> >
> > If we do the latter, as Vadim points out, this is not going to work for
> > our users:
> >
> > Component c = ((ComponentSelector)manager.lookup(Generator.ROLE +
> > "Selector")).select("something");
> >
> > Basically all the code that casts to Component will stop working.
> >
> > I'm trying to see all the tradeoffs.
> >
>
> Not if we create a proxy.
>
> The ECM and FOrtress et. al. will continue working.
>
>
> The Component interface is added at runtime, and the Composable
> interface is supported by creating a proxy that implements the Component
> interface.
>
> Do a little experiment.
>
>
> 1) Upgrade the ECM used in Cocoon.
> 2) Remove the "implements Component" from the Generator interface.
> 3) Run Cocoon.
>
> BAM!
>
> It still works.
>
> _It has already been taken care of_
what about the thousands of user-written components out there who are
*NOT* controlled by us?
those will stop working if not recompiled. binary compatibility is lost.
that will force us to call the next release of Cocoon 3.0 because the
binary components that expect Component will *NOT* work out of the box.
and we *DO*NOT* want to break binary back compatibility just because
Avalon decided it's more *elegant* to do so.
All we ask is a smoother transition period.
We *will* make an effort to follow the path of removing the need for
Component, but given our massive inertia (something that avalon doesn't
have) we can't do it overnight as you ask without *major* impact.
Forcing us to break user code is not a win for us.
On the other hand, what we ask is to be more *tollerant* on past usages
of the frameworks and start deprecating them seriously on 5.x where back
incompatibility will be reflected in the name.
what avalon ask cocoon to do breaks its users code, what cocoon ask
avalon to do doesn't.
I think it's time for avalon to grow up as a project and consider
community dynamics more than pure technological value.
why? because the first builds best-of-breed technology slower, but
stronger communities. the second builds great technology but those
doesn't survive the persons promoting them.
the future of this project depends more on its attitude toward users
than to its technological merits.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine neccesitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Berin Loritsch <bl...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Berin Loritsch wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>> >
>> > Berin Loritsch wrote:
>> >
>> >
>> > What about all the client code that checks for Component and won't
>> find it in the Cocoon components, and the ones that extend Cocoon
>> components?
>>
>>
>> It won't break compilation. Cocoon component interfaces extend the
>> (Component) interface so all the clients have to do to release is
>> m_manager.release(foo);
>
>
> You lost me here.
>
> We want to remove depecation warnings. Or we remove @deprecated, or we
> remove Component from the Cocoon component interfaces.
>
> If we do the latter, as Vadim points out, this is not going to work for
> our users:
>
> Component c = ((ComponentSelector)manager.lookup(Generator.ROLE +
> "Selector")).select("something");
>
> Basically all the code that casts to Component will stop working.
>
> I'm trying to see all the tradeoffs.
>
Not if we create a proxy.
The ECM and FOrtress et. al. will continue working.
The Component interface is added at runtime, and the Composable
interface is supported by creating a proxy that implements the Component
interface.
Do a little experiment.
1) Upgrade the ECM used in Cocoon.
2) Remove the "implements Component" from the Generator interface.
3) Run Cocoon.
BAM!
It still works.
_It has already been taken care of_
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
> Nicola Ken Barozzi wrote:
>
> >
> > Berin Loritsch wrote:
> >
> >
> > What about all the client code that checks for Component and won't
> find it in the Cocoon components, and the ones that extend Cocoon
> components?
>
>
> It won't break compilation. Cocoon component interfaces extend the
> (Component) interface so all the clients have to do to release is
> m_manager.release(foo);
You lost me here.
We want to remove depecation warnings. Or we remove @deprecated, or we
remove Component from the Cocoon component interfaces.
If we do the latter, as Vadim points out, this is not going to work for
our users:
Component c = ((ComponentSelector)manager.lookup(Generator.ROLE +
"Selector")).select("something");
Basically all the code that casts to Component will stop working.
I'm trying to see all the tradeoffs.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Berin Loritsch <bl...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Berin Loritsch wrote:
>
>
> What about all the client code that checks for Component and won't
find it in the Cocoon components, and the ones that extend Cocoon
components?
It won't break compilation. Cocoon component interfaces extend the
(Component) interface so all the clients have to do to release is
m_manager.release(foo);
>> And another one that should be done around April (for Avalon and
>> component oriented programming).
>
>
>
> Then it's even worse! ;-)
Yep, but it doesn't even mention the Component and Composable
classes.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Re-precating (?) classes (was: RE: What is a Parser?)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
> Nicola Ken Barozzi wrote:
>
>>
>> Peter Donald wrote:
>>
>>> On Thu, 30 Jan 2003 08:05, Leo Sutic wrote:
>>>
>>>> I'd just like to see what you in Avalon-dev have to say about this:
>>>
>>> Update Cocoon to latest Avalon code and remove Component from the
>>> Cocoon codebase (A 30 min job?) and the deprecation warnings will go
>>> away.
>
> Right.
>
>> We have to provide full backward compatibility in 2.x series; all
>> Components and Composables must be honored; core interfaces like
>> Generator, Transformer, Serializer all extend Component and this can
>> not be changed.
>
> Keep in mind the following:
>
> #1 The Composables *will* be honored.
> #2 The Component interface does *not* add any functionality. It can
> also be added _dynamically_.
> #3 We can safely remove the Component interface (the source for most
> deprecation warnings).
> #4 We can move to using the Serviceable components instead of the
> Composables so that all _Cocoon_ code can properly mark deprecation
> on components itself without any deprecations comming from the Avalon
> code.
What about all the client code that checks for Component and won't find
it in the Cocoon components, and the ones that extend Cocoon components?
> All this can be done with the current CVS version of ECM and Fortress.
> Currently it requires JRE 1.3 or higher. If JRE 1.3 is unnacceptable,
> then *please* let us know, and we will make ECM 1.2 compatible by using
> the CGLIB library with a drop in replacement for JRE 1.3 dynamic
> proxies.
You'll have to ask cocoon-dev ;-)
I'm personally in favor of keeping 1.2 compat unless impossible. Don't
know if Cocoon now can really still compile with 1.2 though.
>> This will make sense for 3.0.
>
> It even makes sense in the real short term. As soon as ECM is released,
> you will be able to use the *same* code, and not worry about the
> Component/Composable interfaces. They *will* be supported.
Actually, I'd like to see the upgrade to Fortress, it seems many are
interested.
>> As Vadim pointed outm, OTOH, timing for such changes is really not
>> good - we just have 3 books published recently.
>
> And another one that should be done around April (for Avalon and
> component oriented programming).
Then it's even worse! ;-)
>> From an engineering POV removing @deprecated sucks. But it's also
>> true that from a user perspective, having deprecation warnings on core
>> Cocoon components, ant that is all of them simce we use Avalon
>> heavily, sucks even more.
>
> The user won't have to worry about them.
>
>> I'm mildly in favor of removing the @deprecation tag and putting it in
>> the docs, but I'm not sure either.
>
> I'm not. We just need an ECM released RSN. THe Avalon team is putting
> together releases for everything. We just need to know if it is
> acceptable with the Cocoon folks if JRE 1.3 is the minimum or not.
Ok. Please lead in this, I will follow.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org