commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: Query: Hosting Avalon Components
Date Fri, 25 Apr 2003 12:26:43 GMT
summary: there are a lot of things that are "avalon components" 
scattered throughout apache, and the general java world. They should not 
all go into jakarta-commons. However, it might make sense for some of 
them. The existing procedure for deciding whether a component should 
live in jakarta-commons should simply be applied. If that procedure 
includes "import (.*)(avalon|excalibur)(.*)" means auto-reject, that's 
silly though imnsho.

The larger issue "where should piece of code X live" is complex. The 
relationship between all the $X-commons projects is not something we can 
design up front. Opinions differ. Let it evolve.

Henri Yandell wrote:
> What's an Avalon component? Something that implements the Initable,
> Startable stuff? [I'm sketchy on Avalon]
> I can see that it doesn't make any sense to host an Avalon component in
> Jakarta Commons if it's only useful in an Avalon container,

previous post from me was to try and explain why that is not usually the 
case. I'm going to tackle the second part below.

> unless there
> are lots of Jakarta Projects out there which are customers of the Avalon
> project. Then it makes some sense, though it could also be Avalon Commons
> [or better name] as a subproject of Avalon?
> If there are Jakarta projects out there who want to share Avalon
> components, I don't see why they can't be in Jakarta Commons.

Question: where do avalon components currently live?
Answer: most live in private or commercial projects. In the open source 
world, they're scattered throughout. Some places (not a comprehensive 
list, and no, there is unfortunately no comprehensive list):

* *avalon*, Has avalon components in the 
avalon-excalibur, avalon-cornerstone and avalon-sandbox CVSes. Most 
components are similar in scope to those in jakarta-commons (ie 
cornerstone-socket-manager is a utility library for (duh!) socket 

* *james*, Completely componentized system, 
has components such as a dns service, smtp service, fetchpop.

* *cocoon*, Completely componentized system, 
has absolutely loads of pluggable components ("cocoon blocks") ranging 
from things like Rhino and Velocity wrappers to a full-blown xmldb.

* *fop*, Does not use avalon atm, but the 
developers are looking into completely componentizing it.

* *lucense*, Haven't been tracking 
closely, but these people are busy componentizing lucene IIUC. A lucene 
wrapper already exists in cocoon.

* *turbine*, Current Turbine doesn't 
use avalon, but a revamped turbine3 is planned which does by using plexus.

* *slide*, Does not use avalon, there's 
some sandbox material in it that does IIUC.

* *maven*, Does not use avalon, but a revamped 
maven-new is under development which will be completely componentized 
using plexus.

* *plexus*, Effort led by Jason van Zyl, 
everything still under development. Besides an avalon-container effort, 
also has a component repository wrapping things like Apache Axis.

* *spice*, Effort led by Peter Donald, most things 
still under development. Many components and reusable library of similar 
scope to the materials hosted in jakarta-commons.

There are many more projects out there which host "avalon component 
wrappers" around their products, for example the Jo! servlet engine. A 
partial list is at

Question: are there jakarta projects who want to share components?
Answer: yes; but read on.

With most of the avalon-component-providing projects growing into 
top-level projects, their number has decreased again. Also, it is a bit 
difficult to figure out how much will/should be "shared". For example, 
while the JAMES dns service can likely be used seperately of JAMES, it 
is so integral to the functioning of the project that it is extremely 
unlikely that service will ever end up in jakarta-commons.

Question: are there apache projects who want to share components?
Answer: yes! See the partial list above. All these people have a need to 
swap code and stories. With avalon gaining critical mass (amount of 
traffic on users@avalon is skyrocketing), the number of avalonized 
applications and the number of "component wrappers" for existing beans 
and applications is rapidly increasing.

Question: should jakarta-commons host all these components?
Answer: no! Hosting all of them would multiply size of the 
jakarta-commons repository and committer base by several factors in one go.

Question: should jakarta-commons host none of these components?
Answer: imho no! It makes sense to keep the code where the people are, 
and the wrappers where the code is, too. Should an avalonized 
commons-digester wrapper live in avalon-components? No, it should be 
living right here.

Question: so what should the policy be?
Answer: take them as they come. For any given unit of code, evaluate 
whether it has or will have enough healthy community here to support it, 
whether it makes sense within the scope of the commons charter, whether 
it is of quality, and apply whatever other heuristics you guys have for 
accepting or rejecting code.

Again imho, it makes sense to have a liberal and open sandbox policy 
coupled with aggressive cleanup. Invite all those people on all those 
apache projects I listed to come and play over here and see what results 
from that.

Finally, imnsho, it does not make sense to have as a policy "if it 
imports anything containing the word 'avalon', it doesn't belong here". 
I hope my previous message makes clear why. AIUI, this is not the policy 
over here anymore:

find -name *.java -exec grep avalon \{\} \;
package org.apache.commons.jelly.avalon;

which is good. So AIUI, answer to Berin's question should be "bring on 
the proposal!".

Jakarta-Commons, Avalon-Commons, XML-Commons, Apache-Commons, ...
Should there be an "avalon commons"? Should there be a "maven commons"? 
How should those projects relate to each other and jakarta-commons?

This is a difficult topic and discussions certainly started off on the 
wrong foot back on the reorg list; I guess everyone in retrospect would 
have done some things differently. The way I see it, there is quite a 
bit of java code here at apache which would make sense as part of 
java.*, and that code should live here. Everything else elsewhere.

IOW, all that code is of common use and needed for the majority of java 
projects. It should live in a single place where all those projects can 
collaborate together. The only such place, at the moment, is 
jakarta-commons. Cool project, cool things, cool people. You guys 
(contrary to, atm, apache-commons) are on a roll.

There is also quite a bit of code which makes sense as part of javax.*. 
This code should clearly not all live over here. For example, at some 
point in time it might make sense for jelly to become, 
to decrease the strain of its resource consumption on the jakarta PMC. 
Clearly, something like slide makes sense as part of javax.webdav, but 
not really as part of jakarta-commons. The size of

This is all just imho. It is up the jakarta-commons and the jakarta PMC 
to figure out where a line should exist, if any, not me.

As to "avalon commons", we have something like that (excalibur and 
cornerstone cvs), and I think we'll be formalizing that slightly more. I 
think the relationship between this avalon-components and 
jakarta-commons should be determined by applicability. If a piece of 
code is broadly reusable across the majority of (server-side) java 
software, it should live in jakarta-commons. If it makes sense only in a 
cop framework, it should live in avalon-components.

In My Humble yet Honest Opinion (ie, radical thought warning! :D), the 
current Commons PMC should be dissolved, then a new Commons PMC formed 
from all active jakarta-commons committers should all become part of the 
Commons PMC plus all other interested ASF committers (I guess most of 
the people currently on the Commons PMC), and responsibility over all 
the stuff in the jakarta-commons repo transferred from the Jakarta PMC 
to the Commons PMC.

This merged jakarta-commons/apache-commons project should have a sandbox 
open to all asf committers, with small healthy projects "graduating" 
towards common proper, large healthy projects "graduating" to incubator, 
and unhealthy projects `cvs remove`ed.

But certainly this is a highly controversial opinion, and I'm just an 
innocent bystander, so kindly ignore it :D


- Leo

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message