>The only way to "fix" this is to make each component self-contianed [...]
I agree.
>This will of course entail a lot of work and will
>actually also increase duplicity. Each bean will duplicate functionality
>present in frameworks because it can not rely on the framework. Hence you
>have not stopped duplication - you just
>changed it from per-framework to per-component.
I disagree. There are a number of clearly identifiable *services* that can
easily be made fully, atomically self-contained. The framework for a
connection pool, or a cache server, or a logging utility, or a regular
expression parser, or lots of other things is that thing itself.
Let's not sweat it if everyone wants to write their own StringUtil.java and
ExceptionUtil.java, like someone said much earlier on one of these threads,
that's Java 101 stuff. Let's focus on where we can add real value and where
there is real utility from reuse.
>However things like DB pools that work best when integrated into a
>framework will unlikely to see a lot of reuse (except the copy-paste kind)
>if the framework is not adopted.
I don't get it. Integration of the connection pool with another is simply a
matter of having/invoking a "borrow connection" and a "return connection"
method. Moreover, the JDK already has such factory interfaces--two in fact,
DataSource and Driver. It's simply a matter of abstracting away the way in
which the connection is obtained from the way in which it is used.
It's pretty clear, I think, that the "borrow it from a larger framework
project" approach doesn't work. Witness this
Avalon/Struts/Turbine/Town/etc. duplication. And this is done by people
well aquatinted with the Jakarta/Apache, imagine the experience of someone
new to the community.
Does it take more work to build and maintain these services in a modular
fashion? Well, it takes a *little* more work up front, but so does open
source development in general. But over the long haul it takes a lot less
work, and I'm measuring the long haul in weeks rather than years.
>I think there needs to be more infrastructure in place. Sams tinderbox
>stuff with automatic notification and a constant integration build would
>solve this. Combine this with the ability to build finer grain .jars and
>distribute them ala CJAN and it may work but I have my doubts ;)
Amen. This approach will require well-defined, stable releases, and a good
way to get to them. Fragmentation and mutating interfaces is a real
challenge here, but I see it is as a manageable one. (Part of it is just
waiting for the core set of services to mature to a level of stability.)
It has become abundantly clear to me over the past few months (and I believe
to others as well) that such a modular approach to open source java services
is warranted. If it's not going to live at Apache (and I very much would
like to see it live at Apache) then it's going to happen somewhere else.
And it should.
> > 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.
>
>It's up to individual projects IMHO. However if a project spurns reuse due
>to the NIH syndrome then they probably shouldn't have been accepted into
>apache in the first place...
The Wiki thread on the "Reuse/Release Equivalence Principle" seems
appropriate here:
"The granule of reuse is the granule of release. Only components that are
released through a tracking system can effectively be reused. This granule
is the package. This means that in order to effectively reuse code it must
be productized [...snip...] Users of the code are shielded from changes to
it because they can choose when to integrate changes from the package into
their own code. While this supports code ownership, and even promotes it, it
does not enforce it."
<http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple>
- Rod
(single >'s are from Pete, double >'s are Pete quoting Conor)
- Rod
(single >'s are from Pete, double >'s are Pete quoting Conor)
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
