At 04:30 1/3/01 -0800, [EMAIL PROTECTED] wrote:
>> So answer these questions. When you are talking about the library project;
>
>> 1. Are you talking about content/product creation/extraction (ie DB pool)?
>> 2. Are you talking about creating the infrastructure (ie CJAN)?
>
>Both are true - but it's not the main goal ( in my view ).
>The goal is to create a common ground and get inter-project work, and
>jakarta projects will cooperate by creating/extracting components and will
>need infrastructure.
well they are separate projects so you should probably treat them as such.
>> 3. Would you be willing to sign your name saying no new components are
>> created?
>
>I would be very much against creating new components that wouldn't be
>created in an existing project anyway ( i.e. if a project needs a new
>component or doesn't like an existing component - it can create what it
>needs ). I'm very much against creating components just because someone
>might need them - and until this works and we have all the infrastructure
>I would vote -1 on adding new code without a project sponsoring it.
>
>Again - that responds the concern regarding Avalon - where the stated goal
>of the project is to create components.
No it is not ... I am really feeling like a broken record here - Avalons
goal was to act as repository of components. It was meant to collect and
clean existing etc. It unfortunately only occured within it's tribe (ie
cocoon/james).
>The library should not create new components - but let projects share
>their own components.
that would be part of Avalon scharter.
>It's a fine distinction here - but I think that if someone just wants to
>develop components for server side, he should do it in avalon. If a
>project needs a component and prefers to develop it itself, he should do
>it in the library ( by following the guidelines and make it independent,
>or by placing it in the common repository for other projects to work on it
>).
So the only reason someone would use the library is if they didn't want to
work with Avalon? Is that correct? So you think we shout start a process of
sharing and collaboration by starting a new project with identical goals to
a previous project because you don't like the old project? That I don't get.
>P.S.: I personally have serious doubts about the viability of Avalon ( in
>any of the forms ) - I think the best people to create and maintain server
>side components are those who need and use them - i.e. jakarta projects
>like tomcat or struts or turbine. Having a project doing "components" is
>IMHO unlikely to succeed - but that doesn't mean it won't, or you
>shouldn't try - and I will be happy if it works.
Which is why if you have a look at Avalon recently that all the untested
components are slowly being deprecated and removed. Successful parts from
Catalina/turbine/cocoon are being migrated to Avalon as well as components
from my own projects. I agree that it was somewhat naive to try to build
components outside of real life use. This is one of the reasons I believe
that some of concepts where academic for so long. Until recently the only
tested/stable parts were those used in Cocoon. This is slowly changing.
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 |
*-----------------------------------------------------*
