Hi, Dan, thanks for your clarifications and the overall approach seems
reasonable.
The one thing I think is confusing and perhaps misleading is that the
JCC tests (for historical reasons I am assuming, because we didn't used
to have our own JDBC driver) are pretty intermingled with the main Derby
testing infrastructure: with the Derby test harness, the Derby testing
infrastructure (e.g. the suites), and the Derby testing documentation.
It would help a LOT if we were more clear about JCC being a consumer of
Derby as much as (as you say) Hibernate, JDO, etc. I'm not sure what
this would look like, here are some quick brainstorms:
- Cleaning up the testing docs as much as possible to make this
distinction clear (I have done a bit of this already).
- Maybe putting the JCC-specific tests in a separate directory like we
have done for the JUnit tests
- Taking JCC tests out of derbyall and making JCC tests an opt-in part
of the gate to checkin rather than an opt-out (e.g. those whose itch it
is to run JCC tests can explicitly do so).
- I don't think we need to do anything extreme like yanking the support
for JCC out of the harness, I think that would be somewhat silly and
unhelpful.
If there is general agreement that there is nothing wrong with making
this distinction more clear (e.g. it doesn't break existing
functionality, doesn't degrade the quality of Derby, and is not against
the charter of Derby), then it seems to me that those who have the itch
to make these types of clarifications should feel free to do so.
Thanks,
David
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Hi David,
Thanks for this improvement.
Right now, the DB2 JCC libraries are required for running the full set
of combinations.
Should the DB2 JCC libraries be required to run Derby's tests?
The suite derbyall skips the JCC tests (derbynetmats) if JCC is not in
the classpath.
I don't understand Derby's long term relationship with
this code.
It's actually very simple. DB2 JCC should be treated like any other
program that works with Derby, say Hibernate, Apache James, JDO, IBM
WAS, Cheese Lab etc.
Some aspects of DB2 JCC that maybe make it look different are:
- it uses the socket based api to Derby defined in terms of DRDA.
- tests have been contributed that test DB2 JCC and Derby.
But, I don't believe they give it any special status compared to other uses.
As we add new JDBC support (e.g., JDBC 4.0), we have no
control over the behavior of this client.
Not sure what point you are trying to make here. The DBC JCC client
supports JDBC 3.0 and works today, if Derby has added JDBC 4.0 to its
clients, how does that affect an independent client?
Do we expect customers to
migrate onto Derby's client as of 10.1?
Not sure we "expect" anything, people use what they want.
I'm not aware of any discussions
about either continuing or sunsetting support for DB2 JCC.
It's really about code contributions.
- Any submission (or commit) that breaks existing functionality/api's
has the potential to be vetoed.
- A submission (or commit) that follows the specs, does not change the
api, but breaks some specific use of that api, then really it's the
problem of that use to resolve it. The actual case may determine how we
treat that submission in terms of commiting it and/or trying to resolve it.
I guess its also about that itch, if people have the itch to continue
supporting JCC (or anything else) then they will put effort into it. The
only decision point comes if that effort is in some way preventing some
progress on something else, someone else's itch. Then neither is more
important than the other, it's up to the community to discuss and decide
the direction or solution.
Dan.
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
