Re: [PROPOSAL] lifecycle release

Berin Loritsch wrote:
> Stefano Mazzocchi wrote:
> 
>> Stephen McConnell wrote:
>>
>> Wasn't the proposal about migrating the lifecycle package into 
>> framework or did I overlook something?
> 
> 
> No it was about placing it in the "avalon" CVS repository, and
> being maintained separately from Framework.

Then I don't understand what this means.

>>> Can you be more specific - what in you view are the one-man shows 
>>> that must stop? 
>>
>>
>> I don't see many people working on Merlin. Is this a wrong perception?
> 
> 
> It will after we get the Unified Avalon release done.

All right. I trust you on this.

>>> Are these one-man shows related to released packages, packages 
>>> scheduled for release, or are you referring to activities under the 
>>> avalon-sandbox project.
>>
>>
>> I'm referring to Phoenix and Merlin. Both seem to me one-man-shows. 
>> But hopefully I'm wrong.
> 
> 
> Phoenix is actively maintained by more than one individual.  There are
> some projects that depend on it so we also cannot just get rid of it.

Oh, I know, I know.

>>> Perhaps you could put forward you concrete arguments. Nothing below 
>>> even suggests that you're familiar with the package in question. In 
>>> fact several of the comments suggest that you may be confusing the 
>>> lifecycle package with something else. You response on this is 
>>> important because if you really think that the result of the 
>>> collaboration between Marcus, Berin and myself is a "hack" - then I 
>>> would like to discuss that will you. I will disagree with your 
>>> position and present substantial evidence supporting that position. 
>>> If however you comment is made with same level of indifference as the 
>>> original hack comment from Peter Donald, then I can safely ignore it.
>>
>>
>>
>>  From there I stand:
>>
>> 1) something is moving into avalon framework
> 
> 
> That was a misperception.  That is not happening.

Good. Then I can set my alarms off.

>> 2) in my view of the world, this *something* is therefore going to be 
>> considered *ROCK* solid
> 
> 
> How about *next* to framework--but not *in* it?

This worries me. I would like to hear what this means before restarting 
my vote.

>>> The lifecycle package was a successful process of collaboration by 
>>> three people each with relatively different ideas on the approaches 
>>> concerning lifecycle stage management under the Avalon framework. 
>>
>>
>> I now see a forth disagreeing. This is valuable input from me.
> 
> 
> Can I ask you a question?  How comfortable are you with the complexities
> of interception?  

Comfortable? you mean knowledged? I know absolutely nothing about their 
complexities, althought, as a java programmer that knows java a little, 
I think I can grasp the outline of the problem.

> It is not as simple and straight-forward as its main
> proponent suggests.  In order for it to work effectively, we need to
> use a dynamically generated approach which either means incorporating
> CGLib or using Dynamic Proxies.
> 
> Either way, I haven't seen where the code is really more understandable
> using interceptions than the proposed extensions standard.
> 
> Don't get me wrong, interceptions are a cool concept--if the user can
> be successfully hidden from the implementation details.  We have not
> had an opportunity to do that as a community yet.

So you are stating that this lifecycle is just a step in the direction 
toward a more AOP-oriented solution?

That would be fair. But I want to know how this impacts the framework 
before allowing it in.

I hope this is not seen as obsessive obstructionism, but just a concern.

Stefano.