On Tue, Jan 28, 2003 at 11:26:44AM -0500, Jason van Zyl wrote: > > > My initial reaction is that I'd like to see Turbine stay away > > > from Plexus. Even if it a technically superior implementation > > > of the Avalon Framework, > > > > plexus is not an "implementation of Avalon Framework", nor is > > any of the containers hosted @ avalon. I also don't think it > > smart to get into any kind of "pissing contest" over technically > > superior container implementations. Fact of the matter is, there > > is no "container spec" and hence no "container impl", just an > > implementation of a somewhat too vaguely described concept. > > Never claimed it was 'superior'. It will certainly be different > but I never attached the 'superior' moniker to it an any point in > time.
Sorry, the superior moniker was my fault. I should have specified, as I was thinking at the time, that I don't know which container is technically superior, I was just trying to illustrate that 'technical superiority' should not be the determining factor in using Plexus over an Avalon container. Actually saying that sounds rather stupid, e.g. why not go with the best implementation, but (with my naive knowledge of Plexus) I'd put more stock in the Avalon community. Course maybe Jason's points are correct, that Fortress is a good stepping stone to 'SuperContainer' but currently not a good option for the Turbine/Tambora communities. I could accept that, except when we start bringing non-Avalon Framework concepts into the picture (e.g. the ServiceManager.lookup change and hint of different lifecycles) it gets a little scary. It sounds like Plexus embraces and extends the Avalon Framework, which might not be a bad thing, e.g. if we're getting lots of cool new features, but how does that affect our relationship with the Avalon community? E.g. the granduer plans where all Avalon applications run in one container, their is a single component repository to share amongst Turbine/James/Cocoon, someone who picks up Turbine can quickly understand how James/Cocoon operate because their based on the same container/meta-data/etc.? With the changed interfaces/lifecycles, what is going to keep Plexus/Plexusized-Fulcrum/Plexusized-Turbine end up being Stratum? > How long has Avalon been working to release something? There was > certainly a business motivation because you can't get squat to build > without a _great_ deal of difficulty, hardly any of the examples worked > and everyone is busy. Not just a business need, but any need. This is a really good point and, to me, would be the best reason for going with Plexus. However, I'd just like to make sure that: - For one, that using Plexus now doesn't lock out the option of switching to Merlin/SuperContainer in the future (e.g. the embrace/extend still seems fishy, though I know little about it), and - Plexus is brought in and accepted by the community (and ideally would have it's own community). Turbine is already stretched thin with people working on Turbine/Torque/Fulcrum, so without a new influx of developers, adding Plexus to the mix would make things even more chaotic. Also note that, and I mean this with all due respect, from my short time at Turbine, Jason is a revolutionary who likes to pushing out new code to solve new and interesting problems. This is great and results in some really cool applications, e.g. Maven and Plexus. But at the same time, we need the support of our evolutionaries, e.g. Henning and Martin, or bring in some more evolutionaries (which I think is a great idea to ease the load on Henning and Martin) to make sure that after Jason has gone on to the next new project (which is perfectly fine, I enjoy doing the same thing, only, unfortunately, to a more frivolous extent, which is an attribute I'm working on), we have people here in Turbine willing to maintain Plexus, assuming it is donated. - Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
