Marc Schier wrote:
Hi all,We're talking about Apache Commons (http://commons.apache.org) for the Components, not Apache Jakarta Commons (http://jakarta.apache.org/commons/).
I've resurfaced after a stressfull re-location to my new home in Seattle.
Was a lot of work! Now after setting up my email access at work I discovered
672 new mails in the Avalon-Dev folder. Sure a lot of things have been
going on. Now of course I'm writing the following without really knowing if
it is still up for discussions or has already been decided.
Part of our problems has come from dividing implementations and creating feuds, so I would propose that:
1) the Components/services would eventually migrate to Apache Commons.
not now, not tomorrow, but the path is set, and other projects
like Turbine will follow :-)
I absolutely agree in seperating commit privileges and creating several
PMCs, but I'm not sure if I'm convinced that it's the right thing to move
"all" components to commons, if that's what's suggested.
Apache commons IMO as it stands right now is mostly non-component and
largely library material. I think it's a very good approach to centralize
this tooling development effort within Apache, and maybe 30% of excalibur
should actually be in there (CLI, Concurrent, event...), but I do not think
pure Avalon-services will fit, since they cannot easily be used in
Non-Avalon environments. They do not represent the classical software
tooling.
Your comment is correct, Jakarta Commons never accepted our components and never will, but Apache Commons IIUC will, and Peter Donald is on the PMC :-)
They rather perfectly fit into execution environments like AvalonIt has been partially done, and also mainly agreed upon, but it's mostly lack of time by developers.
containers.
In my opinion the first thing to do is to place the mentioned 30% into
Commons. I don't see why that has not been done faster anyway, since it
will not effect more than build.xmls anyway.
What was possible has been done, and we also merged some of our stuff with J-C stuff, and the result seems very good :-)
( BTW How do you get commit
privileges in commons? )
In Jakarta-Commons-Sandbox, just ask and you will be given.
The repository should also be open to Turbine, Obj, Cocoon, etc developers to place their stuff there, so putting it on common ground seems more sensible to me.2) we keep only *one* set of utility classes called avalon-util
(no more fancy names, pleeease)
3) all containers in the making, like Merlin2 and Fortress
go in the scratchpad dir.
This should *not* be done hastly, it will take time. But we'll get there.
In the end we will have *one* avalon CVS repo, with
./src/framework/**.java
./src/util/**.java
./scratchpad/src/merlin2/**.java
./scratchpad/src/fortress/**.java
Some classes now in framework will go in util too probably, we'll have to vote case by case.
Excellent idea. Makes perfect sense to me. Nonetheless I think we need a
service/component repository as well independent from Commons to promote the
Avalon development and adoption of the framework.
Apache Commons will have different bylaws that Jakarta Commons, thus making this part of its repo effrectively the Avalon Component Repository.
If we want developers and decision makers to know that Avalon promotesBeen there, done that. IMHO it seems that Cornerstone was not a massive hit and that otehr projects would like to cooperate more in the process... IMHO that is.
re-use we have to provide them with reusable components as well and IMO from
one homogenious source.
Exactly what we are thinking to do with Apache Commons.So why not make Excalibur the Component Repository for Avalon after migrating the containers, utils and commons material? PMC would have commit privileges to framework, but for the repository we could be more generous and have more developers be able to add and work on service implementations compliant to framework and running inside an avalon container (kinda like a micro-sourceforge). To promote Avalon development, we could e.g. establish an active web based community where users could vote on the usefulness of a particular service implementation.
But Apache Commons has just started, we'll see that the solution will be accepted by all and be solid.
As far as the concept of making such a place is agreed on, we can always discuss the details and actual locations later.
As far as Phoenix is concerned, why not spinning it off as a seperate
project? This could give this excellent piece of software more market
recognition than just being a sub project of Avalon.
So where am I in the course of the discussion?
Seems you're on the spot :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
