Knut Anders Hatlen wrote:
Rick Hillegas <[EMAIL PROTECTED]> writes:
Bryan Pendleton wrote:
II) A straightforward way for derby-dev(elopers) to plug in other
libraries to verify at compile-time that
a) the core engine doesn't spill outside the CDC/FP limits
b) the JDBC3 driver and network server don't spill outside the
JDK1.4 limits
Perhaps we are trying to force the build to do too much?
Would it be easier to verify this via testing, than at build time?
For example:
- to verify that we are compatible with JDK 1.4, we should test
under 1.4
- to verify that we are compatible with JDBC 3.0, we should test
under JDBC 3.0
- to verify that we work in a CDC/FP environment, we should
test in a CDC/FP environment
I have no idea whether this actually makes things simpler or
harder, just wanted to toss this out there to see if it was useful.
thanks,
bryan
I don't think this would be a step backward for CDC/FP support. We
rely on test-time checks for our claims about small device
support. For our JDK1.4 claims, I think that we already provide
support for plugging in the JDK1.4 libraries so that we verify that
support at compile-time. The incremental work here would be a little
tweaking to make the build use the small device libraries (rather than
the JDK1.4 libraries) when building the core engine and network
server. I'm guessing that this is just a little tweaking but the devil
could be in the details.
Another point is that we can't guarantee by testing alone that no JDK 5
methods have been used, thereby breaking the JDK 1.4 support, unless we
have 100% test coverage. Compile-time checks would also discover
problems in code paths that are not exercised by the tests.
I think a compile-time check would be best, if we are to continue
supporting JDK 1.4 and/or CDC/FP.
Testing would have to be done in addition, of course.
From what I read, I get the impression we're assuming everyone has to
compile against these libraries.
But is that really the case?
Why can't a smaller group go through the hassle of downloading the extra
libraries and configure the build framework accordingly?
I'm suggesting that even though we support these versions in official
Derby releases, building Derby against the libraries could be optional.
The main point with this, is to allow newcomers to build Derby easily by
using only one JDK. This might even attract more contributers.
The smaller group would typically be committers, seasoned developers
spending a lot of time working on Derby, release managers and testers.
The downside of such an approach is that some patches fail to compile
for this smaller group, because the contributer only compiled and tested
it with, say, JDK 5.0. In such cases the patch must be declined, or even
backed out if a committer committed it without proper building/testing.
--
Kristian
