avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [Fwd: Re: avalon-framework changes]
Date Fri, 09 Jul 2004 17:11:27 GMT
Leo Simons wrote:
> your wish is my command...I doubt this is more productive...

Irrespective of productivity - technical matters belong on the dev list. 
  There were a couple of technical points I thought were incorrect and I 
wanted to raise those points with you.

... in particular - you said:

>> Component writers which follow this rule when writing Avalon 
>> components will create a component that is impossible to use in 
>> excalibur, cocoon, james, loom, plexus, phoenix, and other software 
>> projects that aim to support Avalon components. 

This is no different to the introduction of the Serviceable interface 
and ServiceManager.  Container implementation that existed prior to 
enhancement to framework are presented with a choice - upgrade or 
restrict support to Composable. This is no different - container 
implementations can choose to support injection or alternatively test 
for a null constructor.

As for the list - I just want to clarify that James is not impacted by 
this in any way at all. Phoenix is not an issue - it will continue to 
support 4.1.X. I'm not involved with Cocoon but it was my understanding 
that they were looking at a Cocoon specific container and more recently 
some discussions about Fortress. As for Excalibur, Loom and Plexus - the 
addition of support for constructor injection, along with support for 
standard context entries, standard meta-info descriptors and packaging 
specifications, etc. remains with the respective development communities.

>> As such, it is highly backwards-incompatible 

There is absolutely no backward incompatibility.

>> and "sideways-incompatible". 


Not sure what this is!

>> It effectively destroys the common denominator between these 
>> projects for no good reason.

The good reasons:

   1. improved compile time checking
   2. reduced memory consumption
   3. significant reduction of lines of code
   4. elimination of potential errors by component
      authors related to sequential artifact delivery
   5. reduced dependency on framework interfaces

Cheers, Stephen.


| Magic by Merlin                       |
| Production by Avalon                  |
|                                       |
| http://avalon.apache.org              |

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

View raw message