Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote:
And just how many competing products and integral architectures is
Cocoon endorsing, publishing and supporting? Just how many mail servers is the James community supporting? How many different component architecture is Turbine backing (as opposed to the number
of architectures they have to deal with).
Fallacy. I was talking about *community* and not about *product*.
Yes - I know you were addressing community. I was referring to the foundation on which a community can function well. So long as we have different platforms we have this forever on-going debate about what is right and what is wrong as opposed to good old fashioned getting in there, supporting, evolving, influencing, and ultimately changing what it is that we believe in.
The difference between here and there is about making some choices together and molding and sculpting - its about the the feeling I had looking looking code in castle - feeling quite at home, and rather proud of myself - and curious about why your doing something different.
That's community!
And how does this impact a community. It means that the community is a community because is bound be a single idea, a vision, an ideal - call it what you want.
Agreed.
Put in place one solution.
Solution for whom, for God's sake.
For Avalon, Apache, our users, James, Cocoon, Turbine, and the Apache Directory Project, and you can count me in under the "users" category.
Thats the point: for a very particullar audience who wants to feel using a J2EE like container.
I don't see things in the same light as you do. But let get down the real point your raising. Your depicting Merlin as a J2EE platform. That in my opinion way off the mark because the Merlin development (and the opinions of the people contributing to merlin) go well beyond that reference point - something much better, much cleaner, a complete quality IOC component and service management solution.
But don't get me wrong - management is an intrinsic element of where I believe the industry is going and with the explosion of users, servers, protocols and components out there management around these will become critical.
Kill the rest and you change the equation.
And push your decision through their trhoat.
Basically we have the cowboys on the left and the city-guys on the right. The cowboys want to play thing fast-and-loose and the city-guys
want to play by the numbers. It just so happens that the city guys have
pulling something together that out-guns the cowboys. I don't want want
to appolagise for that but we do need to deal with it.
Your suggesting that this is a case of me "pushing my decision through their throat". Well that's not exactly the case.
First off - my decision is academic (as you have already pointed out to Niclas) - the opinion of one is no more or no less than than any other. What is not academic is the result of the participation. Now here is where we get to the crunch. Cocoon is hung out on a string and this means an opportunity for the cityguys to step in and close once and for all the duplicity in Avalon. What I'm not interested in hearing about is the next great meta adventure. Geeez!. I'm not terribly interested is hearing about a Sally or Nancy container either. What I am interested in - is closing an issue that Cocoon have to deal with and at the same time closing the Avalon divide.
So what about the cowboys? OK when you brush of the dirt and dust, underneath these are just regular guys. And you know what? There is lots of stuff to do - we have only finished main street - plans for downtown are on the drawing board.
I'm not concerned about people leaving because we take a decision. I am concerned about people leaving because we don't a decision.
Maybe the majority thinks Merlin SHOULD be the future of Avalon, the
*reference* implementation. I'm included in this group. But I - and others I think - disagree that it will happen as the way it is *now*.
It is going to have to happen. We are causing ourselves too much damage through protracted indecision. This is not about "which container" - that's a done deal. This is about accepting that its a done deal. The sooner we get past this point the better it will be for you, me, and everyone else.
And when Aaron says: I don't want the damn repository you'll came with "whats the *real* reason to not want it".
Honestly I had absolutely no idea where you were coming from. I was feeling really good about your stuff (feeling just a tad proud myself), and then your jumping at something that wasn't there. If you had taken an extra 20 mins you may have read more about the structural and security implications of Aaron's suggestion. You may also have read some opinions about how some of the underling objectives could be dealt with differently, and why Aaron's suggestion is probably inevitable for web-app scenarios. But OK - whatever - we'll get back to the subject when the dust has settled.
Your words: "Merlin needs to be break down 'til it becomes Avalon". For every day it seems like to more and more distant goal.
As far as I am concerned Merlin is Avalon's future.
I don't think I've exactly kept this as a hidden agenda (in fact I think its a stated objective somewhere). But let's take this a step further. Here is a predication - Merlin will break down and become Avalon. It will be "The Avalon Container". It will use "That Avalon Meta Model", it will manage component composition through "Avalon Composition" it's runtime will be executed under "Avalon Activation", it's internatilization system will be "Avalon i18n", etc...
And guess what? Anyone can step up and be part of that process, get in there, make it evolve, contribute, push in news ideas, refactor, revolt. Heck - that's what the community rules embrace. Its in this context that we bring in more committers, grow the community, enable other people to pick up stuff that we are learning. End-game? A sustainable community that takes ownership and goes places we haven't even thought about.
And you take the defensive when someone says "I don't want the repository!"
No.
I may be slow, my typing sucks, I know Niclas hates the way I format code, and Alex hates the complexity I put into builds, Leo hates my notion of architecture and the other Leo simply hates the names I give things. But aside from all of that (heck nobody's perfect) - I do want to help, but I want to understand things before I make conclusion!
That means asking question. That's why I asked Alex a bunch of questions when he started talking about turning Merlin inside out, it the reason we ended up with a clean activation model - not from me - but from Niclas asking too many dam difficult questions. It's the reason I asked Aaron what motives were underling his proposal.
Go[t] it?
Yep - it's right here on the tip of my finger.
So lets get to the point. One product architecture. One product implementation. If someone doesn't like that product then they need
to get their butt in gear and do something about it. And a united community will make sure it evolve.
Ok, will do.
Good.
We are on the same page.
Now is the time to make that decision.
Now its time to get consensus. Please, get your butt in gear and make your proposal.
PROPOSAL (Aaron - you ready?)
1. We move Fortress into sustainable retirement 2. We move Phoenix into terminal retirement 3. We update our website and re-position Avalon on Framework and the core facilities within Merlin 4. We bring Avalon Components up-to-date with the Meta Specs (while maintaining legacy support for Phoenix meta) 5. We move facilities to Avalon Components
And outside of the formal proposal, I would be really happy if anyone wants to join me in taking on what is necessary to deliver a solution for James, Cocoon and Turbine - based on Avalon supported products with the collaboration of the respective communities, and through this process deliver the necessarily legacy support for transioning users.
Stephen.
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
