Jeremy Boynes wrote:
> > A lot of the problems here arise because we are trying to support 3 > different JVM revision levels with one output JAR. Is this time to > consider generating multiple output JARs, one for each VM? I'm not so sure this is true. I think we can separate the build issues from the packaging issues. In order to support J2ME, JDK 1.3, JDK 1.4 and JDK 1.5 we have to build code that works in those environments, how it is packaged to run is separate. Can we focus on the build issues first, and then maybe have a packaging disucssion. If we can't solve the build then the packing discussion doesn't matter. Currently we require developers to download the correct environments and use them. I think is is fine to continue like this, but there are two or three problems. 1) The availability of J2ME libraries 2) GUMP - It seems Derby has to be part of Gump, but Gump's philosphy is very different to Derby's, it basically says the product build rules are wrong and it must build using gump rules. Maybe I'm wrong on this? 3) The burden on the developers of having to download 4 environments. Also Jeremy said this approach (using modules) would lead to an ever growing number of modules, that tends not to be the case, since as I think Rick pointed out, at some point environments are dropped from support, such as Derby used to support JDK 1.1 and no longer does. Most of the split between 1.1 and 1.3 code has been removed. Dan.
