avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Change Strategy (was Re: [VOTE] Instrument package into Framework namespace)
Date Mon, 24 Feb 2003 13:47:30 GMT
Stefano Mazzocchi wrote:
> Leo Simons wrote:
> 
>> Leo Sutic wrote:
>>
>>>  1. The interfaces from the instrument package should move into the
>>>     org.apache.avalon.framework namespace.
>>
>>
>>
>> +1
> 
> 
> Maybe there will be one day when avalon packages will be rock solid and 
> won't change every 6 months.
> 
> Or one day cocoon will finally pass a Gump run without having avalon 
> dependencies broken.
> 
> Or one day I'll run out of patience as I did with Tomcat and remove 
> dependencies to the bear minimum.
> 
> Just keep in mind that everytime you feel you are seeking elegance and 
> order, you are, in fact, increasing the enthropy of the system anyway.

Stefano, can you please just come right out and say what you mean?
You are a member of the Avalon community so a simple -1 with an
explanation might be better than this "One day" crap.

You have only had perceived problems with Avalon Framework--IOW, no
change in Framework (the core jar you are using) has made Cocoon
cease to work.  Instrument is a new feature, that grew up in Excalibur.
The question now is whether to support the Instrument interfaces in
Framework, or keep it a part of Excalibur.

It is obvious you are against this.  Why?  Adding functionality to
Framework does not break Cocoon.  What it does is make us have to
handle legacy in the InstrumentManager.  That may be reason enough
not to do the change.  We are trying balance many things here.

THe dependency tree for some of the Avalon packages is potentially
circular, or very complex.  The proposal solves one of the causes
of the unnecessary complexity.  Granted, it is something that is
beyond *just* components, so we need to balance that fact with
incorporating Instrument into Framework.

Also keep in mind that as we learn, it affects what we percieve
Avalon to be.  Managing that change is a difficult task.  I welcome
any input from you as to how best to change.

Constant major version changes are really bad.  Noone complains about
bug fixes.  But what about refining the contracts?  Can you help us
all to understand what a decent change strategy is?

I thought we were doing an exemplary job of managing change at the
Framework level.  Please enlighten me how we can manage the balance
between too much change and stagnation.  I really would like to know.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message