The biggest problem with utility libraries is the release cycle and interim
stability. What has inevetibly happend on projects I've been on is that
project A needs something fixed in the Foobar package. But they also depend
on the current behavior of the Framis class. The current Framis class is,
however, undergoing refactoring, and the next release, that will include the
fixes they need in Foobar, will break Project A's app.
The only good cases of this kind of thing are stuff that is _extremely_
stable out of the box. The equivalent of libc, or rt.jar. With _long_
release cycles.
Otherwise you couple the release cycles of unrelated systems in pathological
ways.
Or projects clone the code and hide it.
-----Original Message-----
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 07, 2001 8:54 AM
To: [EMAIL PROTECTED]
Subject: Re: What is Jakarta?
Ted Husted wrote:
>
> On 2/7/2001 at 12:09 AM Geir Magnusson Jr. wrote:
> > That's exactly what I am trying to say. I know I can't propose.
>
> You or I can't call for a vote of the PMC * on * a proposal, but
> absolutely anyone can submit a proposal for a subproject.
Ok. I read it that one of the duties of the PMC membership was to
propose new projects. My approach was to badger and lobby Jon and Craig
(two PMC members that I have interacted with on other issues).
> As David Weinrich mentioned, a good place to start is any package named
> "util" in any of the Jakarta or Apache products. This could generate a
> list of candidates, leading to a package heirarchy. The committers on
> existing subprojects could be polled to see if anyone is interested in
> creating and mainitaining such a set of Platform Tools. If so, the
> proposal could then put this together and outline what might be in the
> first release of the product, and who would be doing the work.
Cool.
I am usually of the 'start small and iterate' mindset, so I would think
a really good connection pool would be an *excellent* start. Choose
another tool as well so that the notion of the project as a multi-tool
kit can be established from the beginning (ex. documentation and a
multi-jar distribution), but keep the deliverables list small, to what
people are making noise about.
<noise>
Connection pool, connection pool, connection pool.
</noise>
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named. Any use, copying or disclosure by any other person is strictly
prohibited. If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
