Continuing the "What is ..." theme.
I don't have a stake in the current DB Connection pooling argument. I don't
use either pool in my day to day work or within Ant. However, I have found
the discussion interesting, especially as I have just read Richard
Gabriel's "Patterns of Software". He deals with reuse a little and I think
he makes some interesting points:
"First you need a central repository of code. It doesn't help if developers
have to go around to other developers to locate code you might be able to
use"
"Second, there has to be a means of locating the right piece of code, which
usually requires a good classification scheme. It does no good to have the
right piece of code if no one can find it."
"Third, there must be good documentation of what each piece of code in the
repository does."
"For a lot of pieces of code it is just plain simpler to write it yourself
than to go through the process of finding and understanding reusable code".
I think this last point is particularly strong in open source projects
where a lot of people want to implement things themselves.
Anyway, what all this says to me is that if we want strong reuse across
Jakarta projects, we need to make reuse easier. We need a way to find code
that can be reused. If we are to have a utility project, then it must
produce not only the code, but a code catalog which facilitates reuse. I
think such a group could range over all the Jakarta projects, looking for
code that can be packaged for reuse. I would prefer to see modules with
little coupling rather than a framework approach. Building such components
can be hard. If we don't want a centralized project to own the code,
another idea could be to have a central catalog maintained across the
Jakarta projects. The Turbine folks, Struts folks, etc could "advertise"
all the modules they provide. There would be implications for how projects
package their software.
So now we have connection pooling code in two places. Duplication isn't
great but it happens, and sometimes it even happens in the same project. It
is a refactoring opportunity. Now that we have recognized that, surely we
can find the best solution, find somewhere for it to live (which may be
where it already lives) and increase our reuse going forward. The bigger
issue is to improve our communications, cataloging, etc so reuse is easier,
going forward.
This seems to me to be exactly the sort of cross-project issue the PMC is
designed to handle. Perhaps the PMC should consider whether to adopt a
policy of reuse across Jakarta projects, what that policy might be, whether
the policy should be promoted through a library subproject, etc.
I can recommend Gabriel's book. It is a fascinating and very different book
about software.
That is my 2 cents worth. Back to releasing Ant 1.3 ...
Conor
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
