Hi gang!
While on the subject of moving things back and forth between projects, lets briefly revisit this one as well. Sorry about the lenghty e-mail, but I think some people need some context. If you have the context, skip to the last paragraph.
What is Spice? -------------- Spice is a component repository:
http://spice.codehaus.org/
it's primary developer is Peter Donald, who is also the guy who wrote most of the excalibur component code. IIRC some of the materials in Spice are forks of excalibur materials and others are forks of cornerstone materials.
Again, IIRC, Pete started spice (over at sourceforge) when we decided @ avalon that we didn't want to host a component repository inside avalon. The bits of avalon that he moved over were the bits he was the primary (often only) maintainer for.
What happened?
--------------
All this got off to a bad start. I have no particular desire to drag all that up again. Instead of avalon materials being deprecated in favour of the spice ones, lots of nasty shit happened.
The current situation is that we have more than a little duplication of functionality between avalon, excalibur and spice, sometimes duplication of code (I think Pete improved a lot of the packages over at spice), etc, with the primary developer of some components having forked them offsite to develop them there, but all the old materials still lying around over here, mostly unmaintained.
Cocoon?
-------
ECM actually started within cocoon and moved over here. Along with it came bits and pieces of other code, in particular some of the components, like xmlutil and sourceresolve. Some of these saw use in other people's projects, others never did.
Cocoon uses ECM, but is AFAIK moving away to their own highly domain-specific solution. That'll take them at least a year or two (my estimate, not theirs!) before a final release. In the meantime we have a big ECM client to support.
Stefano and others have been crying out about the large amount of cocoon dependencies (http://cvs.apache.org/viewcvs/~checkout~/cocoon-2.1/gump.xml), and they've set out to reduce those.
This might mean cocoon will fork things like sourceresolve, which they're still going to need in some form.
So....many....repositories...
-----------------------------
Spice is just one of a multitude of IoC component repositories. Cocoon is just one example of an IoC-container-client.
In the meantime, avalon has also decided that they are going to keep a component repository around after all (I think its now called "Avalon Planet").
There's also the dormant but not dead idea of a ComponentHaus, which would contain dependency injection (you know, pico stuff) as well as service locator (you know, avalon) style IoC components. Mike Hogan started some basic code to automate that, then ran out of steam. I think Paul Hammant has his mind set on making this happen one day, which makes it likely that it will happen.
And there's more.
Turbine has IoC components. Cocoon has IoC components. Excalibur has IoC components. Avalon has IoC components. Spice has IoC components. Spring has IoC components. WebWork has IoC components. Keel has IoC components. Plexus has IoC components. Maven will have IoC components. PicoContainer has IoC components. ComponentHaus has IoC components. Lots of IoC materials scattered around the open source world.
Compare this to Jakarta-Commons, which is like the de-facto place to get some common "jdk additions". I don't see many people compete with commons-lang or commons-cli, at least not very successfully.
Now what?
---------
My take on all this is pretty simple: I have no particular desire to keep all this duplication of effort in place. It's an end-user nightmare and highly inefficient for the developers.
I would like to see the remaining components in excalibur moved elsewhere or deprecated in favour of packages living elsewhere, and focus on building a highly competitive container package. Projects like Keel can then compete with offerings like spring.
Oh, I usually make a distinction between "end user components" that you run inside a container and "building blocks" that you use to build a container. I'm talking about /both/ here.
Proposal?
---------
Nope. I would like to take a week or so to figure out what y'all are thinking, figure out what our average direction is, distill a plan, get it in jira, and JFDI.
WDYT?
cheers,
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
