You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by David BERNARD <dw...@freesurf.fr> on 2002/04/09 16:14:51 UTC
deprecated api (ex : Loggable...)
Hi,
I've studied Avalon family in september 2001, and I can't use it in
project due to api coherence. After some time I want to used it again
because there official "release" and documentation have been updated,
and I think avalon is very good (philosophy, approch...).
But in a "release", there are again incoherence :
- incoherence between documentation and released api,
- from scratch application need to use deprecated classes or methods
like ECM.
Why ?
* backwards compatibility, like wrote Berin (2002/02/08) :
> The Loggable interface is freshly deprecated, we cannot simply drop it
> from the face of the earth.
>
> ExcaliburComponentManager and friends are *not* deprecated.
> Using them will definitely cause deprecation warnings in the interim,
> but that is the price to pay for backwards compatibility.
I'm not OK. If a developper use :
- a released version : backwards compatibility is need if he wants
to upgrade. And he wants to upgrade for :
- used new features then he is potentialy alright to update his code.
(no need of backwards compatibility, it's the price of the update)
- updated libraries dependancy to be ok with runtime context.
- bug fixes, but in this case when he find a bug,
he doesn't know when fixe will be published or released so he code
himself the patch, use other librairies or extract new version
of the classes in the CVS tree.
(no need of backwards compatibility, it's the price of the update)
- a nightly version :
- he used a specified version, he use it like a "release" one.
- he updates periodicly, then he knows that api are unstable.
(no need of backwards compatibility)
So the need of backwards compatibility, isn't a hight priority. And It's
dangerous for new project, see the M$ Windows experience. For the moment
there aren't lot of application based on Avalon/Excalibur but new
project team can be frightened by the obligation to use deprecated api
like ECM.
> I am still working on the replacement technology
> I am alot closer than I was, but still not all the way there yet.
> Once done with the ContainerManager and friends, if we are happy with
> that, we can talk about deprecating the ECM and friends.
Then my conclusion, he is you loose interested user of the avalon.
Because newbies developper or new project can't find a coherent api in
"released" version (librairies + documentation).
I suggest :
- to release more often (minor or macro) version.
- to apply depredecated api recursively
(if a method uses a deprecated Class the it's deprecated)
- to provide alternatives to all deprecated api.
- to remove deprecated api every 2 or 3 minor release.
- to have 2 sites (librairies + documentation(changes, api, tutorials,
overviews...)) :
- site for "Release version", where you can add an API changes
rubrique (see JDiff http://jdiff.sf.net) whith the diff between
succesives releases
- site for "nightly version", where you have access to cvs,
nightly snapshot, new documentation, proposed orientation...
PS : I've got some time this month if you want help (to update code or
documentation (in this case I only see mistake, sorry for my english),
...).
--
--------------------------------------------------------------
David "Dwayne" Bernard Freelance Developer (Java)
mailto:dwayne@java-fan.com
\|/ http://dwayne.java-fan.com
--o0O @.@ O0o-------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: deprecated api (ex : Loggable...)
Posted by Berin Loritsch <bl...@apache.org>.
David BERNARD wrote:
>>>Then my conclusion, he is you loose interested user of the avalon.
>>>Because newbies developper or new project can't find a coherent api in
>>>"released" version (librairies + documentation).
>>>I suggest :
>>>- to release more often (minor or macro) version.
>>
>>I am in favor of releasing more often. We do need to finish our
>>restructuring of the Excalibur build before we can make that release
>>happen.
>>
>>
>>
>>>- to apply depredecated api recursively
>>> (if a method uses a deprecated Class the it's deprecated)
>>
>>In the case of ECM, I *could* have forced the upgrade, but then users
>>who had an investment in Loggable components would be left high and
>>dry.
>
>
> Which users ?
> Not the users of a "released" version.
Sure, but when we release, we have to have a smooth upgrade path. The
backwards compatibility stuff ensures that. It is easier to apply
immediately than retrofit after the fact.
> Users of the nightly want to be uptodate and use the last
> recommendations or concepts and are OK to pay the price.
They know the risks, yes. However, our nightlys are a march toward
another release.
>
> But newbies who read the last api and framework are confused by the mixe
> of informations. By exemple in a other project I use Cocoon, I want my
> team study Avalon to understand better Cocoon, but I can't, because the
> management of Log is different.
>
> I think there is a probleme in the targetted audience.
They are? that's news to me.
>
>
>> Instead we provide compatibility for the deprecated Loggables
>>so that when the other projects get up to speed, they don't have to
>>change CM infrastructures.
>>
>>
>>>- to provide alternatives to all deprecated api.
>>
>>We have those alternatives in place.
>
>
> No, actually with 4.1, a developper can't build a application without
> deprecated warning like you wrote.
I didn't say they wouldn't get deprecation warnings. I said we have
alternatives in place.
>
> I think "apply deprecated API recursively" help to find deprecation
> without remove them, and help to find where alternatives are necessary.
>
>
>>>- to remove deprecated api every 2 or 3 minor release.
>>
>>That is not an option. Some projects take longer than 6 months to
>>upgrade. While we have some cruft in our systems, it is not
>>unmanageable. We need to give at least 6 months to a year.
>
>
> Why not set a new branch or use a compat lib.
> Why a project want the last version ?
Good question, but we have had that happen. We do have to live with the
realities that the code is used.
>
>
>>>- to have 2 sites (librairies + documentation(changes, api, tutorials,
>>>overviews...)) :
>>> - site for "Release version", where you can add an API changes
>>> rubrique (see JDiff http://jdiff.sf.net) whith the diff between
>>> succesives releases
>>
>>We are moving toward this approach.
>
>
> It's possible to provide a guide to help migration with users
> experiences.
Sure.
>
>
>>> - site for "nightly version", where you have access to cvs,
>>> nightly snapshot, new documentation, proposed orientation...
>>
>>Nightly CVS snapshots are generated by Apache. It *only* takes care
>>of the tarball. We cannot maintain such a vision without automated
>>tools. We are in the process of automating the site maintenance now.
>
>
> When I spoke about the nightly version, I meant the current development
> version with the future documentation. Like I say, it's very confusing
> to have some documentation say use that in one page and use this in
> other page.
Documentation maintenance is a pain, so we tend to put it off. IT's
human nature.
> Regards,
>
> PS: Sorry for raise alarme about ECM...
IT's ok.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: deprecated api (ex : Loggable...)
Posted by David BERNARD <dw...@freesurf.fr>.
> > I've studied Avalon family in september 2001, and I can't use it in
> > project due to api coherence. After some time I want to used it again
> > because there official "release" and documentation have been updated,
> > and I think avalon is very good (philosophy, approch...).
> > But in a "release", there are again incoherence :
> > - incoherence between documentation and released api,
> > - from scratch application need to use deprecated classes or methods
> > like ECM.
>
>
> Could you go into more detail of what *exactly* you are driving at
> with API coherency? Give me a specific definition so that we are
> on the same page.
>
> From the bits and pieces, I have put together, Framework itself is
> API coherent--your concerns arise in Excalibur.
More about Excalibur himself (see the logger package of 4.1,
LogKitManager is deprecated but not LogKitManageable) and Excalibur with
Framework, "Developping with Avalon...".
> > I'm not OK. If a developper use :
> > - a released version : backwards compatibility is need if he wants
> > to upgrade. And he wants to upgrade for :
> > - used new features then he is potentialy alright to update his code.
> > (no need of backwards compatibility, it's the price of the update)
> > - updated libraries dependancy to be ok with runtime context.
> > - bug fixes, but in this case when he find a bug,
> > he doesn't know when fixe will be published or released so he code
> > himself the patch, use other librairies or extract new version
> > of the classes in the CVS tree.
> > (no need of backwards compatibility, it's the price of the update)
> > - a nightly version :
> > - he used a specified version, he use it like a "release" one.
> > - he updates periodicly, then he knows that api are unstable.
> > (no need of backwards compatibility)
> >
> > So the need of backwards compatibility, isn't a hight priority. And It's
> > dangerous for new project, see the M$ Windows experience. For the moment
> > there aren't lot of application based on Avalon/Excalibur but new
> > project team can be frightened by the obligation to use deprecated api
> > like ECM.
>
> You'd be surprised at how many projects use Avalon--even within Apache.
> We don't want to be in the business of manually upgrading the projects
> when we deprecate something. We would rather give the projects time
> to migrate themselves--when they are ready.
>
> A project is not always in a position to upgrade his code overnight.
> Too many upgrades and we scare of other projects. We have already
> been down that road. With Avalon Framework 4.0 we drew a line in the
> sand saying that this API is supported. We must support it.
It's what I wrote a project with dependency on Avalon... do the choice
of the version and how/when it upgardes. I wrote that differents
strategies have differents risks. And a nightly build doesn't have
stable API.
> > Then my conclusion, he is you loose interested user of the avalon.
> > Because newbies developper or new project can't find a coherent api in
> > "released" version (librairies + documentation).
> > I suggest :
> > - to release more often (minor or macro) version.
>
> I am in favor of releasing more often. We do need to finish our
> restructuring of the Excalibur build before we can make that release
> happen.
>
>
> > - to apply depredecated api recursively
> > (if a method uses a deprecated Class the it's deprecated)
>
> In the case of ECM, I *could* have forced the upgrade, but then users
> who had an investment in Loggable components would be left high and
> dry.
Which users ?
Not the users of a "released" version.
Users of the nightly want to be uptodate and use the last
recommendations or concepts and are OK to pay the price.
But newbies who read the last api and framework are confused by the mixe
of informations. By exemple in a other project I use Cocoon, I want my
team study Avalon to understand better Cocoon, but I can't, because the
management of Log is different.
I think there is a probleme in the targetted audience.
> Instead we provide compatibility for the deprecated Loggables
> so that when the other projects get up to speed, they don't have to
> change CM infrastructures.
>
> > - to provide alternatives to all deprecated api.
>
> We have those alternatives in place.
No, actually with 4.1, a developper can't build a application without
deprecated warning like you wrote.
I think "apply deprecated API recursively" help to find deprecation
without remove them, and help to find where alternatives are necessary.
>
> > - to remove deprecated api every 2 or 3 minor release.
>
> That is not an option. Some projects take longer than 6 months to
> upgrade. While we have some cruft in our systems, it is not
> unmanageable. We need to give at least 6 months to a year.
Why not set a new branch or use a compat lib.
Why a project want the last version ?
> > - to have 2 sites (librairies + documentation(changes, api, tutorials,
> > overviews...)) :
> > - site for "Release version", where you can add an API changes
> > rubrique (see JDiff http://jdiff.sf.net) whith the diff between
> > succesives releases
>
> We are moving toward this approach.
It's possible to provide a guide to help migration with users
experiences.
> > - site for "nightly version", where you have access to cvs,
> > nightly snapshot, new documentation, proposed orientation...
>
> Nightly CVS snapshots are generated by Apache. It *only* takes care
> of the tarball. We cannot maintain such a vision without automated
> tools. We are in the process of automating the site maintenance now.
When I spoke about the nightly version, I meant the current development
version with the future documentation. Like I say, it's very confusing
to have some documentation say use that in one page and use this in
other page.
> > PS : I've got some time this month if you want help (to update code or
> > documentation (in this case I only see mistake, sorry for my english),
> > ...).
> >
>
> If you want to help update the site docs, feel free. We need to come to
> consensus on code changes though. We aren't removing anything without a
> vote.
OK, i 'll take a look.
Regards,
PS: Sorry for raise alarme about ECM...
--
--------------------------------------------------------------
David "Dwayne" Bernard Freelance Developer (Java)
mailto:dwayne@java-fan.com
\|/ http://dwayne.java-fan.com
--o0O @.@ O0o-------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: deprecated api (ex : Loggable...)
Posted by Berin Loritsch <bl...@apache.org>.
David BERNARD wrote:
> Hi,
>
> I've studied Avalon family in september 2001, and I can't use it in
> project due to api coherence. After some time I want to used it again
> because there official "release" and documentation have been updated,
> and I think avalon is very good (philosophy, approch...).
> But in a "release", there are again incoherence :
> - incoherence between documentation and released api,
> - from scratch application need to use deprecated classes or methods
> like ECM.
Could you go into more detail of what *exactly* you are driving at
with API coherency? Give me a specific definition so that we are
on the same page.
From the bits and pieces, I have put together, Framework itself is
API coherent--your concerns arise in Excalibur.
>
> Why ?
>
> * backwards compatibility, like wrote Berin (2002/02/08) :
>
>
>>The Loggable interface is freshly deprecated, we cannot simply drop it
>>from the face of the earth.
>>
>>ExcaliburComponentManager and friends are *not* deprecated.
>>Using them will definitely cause deprecation warnings in the interim,
>>but that is the price to pay for backwards compatibility.
>
>
> I'm not OK. If a developper use :
> - a released version : backwards compatibility is need if he wants
> to upgrade. And he wants to upgrade for :
> - used new features then he is potentialy alright to update his code.
> (no need of backwards compatibility, it's the price of the update)
> - updated libraries dependancy to be ok with runtime context.
> - bug fixes, but in this case when he find a bug,
> he doesn't know when fixe will be published or released so he code
> himself the patch, use other librairies or extract new version
> of the classes in the CVS tree.
> (no need of backwards compatibility, it's the price of the update)
> - a nightly version :
> - he used a specified version, he use it like a "release" one.
> - he updates periodicly, then he knows that api are unstable.
> (no need of backwards compatibility)
>
> So the need of backwards compatibility, isn't a hight priority. And It's
> dangerous for new project, see the M$ Windows experience. For the moment
> there aren't lot of application based on Avalon/Excalibur but new
> project team can be frightened by the obligation to use deprecated api
> like ECM.
You'd be surprised at how many projects use Avalon--even within Apache.
We don't want to be in the business of manually upgrading the projects
when we deprecate something. We would rather give the projects time
to migrate themselves--when they are ready.
A project is not always in a position to upgrade his code overnight.
Too many upgrades and we scare of other projects. We have already
been down that road. With Avalon Framework 4.0 we drew a line in the
sand saying that this API is supported. We must support it.
>>I am still working on the replacement technology
>>I am alot closer than I was, but still not all the way there yet.
>>Once done with the ContainerManager and friends, if we are happy with
>>that, we can talk about deprecating the ECM and friends.
>
>
> Then my conclusion, he is you loose interested user of the avalon.
> Because newbies developper or new project can't find a coherent api in
> "released" version (librairies + documentation).
> I suggest :
> - to release more often (minor or macro) version.
I am in favor of releasing more often. We do need to finish our
restructuring of the Excalibur build before we can make that release
happen.
> - to apply depredecated api recursively
> (if a method uses a deprecated Class the it's deprecated)
In the case of ECM, I *could* have forced the upgrade, but then users
who had an investment in Loggable components would be left high and
dry. Instead we provide compatibility for the deprecated Loggables
so that when the other projects get up to speed, they don't have to
change CM infrastructures.
> - to provide alternatives to all deprecated api.
We have those alternatives in place.
> - to remove deprecated api every 2 or 3 minor release.
That is not an option. Some projects take longer than 6 months to
upgrade. While we have some cruft in our systems, it is not
unmanageable. We need to give at least 6 months to a year.
> - to have 2 sites (librairies + documentation(changes, api, tutorials,
> overviews...)) :
> - site for "Release version", where you can add an API changes
> rubrique (see JDiff http://jdiff.sf.net) whith the diff between
> succesives releases
We are moving toward this approach.
> - site for "nightly version", where you have access to cvs,
> nightly snapshot, new documentation, proposed orientation...
Nightly CVS snapshots are generated by Apache. It *only* takes care
of the tarball. We cannot maintain such a vision without automated
tools. We are in the process of automating the site maintenance now.
>
> PS : I've got some time this month if you want help (to update code or
> documentation (in this case I only see mistake, sorry for my english),
> ...).
>
If you want to help update the site docs, feel free. We need to come to
consensus on code changes though. We aren't removing anything without a
vote.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: deprecated api (ex : Loggable...)
Posted by Shawn Boyce <sh...@qcominc.com>.
Nicola Ken Barozzi wrote:
>From: "Shawn Boyce" <sh...@qcominc.com>
>
>>David BERNARD wrote:
>>
>>> - site for "Release version", where you can add an API changes
>>> rubrique (see JDiff http://jdiff.sf.net) whith the diff between
>>> succesives releases
>>>
>>This tool seems very useful.
>>
>
>It's under LGPL
>
>We cannot redistribute it :-(
>
Why do you want to redistribute it? Do you mean it cannot be in the
Avalon CVS?
You only need to distribute the output of the tool.
--
Shawn Boyce
QCOM, Inc.
Quality Software is Our Business
http://www.qcominc.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: deprecated api (ex : Loggable...)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "David BERNARD" <dw...@freesurf.fr>
> On Tue, 2002-04-09 at 17:56, Nicola Ken Barozzi wrote:
> > From: "Shawn Boyce" <sh...@qcominc.com>
> >
> > > David BERNARD wrote:
> > > >
> > > > - site for "Release version", where you can add an API changes
> > > > rubrique (see JDiff http://jdiff.sf.net) whith the diff between
> > > > succesives releases
> > > >
> > > This tool seems very useful.
> >
> > It's under LGPL
> >
> > We cannot redistribute it :-(
>
> You can redistribut it in the development pack.
> With a LGPL you haven't the obligation to be under GPL. It can be
> integreted with any distribution.
But AFAIK LGPL jars have been removed from CVS in latest pruning...
I agree that LGPL seems to be ok, but it also seems that we cannot
redistribute it here.
Paul, since you had this problem with jesktop, how does the stuff work here?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: deprecated api (ex : Loggable...)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Shawn Boyce" <sh...@qcominc.com>
> David BERNARD wrote:
> >
> > - site for "Release version", where you can add an API changes
> > rubrique (see JDiff http://jdiff.sf.net) whith the diff between
> > succesives releases
> >
> This tool seems very useful.
It's under LGPL
We cannot redistribute it :-(
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: deprecated api (ex : Loggable...)
Posted by Peter Donald <pe...@apache.org>.
On Wed, 10 Apr 2002 01:31, Shawn Boyce wrote:
> David BERNARD wrote:
> > - site for "Release version", where you can add an API changes
> > rubrique (see JDiff http://jdiff.sf.net) whith the diff between
> > succesives releases
>
> This tool seems very useful.
Its damn useful. A lot of the JSRs use it when evolving an API. Now if they
could only tell you which changes were backwards incompatible it would be
fantastic.
--
Cheers,
Pete
-------------------------------------------------------
"When we remember we are all mad, the mysteries of life
disappear and life stands explained." -Mark Twain
-------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: deprecated api (ex : Loggable...)
Posted by Shawn Boyce <sh...@qcominc.com>.
David BERNARD wrote:
>
> - site for "Release version", where you can add an API changes
> rubrique (see JDiff http://jdiff.sf.net) whith the diff between
> succesives releases
>
>
This tool seems very useful.
>
>
--
Shawn Boyce
QCOM, Inc.
Quality Software is Our Business
http://www.qcominc.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>