Hi,
I guess it is time for me to comment :) This proposal has many components
in it but the two most obvious aspects are the infrastructure/form and the
products/content. The infrastructure consists of
1. shared CVS
2. standard directory/build file layouts
3. standard build support included automated testing/building/profilling
4. publish/directory system ala CJAN
(3) will be done by cooperating with alexandria-gump/Sam. The other
components will be developed for this project.
The products of the project will basically be shared reusable server-side
components.
It is my contention that once the infrastructure is developed you will see
other projects adopt it. Sam (and me aswell) is a supporter of open CVS
system (1) to foster cross project collaboration and to help break down the
barriers between projects. Both (2) and (4) are also likely to see rapid
adoption among the other jakarta/apache/external projects.
So once the infrastructure is in place this project is primarily about
content. If you look at the content description closely you will see it is
a subset of the charter of Avalon. There was discussion about this on the
list and a number of objections to Avalon. The majority was misinformation
or confusion but there was two points identified that made Avalon
"undesirable".
Craig identified the point that while Avalon was originally intended for
this purpose it has historically been associated with other factors. Namely
it has been *seen* as both an application server and also as a framework.
My response to this was - perhaps - but since my involvement in Avalon I
have been trying to get it back to it's original charter. If you look at it
now the kernel+services (ie application-server part) have been separated
into alternate CVS repositories (phoenix and cornerstone) and will
eventually be moved out of Avalon into alternate projects. The latest
proposal for Avalon also moves basic utility code into an alternate tree -
and as things consolidate the non-framework specific code will be migrated
to another hierarchy.
Costin identified another concern - the "Not Invented Here" syndrome. ie he
wasn't involved with Avalon and thus a new project should be created. I
disagree with NIH in almost all circumstances unless an effort has been
made to work together with the original team and has failed. This has not
been the case.
Now lets look at this from a different perspective. If I were to propose a
new servlet engine as a top-level project (ie not a revolution of tomcat
but a peer of tomcat) and my only reason for doing it was NIH would such a
proposal be accepted. I would hope not (except under very specific
circumstances described below*). The main reason is that it does nothing to
"help" apache - it could even damage the apache name as end-users would be
confused on which project they should be using etc. Especially if feature
sets were identical.
* If two existing code bases have different performace aspects and strong
communities then it could be beneficial for apache to accept both
Look at the conflict caused a while back when struts started reimplementing
turbine code. Now instead of this imagine that struts was a subset of
turbine with no different use case - would it have accepted? Or more to the
point would it have been productive for jakarta for it to have been accepted?
Some may point that we have multiple template technologies at apache
(php/xsp/velocity/struts etc) however as they are each a different view on
problem space they are acceptable. The commons is a subset of Avalon (not a
different view) once the infrastructure is implemented.
Others have questioned why doesn't Avalon change it's charter so that
Commons could be created. However this is a path of questionable worth. The
reason is that once Avalon has consolidated it's current products and they
have been split of it will be nothing but a glorified component model. So
Avalons charter will have gone from "repository of framework and components
for server-side development in Apache products" to "glorified component
model" so that commons can adopt Avalons old charter. Would any other
project be subjected to such a change?
Another point to consider is the risk inherent in such a project. If you
look at most other attempts to do this sort of thing in the past they have
generally failed. The reason being that developing framework agnostic
components is difficult and much more work than creating framework specific
components. (Consider how hard it is to develope a good framework and
multiple the difficulty by 10). It is true that java is better than most
other languages and there is the JavaBeans standard that will help this
project significantly. Even with these bonuses it is a risky endeavour.
So I guess what I am trying to say is that if I had a vote it would be -1 ;)
If a project was proposed to focus on the infrastructure (ie
CJAN/standadisation/gump/whatever) then I think that is great +1000.
If the group wanted a CVS and place to birth such a idea in Avalons CVS
then as an Avalon committer I would +1 that (of course this depends on
PMC/other Avalon committers).
What I would object to is the PMC deciding to displace another project
without any good reason - unless of course that became a standard practice
(in which case I have a few proposals to submit ;]).
Of course I am sure I will get flamed for this - or told how I "just don't
understand" ? (Funny thing is they can't explain it either). Anyways both
Sam and Craig were on the library list so they should be able to indicate
if I am biased ;) I will try to answer any sensible retorts before I go
away for the weekend. Anyways - flame on !
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
