Rick Hillegas wrote:
Kristian Waagan wrote:
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?
Hi Kristian,
I think we're converging on the same goals. What I meant by (I) was what
you are suggesting: we want a default build which works for anyone who
just downloads the Derby source and Java 5 jdk.
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.
Right. And that's what I was trying to say by (II): we can rely on
interested community members to configure the build so that they get
compile-time checks for CDC/FP and JDK 1.4 support. As you note, the
practical implications of this are that we discover build problems
lazily and may have to back out bad patches if we discover later on that
they break the CDC/FP or JDK1.4 contracts.
Regards,
-Rick
It is likely if such an approach were taken, that the builds used to
produce the tests results published at the derby public site from ibm
would continue to use a jdk14 jvm to do the build. So it would be good
to make it easy to configure the build to continue to use 1.4 after
whatever changes in this area is implemented. These are publicly
available at:
http://db.apache.org/derby/derby_tests.html
under the IBM Regression Test Results link
I also believe it useful
to continue 1.4 support such that the small device jvm's can be
supported. But agree that it would be useful going forward to allow new
developers to work with jdk15, but provide as quick feedback as possible
if they use 1.5 specific features that would break 1.4 derby support.
If no implements the stub approach it may be useful to require patches
to be tagged against which jvm they have been compiled against, to give
a heads up to committers to check against 1.4 or not:
http://people.apache.org/~myrnavl/derby_test_results/
