disclaimer: I got a problem on my secondary mail server that made me
receive mails 1 or two days after thay were sent... this and my lazyness
makes me quite late :P but here's some comment...
"Geir Magnusson Jr." wrote:
>
>
> Anyway - I see that sentiment appears to be bimodal:
>
> 1) I got involved here because of my interest in seeing some of the
> useful bits of code present in Jakarta projects, code that generally is
> supportive of the project goals but not the goal itself, be brought out
> and maintained in a sharable, 'productized' manner. My canonical
> example is a DBConnectionPool, currently present in Struts, Turbine and
> apparently Avalon, among others. I feel this is the type of
> utility/component that is valuable not only within Jakarta projects, but
> for anyone building Java servlet-based software, and therefore a clearly
> chartered project delivering pooling/db pooling would be in-line with
> the Jakarta mission. Despite the 'alternative charter' of Avalon, the
> mythical 'Jakarta-Tools' project, I don't currently see a place in
> Jakarta-land where this goal is clear, public, and active. And if what
> I want to do is a dumb idea, I would really like it if someone told me
> so :)
>
> 2) The other mode is more oriented toward a 'library' or as I prefer,
> 'software depot', an open-access repository for miscellaneous bits of
> code that can be shared across Jakarta projects by all Jakarta
> committers. This too is tremendously valuable, although a bit of a
> departure from what I percieve as the usual Jakarta project model. But I
> think that's ok :) ( As an aside, Taglibs seems to be more of a hybrid,
> with a clear charter that allows the open library model. )
>
agree. we can have:
-repository for various code
-project for code sharing
-project for instances sharing (avalon)
to allow run time instances sharing, avalon must enforce on each part
(Blocks) very strong an well defined contracts.
to share code, in the form of libs, you need much less restrictive
rules. Even is coherence is desirable, each component is free to deal
with configurations the way it wants.
that's why I think avalon and this are only partially overlapping.
Anyway I'm very +1 in option 1. I whould be -0 on option 2...
Fede
