Sam Ruby wrote:
>
> Geir Magnusson Jr wrote:
> >
> > 1) A central resource 'repository', as envisioned by Costin
> > (and others).
> >
> > 2) A central component 'Catalog', as envisioned by myself
> > (and others).
>
> Perhaps I'm dense, but I really don't see a sharp dividing line between the
> two.
Others seem to - it seems like this has been the underlying point of
contention to a full week of discussion.
> Is the point of #1 to include things that have absolutely nothing to do
> with the Jakarta mission? If so, -1.
No. To me, the point of #1 is to allow a different committer/project
model for projects that are either new, fit into the taglibs model of
"single-theme, mutltiple application/implementation", or are such that
fit into Costin's ideas of how sharing will work between proejects.
Anyway, I thought it was a given that all of this is in support of the
Jakarta mission.
> Is the point of #2 the ability to exclude people who have value and want to
> contribute? If so, -1.
Not at all, and I can't understand why you would even say that. I don't
think that has been anyone's intent, expressed or implied. :(
The point of #2 is to use the conventional jakarta model to take
portions of the Jakarta codebase (or new ones) that are useful to Java
developers engaged in server based development and 'productize' them
with documentation, support, and a community. This would just simple
augment the current 'Jakarta catalog' with a set of smaller bits that
any server/servlet developer would find useful.
It would imagine that this would be a way to bring even more people into
the Jakarta tribe - someone may know an awful lot about one of these
smaller projects, and would be interested to get involved.
The surface area of Jakarta is large. People just aren't aware of all
the things in the codebase.
Again, I will use the DB COnnection Pool as an example of a component
that is almost as requisite to dynamic website development as Tomcat is,
is present in multiple implementations across the Jakarta codebase, none
of which is packaged and documented in a way that is attractive or
useful to a developer 'shopping' for software.
That is not meant as a criticism, as the projects those DBCP's are a
part of simply needed the DBCP to support their primary mission.
> The essense of both is that ability to tolerate duplication and the desire
> to minimize dependencies. Note that I didn't say encourage duplication or
> eliminate dependencies; neither goal is practical or useful.
> Stable interfaces and robust implementations are critical success factors
> for both.
>
> If the difference is whether or not we should include people whether or not
> they have expressed any desire to contribute, then I will openly admit that
> I don't see the point of automatic inclusion at this time.
To me, it's not that. We can easily deal with either model, a hybrid,
or something new. We all want the same thing in the end.
The big difference is the approach and purpose of such a new
Jakarta-level project.
To me, the *purpose* of a catalog is to simply extend the Jakarta model
to smaller-scale but important projects that stand on their own. A
DBConnectionPool is such an example. They would be separately
documented, supported, installable, buildable, etc. It is not required
that the code come from existing Jakarta projects, although that is what
makes the most sense right now.
While nirvana would be achieved if Jakarta projects used these products
(like Velocity uses Ant and soon Log4J), that would only be because they
are best-in-class, and not required for success of a catalog project.
My understanding of Costins view of the *purpose* of the library is to
have a place where components that are shared between Jakarta projects
can be stored, shared, developed, etc. From what I gather, his vision is
that it would be a place where sharable but not necessarily
productizable things would be, and further, that generally speaking, it
would be code that already exists in Jakarta projects.
As an example, Turbine and Struts (and to some degree Velocity) have
the need for locale and internationalization tools [locale-supporting
template/page management, internationalized string resource management
tools, etc]. These may not have obvious standalone use (for whatever
reason) and therefore might not be something you could make separate
builds with, have useful 'user' docs outside of Javadoc, etc.
That's all I was trying to say : one is product oriented, the way
Jakarta is product oriented in it's project offerings, and the other is
share-collaboration oriented, to bring together the resources and talent
present in the Jakarta codebases.
geir
> If there is doubt that darwinian processes will achive stability of
> interfaces in any reasonable period of time, then I would like to contrast
> CPAN with some of the existing Jakarta projects which proport to make
> available reusable components with stable interfaces.
>
> What am I missing?
>
> - Sam Ruby
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
