"Craig R. McClanahan" 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. ^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^
This is your <FOO>, and <BAR> then is clearly defined. To me, this is
a <FOO> that is generic - like 'visual component' or 'bean' - it is a
general class of software where the functionaly is a degree of freedom
left to the creativity of the developer. So you can say "Here is a
collection of <FOO>, listed by functionality."
I think this is a valuable model - clearly the Taglibs projects shows
it's a valuable model. But I am not sure that all the projects in
'Rupert' would work well this way. For the 'single-instance' model, it
would be harder to say "Here is a collection of JDBC-compliant DB
connection pools". How can you distinguish?
There certainly is space for both, or if you make <FOO> generic enough
in each case, then the overall project model can consists of a set of
libraries, each hosting a subject area :
POOLS : (works as library )
- generic object pool
- JDBC DB connection pool
- ?
XML Configuration : (works as library)
- this would be a big list
ETC:
And each library (POOLS, XML Config) could manage the components within
in, similar to how a Jakarta project manages its own work.
[SNIP]
>
> 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.
Yes, but we should recognize that if the multiple <FOO> are something
like a DB Connection Pool, the 'rule' would be that the differences in
features and uses should be *clearly* enunciated, to the point of making
sure the non-Jakarta developer looking for a solution can easily
understand the differences, and make a decision. Otherwise, they *will*
go elsewhere.
Maybe my concern for the non-Jakarta developer is misplaced or
misaligned with the intent here, but as I have said before, there seems
to be an *enormous* amount of useful code for the Java developer
scattered around, and finding a way of clearly describing, presenting
and organizing it for general use would do the development community
(and ourselves - nothing beats writing software that is actually used) a
big favor.
> 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 ;-).
that's a great idea.
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]
