> 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.
> 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.
The library should not create new components - but let projects share
their own components.
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
).
> 4. Are you talking about shared standards? ie use JavaBeans+CJAN+...
I'm talking about sharing work and maintainance and code - by using
whatever gives us that. CJAN is a different story.
Things will probably self-organize - code needs to be factored out to
reduce deps, and the most likely pattern will be JavaBeans and packages.
> 5. Do you think you will need a new CVS and why?
Yes, a new CVS with a special access rule ( in at least on directory ),
allowing all jakarta commiters to commit.
Why ? Why not :-)
( my initial preference was to use jakarta-tools )
> >From what I understand you want a shared CVS that everyone has access to.
> Products are cleaned/extracted/refactored from their home project and
> placed into library CVS. The products whill have names like
>
> org.apache.share.digester
>
> Am I correct?
Yes.
> You said I obviously don't get it - well make me get it. Explain it in
> clear and simple terms.
Not easy.
> If the the only reason you don't like Avalon is
> because it has a history state that, if there is other reasons then state
> that aswell.
Yes, that's the main reason I think Avalon will not be a good choice for
those goals ( that doesn't mean I don't like Avalon, just that it would
hurt the goals, because a lot of people have opinions about avalon ).
Costin
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.
AS a matter of fact I like the idea behind avalon - even if I don't think
it can work.
