|
From: John G. <jge...@ny...> - 2001-04-27 20:34:35
|
> I am a little confused. Why would you need to specify the -jar option? > Since that option is set-and-forget, and it specifies where jEdit is why > not just have it be the path to the classfile (jedit.jar) but then > iunternally always add the file to the classpath on the command line, > followed by the jEdit classname? The user should never know if you are > calling the class by name or with the -jar option. The only class that > will be called is jEdit itself. So I don't see a need to customize beyond > having a way to sepecify the jEdit jarfile location and the jEdit > classname (which would be optional, guessed by default). Sorry, I'm not being clear. I'm not requiring use of the -jar option, I'm allowing it. If Slava woke up tomorrow and decided to put the application's main() method in another class, she could point the manifest.mf inside the jar somewhere else and a -jar option command line would run without needing a change. Obviously, that's not very realistic (um, right Slava?), but anybody who takes the time to type in a command line should be able to type in anything that works. That is how I would like to fashion jEditLauncher. What I would ask at this point is that you look at the source code for CJEditLauncher::Launch_jEdit() in my next release (because I got some cleaning up to do right now). You should be able to drop it into your Windows code without skipping a beat, and people can do whatever they want to do with command options. If your Windows code defaults JEDIT_TARGET to a classname, you're excluding the use of -jar in the default case. That's fine if strstr(<JEDIT_JAVA_OPTIONS>, "-jar") returns 0; otherwise, the user doesn't want to use the classname and has to tell you where the jar file is. That becomes JEDIT_TARGET. You can't avoid requiring the user to identify the path to the jar file, however. It's either part of the classpath or it's the target. If you're OK with JEDIT_TARGET, I think we have our ini interface resolved. John |