On Fri, 04 Mar 2005 14:25:21 -0800, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: > I was trying to expand this model to support J2ME/CDC/Foundation but I > am now having doubts, mainly due to the requirement at Apache to be part > of Gump. Andrew had to modify various build.xml files (adding near > duplicate actions) and make the gump build a multi-pass affair. I don't > see how I can add J2ME support in this mode while also keeping Gump running.
Just to be clear, the near-duplicate actions were needed to work around a bug in Jikes 1.22. But yes, because of the way Gump controls the compilation classpath, it became necessary to split the engine build across JDBC 2/JDBC 3 lines. I might be able to simplify it somewhat from the current situation, but I haven't spent much time on it since I got it working. > The trick I then use is to modify the class file sometime after > compilation to mark it concrete by modifying the byte code in the .class > file (using Derby's class file utilities). Adjusting how we build in Gump for changing requirements is an inconvenience, one that I'm not sure really calls for going to such lengths to mitigate. I'd rather put the time in myself to keeping our build running in Gump than deal with problems caused by modifying the classfiles at build time (I'm thinking of all the fun I've had with obfuscation). :-) A more serious problem would seem to be: > - J2ME libraries not (easily) available Is there any readily available reference implementation for J2ME (w/JSR169)? How would Gump, or anyone, build Derby if we require J2ME reference libraries to build, but there's no available reference implementation? If the answer is: there is none, then I suppose we'll need to consider this anyway. Also, Kathey Marsden wrote: > Suddenly users have to think of which set of jar files to > download, we need to document when and why to use which and they may > need to download a different jar when they upgrade their jvm. If the choice is between J2ME and J2SE, then that's pretty easy, but I don't think we should have separate jars for different JDK revisions. That would get confusing indeed, not to mention be a real hassle for maintenance (and versioning, and, and...) Even creating a split between J2ME and J2SE shouldn't require splitting the codeline. The module system allows for creating different jar files with different sets of modules, although I think the code for this would need to be revived in the build. andrew
