At 11:48 8/2/01 +1100, Conor MacNeill wrote:
>I think this last point is particularly strong in open source projects
>where a lot of people want to implement things themselves.
I think this is a more significant issue than any other. People like
hacking at code and unless the candidate code is significantly better or
there is someother incentive to work with it then it aint going to happen.
When the code is part of another largish framework then it is almost
invariably unwise to adopt it unless there is collaborators on both sides
who want it to happen.
>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.
There is a problem with this view point I suspect. There has already been
one project with such an aim. The charter of the Avalon project was to
provide support for things of exactly this nature.
http://java.apache.org/framework/need-for-avalon.html
http://java.apache.org/framework/call-to-vote.html
While it has accumulated some code - there was only support from 2 other
projects (namely JAMES and cocoon) - it hasn't become anywhere near what it
was originally envisioned to be. Instead what you have is rapid duplication
throughout all the projects ;)
Even worse - if you are watching commits you will have noticed that turbine
just increased it's charter to include general purpose server utilities (ie
it now encompases Avalons charter). Ironic that Jons complaining about the
way Struts aren't sticking to their charter, no ? ;) I don't see this as a
bad thing - just natural tendency. People want to see their work used by
greatest audience generally but want the "other" to adopt their framework
aswell.
Creating a new project to act as a repository for util code could work.
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.
The only way to "fix" this is to make each component self-contianed (and
very bean-esque). 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.
>The bigger
>issue is to improve our communications, cataloging, etc so reuse is easier,
>going forward.
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 ;)
>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 ...
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
