Utility/Library Projects [was Re: What is Jakarta?]

[Rodney Waldhoff <rw...@hotmail.com>]

I couldn't agree more.  A modular approach is the best way to encourage and 
accomplish the sharing of code, and to help people discover what exists and 
what doesn't.  Arieh's metaphor of picking components off the shelf seems 
right on to me.

I'd be happy to help in whatever way I can.

A few modules that come immediately to mind, in no particular order:

* Generic object pooling
* Database connection pooling
* Object caching
* Base64 encoding/decoding (or perhaps a more general endec package?)

I'm of no particular opinion whether this is best done as a single project 
or a bunch of little independent projects, although I suspect a single 
project with lots of pieces will be easier to standardize for documentation, 
structure, etc.  Something like the way jakarta-taglibs is managed seems 
like a reasonable model--relatively independent code-bases, but with some 
effort toward standardizing documentation, build scripts, etc.

I'd also suggest that while desirable, it's not strictly necessary to avoid 
all possible redundancy.  Leaving open the possibility of multiple, even 
competing implementations where reasonable seems in keeping with the 
bazaar-approach.  It's perfectly legitimate that different applications may 
require different functionality for what on the surface looks like a single 
component.  While every effort should be made to avoid duplication and to 
enhance rather than fork, simply stating "we've already got something that 
kinda does that" doesn't ipso facto invalidate a new approach. (cf. 
Davidson's "Rules for Revolutionaries".)  (Let me stress, every effort 
should be made to avoid duplication and enhance rather than fork.) I don't 
think this leads to too much duplication of effort, because I think the 
evolutionary forces from the community will lead us to a very small number 
of alternatives over time

Hence it may make sense to package this stuff under a "code name" even under 
this generic library/utility project (e.g., org.apache.*.foo.widget and 
org.apache.*.bar.widget (or *.widget.foo/*.widget.bar)) to avoid namespace 
conflicts.   Moreover, it may make sense where possible to define an 
interface module/sub-project as distinct from the implementation 
modules/sub-projects, to allow for a more interchangeable set of 
implementations.

- Rod

-----Original Message-----
From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
Sent: Wednesday, February 07, 2001 4:27 PM
To: general@jakarta.apache.org
Subject: Re: What is Jakarta?


Ted Husted wrote:
 >
 > I would frame it this way:
 >
 > 1. We have a shared utility subproject that would host an assortment of
 > components.
 >
 > 2. We have a subproject for each component.
 >
 > 3. Each subproject may host a utility library, which other subprojects
 > can use.
 >
 > (1) or (2) are going to depend on whether anyone has an itch and takes
 > the initiative. Otherwise, we default to (3). This might not actually
 > be a bad thing, so long as we have some type of CJAN facility so people
 > can find what they need.
 >

I'm getting itchy.  I think (3) puts us back into the same place.  I
think (1) is the best, simply because of the challenge of coming up with
kool names for all the subprojects you would have in (2)  :-D

geir

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: Utility/Library Projects [was Re: What is Jakarta?]

[Ted Husted <ne...@husted.com>]

On 2/8/2001 at 12:53 AM Rodney Waldhoff wrote:

> I'm of no particular opinion whether this is best done as a single 
> project or a bunch of little independent projects, although I suspect

> a single project with lots of pieces will be easier to standardize
for 
> documentation, structure, etc. 

A middle ground might be to create a root utilities package, like say
Apache-Zarf ;-). Everything beneath that would have boring functional
names, like "ConnectionPool". Each set of related Zarf classes could
have their own list, set of committers, and version numbers. People
could either pluck out the classes that they needed, and roll them into
their own products, or just adopt the zarf.jar wholesale. 

You could think of them as subproducts rather than subprojects, but
important attributes are that 

(1) the people authorized to work on a set of classes are real
Apache-style Committers to those particular classes.

(2) the subproduct classes have independent versioning and release
dates. 

The concern about an umbrella project is that changes to classes upon
which a product depends must be properly managed, or may become ad-hoc
and undermine their usefulness.

Zarf could have a set of core Committers (something like a PMC) to
ensure that the documentation and structure remains consistent, and to
cover any classes that have lost their own Committer (at least until a
new volunteer can be found).

< http://www.dictionary.com/cgi-bin/dict.pl?term=zarf  > 
;-) Not sure if I like it either -- but it sure is appropriate!


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/