Morgan Delagrange wrote:
> --- Sam Ruby <[EMAIL PROTECTED]> wrote:
> > Geir Magnusson Jr. wrote:
> > >
> > > So in a sense, Directory is another library
> > project with open
> > > rules (like agora). (Not sure if Agora was going
> > to be a
> > > Library peer in Jakarta-land, or a 'product peer'
> > in Library-land.
> >
> > My biggest concern is that I don't understand the
> > relationship between
> > Library, Directory, Agora, and Avalon.
> >
> > Avalon has been in the process of splitting into
> > multiple cvs repositories,
> > using the naming convention of jakarta-avalon-xxx.
> >
> > It would be a simple matter to create a
> > jakarta-avalon-dbpool.
> >
> > 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 think this is the key distinction. I've lurked on the avalon
developer's list off and on, and this seems to have been the primary
focus.
>
> 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.)
>
The shareable thingies that I care the most about are typically smaller
than a framework. In fact, dependency on a particular framework (of any
nature) is probably detrimental to reuse.
Example 1: the connection pool in Struts is 2 classes, with
dependencies only on the JDK and the JDBC 2.0 Optional Package APIs. It
uses JavaBeans property setters for configuration, so you'd write your
own mechanism for initialization (using whatever approach your framework
favors), but the pool itself doesn't mandate anything.
Example 2: The BeanUtils/ConvertUtils/PropertyUtils classes in Struts
are just a bunch of publicly available methods that work together for
introspecting JavaBeans. They rely only on JDK APIs, and have no
connection to any sort of probramming model.
>
> 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 on fine-grained JAR files -- this is one of the better parts of the
CPAN approach.
When we get down to process details, I'm going to recommend that we
record dependencies in the MANIFEST.MF file of our JAR files, in the
manner recommended in the JDK 1.3 documentation describing "system
extensions". In suitable environments (for instance, any servlet
container that implements 2.3), the container will even do this checking
for you.
>
> 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?
>
> Turbine seems like the wrong choice. Where is the
> documentation for the dbPool? Is it adequate on its
> own, or will the taglib implementer have to configure
> lots of unrelated Turbine functionality as well? I'm
> also somewhat uncomfortable pointing people to the
> Turbine project, many of whose members are anti-JSP
> and therefore anti-Taglib. The last thing I want is
> for users to be met with condescension when they ask
> the Turbine mailing list for help, which is quite
> possible in the current political climate.
>
> 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.
>
In order to be usefully shared, the dbpool should be in a separate JAR
as you recommended earlier.
>
> So, I guess I could go to Avalon and ask them to
> implement a database pool, but I'm still faced with
> the same old questions. How much of the database pool
> is going to be tied up in the Avalon framework? How
> self-contained will the documentation and
> implementation be? Who's going to write it?
>
> This is a specific example, which to me underscores
> the need for a framework-independent repository of
> mini-subprojects.
>
> 3) Different scope
>
> The Library project should specifically steer clear of
> developing grand frameworks. That kind of development
> is much more appropriate for full-blown subprojects
> like Turbine, Struts, and Avalon.
>
Agreed ... see comments above.
>
> 4) Convergent goals
>
> When possible, other frameworks can plug Library
> components into their framework. The Library project
> is not intended to be a replacement to Avalong, Struts
> or Turbine. Rather it's a place for convergence,
> where they can farm out self-contained components and
> focus on the means for tying them together.
>
> In some cases, a component may be able to be
> completely external to the project. For example,
> perhaps Struts does not really need to reference
> directly the database pooling code, if it can still
> grab connections from a JNDI DataSource or a pooling
> Driver. Then we've really reached Nirvana, components
> with interfaces so clean that we can literatlly swap
> implementations in and out at will.
>
> As long as we focus exclusively on frameworks, I think
> it will be very difficult to reach these ends.
>
> - Morgan
>
Craig
