Remy, I hear you.
Current Avalon is what you say.
Next Avalon will be what it was supposed to be in the first place.
I respect you and your judgement; if you could give me additional hints
on what the problem is about for using Avalon here, I would sincerely be
grateful.
Anyway, as I tried to say in my last post, the only fact that you think
this about Avalon is IMHO enough to not use it ATM.
Remy Maucherat wrote:
> For all the things it gives you, Avalon is a framework, and makes you
> feel like it. It imposes contracts between components / patterns,
> packaging, etc. All things which aren't compatible with 5.0.
Hmmm... imposing good contracts is a good thing. Every API is a
contract, and good APIs help make good software.
Hmmm...
> And more
> importantly, the API changes often, to the extent that all the projects
> which use Avalon work off a specific snapshot, and don't upgrade too often.
This is not that true. Avalon framework API 4 is stable for quite some
time. What really changed fast are the implementations.
We are now working on make a single reference implementation and focus
on that.
> Also, most of the utility provided by Avalon are available from the
> commons without any string attached, and/or are of a better quality.
Utilities provided by Avalon are lifecycle management and component
reusability+management.
All the other things are not Avalon, and are currently being moved to
Commons, or wherelse where they belong.
> There has been plenty of discussion on that with Paul, and during the
> whole commons-logging incident, at which point I thought it would be
> best if I didn't have anything to do with Avalon.
I wasn't here when the logging incident took place, luckily ;-) , but I
must say that it was a bad thing for all of us.
Currently there has been a proposal of using commons logging APIs, but
there is still a bit of resistence from both parts.
I'm confident we will get through them, because if we don't I'll ask
Pier some spiritual karma and have some kicking to do ;-)
> OTOH, we could have optional Avalon wrappers again, as long as there is
> someone to write them *and* maintain them when the API changes.
This is certainly nice.
I hoped that someone did some work on them, but it's ok.
When we'll be ready for that stage, I'll post again.
> So +0.1
> to work nice with Avalon, but -1 for basing the architecture on Avalon.
We'll talk about this when we've finished our spring-cleaning.
Could you kindly summarize the things that Avalon needs to do before you
would even consider taking it in consideration as a framework?
Thanks :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
