db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: DB2JCC, was: [jira] Updated: (DERBY-689) Various improvements to compatibility test.
Date Wed, 09 Nov 2005 18:15:45 GMT
Hi, Dan, thanks for your clarifications and the overall approach seems 

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 

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.



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.

View raw message