On Thursday 10 April 2003 07:51, Nicos Panayides wrote: > There are more than one ways to do this. My suggestion is to have two > packages: > > cdk-java (command line) > cdk-gui-java (swing stuff) > > the command line package needs to be compilable with a free javac (gij, > jikes etc). As for the binary I don't think it provides any real benefit > besides a slightly reduced startup time (and even that is not always the > case). Just make a wrapper script that calls java with the appropriate > options/classpath.
Compiling it with just a free javac does not get it into main, as is... it needs to be run with a free VM too... Having a binary this is no longer a problem, i.e. there is no need for the free VM... therefore, I would prefer that. I am thus looking for something like cdk-lib (with the .so + the .jar for the same 'library' functionality) cdk (with the binary executables) cdk-java (with swing stuff) > Making a binary would cause problems if the gui stuff > uses classes from the command-line package. Rigth, hence my question. The solution to this latter problem, of course, is to have both a .so library used by the binary, *and* the corresponding .jar for the GUI stuff... > Roughly you will end up with: > > cdk-java Depends: java-virtual-machine > cdk-gui-java Depends: cdk-java, java2-swing (or whatever). Thus getting something like: cdk-lib Depends: (empty because of .so part) Suggests: java-virtual-machine (for .jar part) Build-Depends: java1-compiler cdk Depends: Build-Depends: java1-compiler cdk-java Depends: java2-swing Build-Depends: java2-compiler Egon