"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]
