excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <lsim...@jicarilla.org>
Subject [RT] so...many...components...
Date Tue, 15 Jun 2004 09:48:29 GMT
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: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/


Mime
View raw message