Sam Ruby wrote:
>
> Geir Magnusson Jr. wrote:
> >
> > I will use the DB COnnection Pool as an example of a component
> >
> > It is not required that the code come from existing Jakarta
> > projects...
> >
> > While nirvana would be achieved if Jakarta projects used these
> > products...
>
> I don't believe that the above were taken out of context, feel free to
> disagree.
>
> Warning: I am trying to put words in your mouth to see if I can draw out
> the truth. Again, feel free to disagree.
>
You shouldn't be warning me. Now my guard is up :)
> By the sentences I have quoted above, it would seem to me that you see a
> possibility of a SUCCESSFUL "catalog" entry which consisted of a DBCP which
> was "separately documented, supported, installable, buildable, etc." but
> was *NOT* used by any Jakarta projects. From what I gather, Costin would
> view this as a failure.
I would personally view it as a failure as well - just like I would view
it if Velocity and things that used Velocity (Anakia) weren't used by
other Jakarta projects - because it would be saying that its peers
didn't believe that a component, whose functionality they [claim] to
need, doesn't support their needs.
I am saying that (for what I want) it shouldn't be REQUIRED that it
come from an existing Jakarta project, and shouldn't be REQUIRED that it
be used in other jakarta projects.
For what I want, it should be REQURED that it can stand alone and is
useful for people building server/servlet solutions in Java. That's
really my primary interest. I bet there are tons of stuff that are
buried that could come out and be useful to people. DBCP is just one
example.
Note that :
1) A DBCP that supported standard JDBC API, interfaces, etc is something
that Turbine doesn't have or need (or some don't feel it's needed) - the
point is that current projects may not need a generalized version of
something and are happy with what they have, or exploring new
models/patterns such that the canonical rendition doesn't satisfy their
needs (although it may satisfy 95% of the Java development community
where canonical and safe gets them through their workday...) Turbine is
again this way - the idea that they build a database abstraction into
their framework, so it just doesn't matter. (Again, this is an area of
ongoing discussion in Turbine-land, and as a disclaimer, I am just a
Turbine lurker for the most part, so the above may be entirely false.)
2) A bootstrap problem : if there is something not currently used in the
Jakarta projects that is important to developers, you can't get it
started with the 'must come from within Jakarta' dictum. (Hence the "It
is not required that the code come from existing Jakarta projects...")
3) A bootstrap problem : I can start making a <FOO> tomorrow, and I
guarantee that for anything vaguely complicated it will not be of a
quality useful to anyone for a while. Projects will need time to
mature. The question is how long do you wait. Hence the bit about
"While nirvana would be achieved if Jakarta projects used these
products..."
4) A community problem : If things had to come from within Jakarta, how
would someone show up with something new and different (although maybe
small and vertical)? Where do you put it? A peer in the Jakarta family
to Tomcat? There are already noises about what to do about Ant, Log4J
and the regexps, right?
Some may consider #4 sophistry, as I guess Jakarta has historically been
very open in this sense. But as the servlet landscape grows as the
technology matures, the vertical specialization of new projects will
increase. A 'sub-Jakarta' like catalog project would be the ideal home
for things like that.
> Geir, would you be willing to concede that use by one or more (and
> preferably more than one) is an indication of success. In other words,
> which it may not be a reason in your eyes, it certainly is the desired
> result.
I don't understand the phrase "which it may not be a reason in your
eyes", but I will answer what I think you are asking.
I hope the following is clear : Yes, I feel this is *certainly* a
desired result.
I think the most likely way this will happen is ensuring the right
people are involved, and since those people answer to the PMC, the PMC
has a big stick to make this happen. Or, if currently the bylaws
*don't* give the PMC a big enough stick, bake it into the library
charter.
I believe am not 'conceding' anything with this statement, nor is it
contrary to my suggestion of recoginzing the difference in the two
'camps' : at all times, from the beginning, including pre-'library'
independant activity on my own privately lobbying Jon (for Turbine) and
Craig (for Struts) to do a DBCP that both projects would share but
would also be a 'product', I have been interested in simply getting
things that are buried in Jakarta projects out and into the light of
day. I dropped that effort when discussion started, as it was *obvious*
a community effort would of course be *easier* and *faster* than one guy
with a vision lobbying leaders of existing codebases, getting them to
work together. ;)
Seriously, I apologize if anything I have said was misleading in this
regard.
>
> If I am wrong, please correct me. If I am right, please tell me how this
> position is OPERATIONALLY different than what Costin seeks?
I think you are wrong about what I am saying, and I hope the above
clears it up.
Quite honestly, I don't know 100% what Costin seeks. I thought my #1
was what he seeks. For what it is worth, I see it as valuable, I
support it. However, I can't help right now, but I will when I can.
What I *believe* is that what Costin seeks is different from what I
seek, simply from the direction the result is approached, and with the
difference that I don't think that Costin values the 'productization'
initiative, as his driving interest is different.
I want to ensure that we can bring things out useful things, make them
easy to use, install, understand, and find for both the Order(10^2)
people that are Jakarta developers, as well as the Order(10^whateveR)
developers that are making server/servlet software/solutions with Java.
I see Costin's view as something more oriented to internal Jakarta use,
something primarily to enable easier sharing of code between projects,
as well as help community involvement. I agree with both of those
points.
Fundamentally, what I am trying to ensure is that the productization /
projectization doesn't get lost in this scuffle.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
