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:[EMAIL PROTECTED]
\|/ http://dwayne.java-fan.com
--o0O @.@ O0o-------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
