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.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
