Jeremy Boynes wrote:
Having one JAR for the database is nice, but not if the price is post-compilation bytecode hacks.
So how does everyone feelf about pre-compilation sourcecode hacks?
Would someone please state the need a little more clearly?
I think there are two basic problems here:
1) How do we provide implementations of the JDBC interfaces? The problem here is that JDBC3.0 (JDK1.4/1.5) added classes to the API in java.sql that are not present in JDK1.3 or JSR169 JVMs.
Perhaps the solution here is to have two separate modules that implement the APIs and which are compiled with the appropriate VM. We can avoid post-compilation hacks and although we could use source code pre-processing I would suggest it may not be necessary as the modules would mostly just be delegating to internal Derby classes making it trivial to support two separate code trees.
This is very similar to how the build works now. We may be able to simplify this by building the API implementations totally separately so most of the time people would just use the one for their platform.
2) How do we provide different configurations for distribution? Essentially, are we sticking with the one-jar-fits-all model or should we break things down into separate modules that can be built and packaged separately. In the separate module model, different versions could be built for different platforms and assembled into distributable configurations as needed but users would need to select the configuration applicable to their environment.
If done right, the separate module approach can work very well e.g. Apache HTTPD, Eclipse, Maven and is well suited to the distributed development model that is open source; it can also go horribly wrong if not managed properly.
Back last year I did some experimentation with Maven about breaking down the build into a module structure. If anyone is interested I could try and finish that up so folks can have a look.
-- Jeremy
