Morgan Delagrange wrote:
>
> --- Sam Ruby <[EMAIL PROTECTED]> wrote:
> > I'd like to hear consensus with someone representing
> > jakarta-avalon (i.e.,
> > Peter Donald) before creating another subproject
> > with overlapping goals.
>
> Hmm, it would be a damn shame to shoot down the
> library project after making so much progress.
>
> Here's my analysis of Avalon vs. Library, with a
> little Turbine and Struts sprinkled in for good
> measure.
>
> 1) Different charters
>
> Avalon's charter is:
>
> The Avalon project is an effort to create,
> design, develop and maintain a common
> framework for server applications written
> using the Java language. This framework will
> not be a standalone product, but will allow
> existing and yet to be created server
> applications to fit into a common platform
> and to share code, design and human resources.
>
> Note that Avalon is a _framework_ for servers, which
> is clear from the API's many interfaces for request,
> responses, pools, properties, etc.
I made that mistake too :-)
It appears that is their 'cover charter'. Their *real* charter is
something else :D
Peter will chime in shortly, I assume.
> The Library project is quite different. It's goal is
> to create components, as self-contained as possible,
> that perform (generally speaking) a single useful
> function. More specifically, one can implement
> Library components _outside_ of the Avalon framework.
> (Turbine is a better example of a project where it is
> necessary to implement the framework to make use of
> the database pools, etc.)
+1
> 2) Different organization
>
> Our intention with Library is to make each component a
> microcosm within the Library subproject. A component
> has its own documentation, including FAQ, quick start
> guide, etc. It's available as a seperate JAR and has
> an explicit list of required/optional dependencies on
> other JARs. This should make sharing much easier,
> since it will provide a grab-bag of functionality that
> can be used without becoming tied to a framework.
+1
> Here's a specific example of the dilemna caused by
> wrapping all our functionality in big projects. I
> have a little JDBC tag library that we're about to
> release in Taglibs. However, it's ridiculous for me
> to implement my own database pooling for the tag,
> because that's way out of scope for the project.
> Therefore, I'd like to point to somebody else's
> database pool. The question is, whose?
Struts'. All you JSP weirdo's should stay 'over there' ;)
> Turbine seems like the wrong choice.
> [SNIP]
>
> Struts is probably more appropriate, but it's still
> one big JAR. It's also a "framework for building web
> applications" where the inclusion of a database pool
> seems, frankly, incidental. It's a good
> implementation, but it's a little buried within the
> website. In face it's not obvious to the uninitiated
> that their database pool even exists.
BINGO. This is *exactly* the same thinking that motivated me to start
persuing this. I needed a DBCP, I saw that Turbine's was really
tailored for turbine [which is fine - it is what the need and want], I
saw that Struts' was more what I needed interface-wise, but still buried
in Struts, so I wanted to pull out Struts', steal ideas from Turbine,
document and ...
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
