Hear hear! I think that Taglibs is an excellent model
for a library-oriented subproject. Here are some
features of Taglibs (some overlap with Craig's
comments) that I think would translate quite well:
* individual landing pages for each taglib
(essentially sub-subprojects)
* standardized documentation formats in most
taglibs
* clearly defined divisions between tag
libraries in the CVS repository
* "courteous" interaction between taglib
developers (i.e., I don't muck about with
your taglib without asking)
* lots of user interaction on the dev list
esp. concerning release candidates (which
neutrilizes maverick developer
syndrome and reduces the necessary number
of committers)
* reasonable scope boundaries (e.g. the JDBC
taglib doesn't do database pooling, that's
what utility libraries are for!)
* it's fun to work on!
Although I'm not interested in being a committer on
any of the other proposed library sub-subprojects at
this time, I'd be happy to help out with the "Library
Infrastructure" sub-subproject, if the goal is a
Taglibs-like organization for the project and the
site.
- Morgan
--- "Craig R. McClanahan"
<[EMAIL PROTECTED]> wrote:
> "Geir Magnusson Jr." wrote:
>
> > [EMAIL PROTECTED] wrote:
> >
> > > If someone chooses to duplicate a piece of code,
> maybe the problem is with
> > > the way the code is written and shared.
> >
> > I think in some cases, its bacause people aren't
> aware that the stuff
> > exists. Go through the Jakarta project sites, and
> find the number of
> > places that offer a separate, clean <FOO> tool
> that supports <BAR>.
> > (Choose your tool and it's expected
> functionality).
> >
>
> One small proto-model of "shared code" code
> components already exists within the
> Jakarta community, and might serve as a starting
> point for discussions -- the
> Jakarta Taglibs project, which is focused on
> creating reuseable JSP custom tag
> libraries. The encouraged sharing is in this case
> at the end developer's
> application level, rather than within the Jakarta
> community itself, but some
> practices we created there might be useful models to
> look at.
>
> Basically, developers on Taglibs agree to the
> following conventions and
> policies:
>
> * No particular concern about overlaps of
> functionality -
> different applications care about different
> features and
> might appreciate alternative approaches.
>
> * Committers essentially take ownership of the
> pieces
> they care about, and agree to offer at least some
> level
> of ongoing support.
>
> * Organize their tag library directories according
> to standard
> conventions (source, example app, documentation)
> and
> package naming hierarchies that quickly become
> familiar
> to library users.
>
> * Construct semi-autonomous releases of individual
> tag libraries,
> plus a convenient way to go grab them all. Formal
> versioning
> hasn't been an issue yet because the whole thing
> is pretty new,
> but that will need to be addressed.
>
> * Make information (essentially, the documenation
> associated
> with each tag library) available online and
> accessible. Having
> one or more <FOO> modules in a shared library
> doesn't help
> any more than the current situation, if I don't
> know about them
> or cannot find anything out about them.
>
> It would seem reasonable to adopt some set of
> conventions like this for the
> sorts of code modules we're discussing here. That
> way, people whose itch is
> creating shareable modules have a place to showcase
> their wares, and people who
> would rather reuse than write have a place to
> "shop".
>
> As long as you avoid a rule that there will be only
> one kind of <FOO> in the
> library, that should avoid most of the potential
> conflict issues.
>
> In order to make this work, someone(s) needs to step
> up and organize the basic
> infrastructure, but after that it can be fairly
> self-sustaining. (And maybe Sam
> can extend Gump to see which individual modules are
> being used in which projects
> -- having your shared code selected by some other
> project is a pretty good vote
> on it's quality, plus an indication of who you
> should talk to before changing
> APIs ;-).
>
>
> >
> > geir
> >
>
> Craig
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
=====
Morgan Delagrange
Britannica.com
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
