This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
E.g. "-branding" etc. should be "--branding" etc.
*** Issue 32079 has been marked as a duplicate of this issue. ***
Issue 32079 maybe duplicated but in such case we have to make this one block issue 31065.
Some kind of proposal available at http://openide.netbeans.org/proposals/arch/cli.html
Let's not forget --version which is missing currently. Frankly I'm not sure what it should return, given the existence of modules, but something at least. Maybe just cat ${netbeans.home}/build_info if it exists, else print to stderr a metaphysical discourse on the nature of identity. :-)
Tim said that he can do it and also mentioned that he is able to do it till december. So I am reassigning this to him and changing target milestone.
Funny, I don't remember volunteering for this...
I such case, I am sorry for such misinterpretation. Please unsign yourself from the bug then.
I'll do it, it's not a problem. When is it needed by?
Last I recall, we don't need this until D, so there is no rush.
I had a lunch with Trung and Tim and we talked about this issue, about Tim taking it over, as he has some free time soon and about trying to fix this for promotion B. Based on this I have changed the owner and target milestone of the issue. But in the light of Tim's posts, I have a feeling that I am either schizophrenic or I was talking to completely different Tim. Otherwise I cannot explain why he does not remember this being discussed. So once aqain. If I made wrong changes to the issue (Tim owner, target milestone 4.0), please excuse me and correct it.
No, Jarda, I clearly recall *you* volunteering me to do it. I just didn't recall liking the idea so much :-)
I propose to change the option to something like this by chaning the runide.sh launcher (and possibly runide.exe as well) and especially all java CLIHanders (in core and in utilities/openfile module). The help would look like this: Usage: ./netbeans/bin/runide.sh {options} arguments General options: --help help on more parameters (not interpreted by launcher) --jdkhome <path> path to JDK (could also be just JRE but some modules may not work!) -J<jvm_options> passes <jvm_option> to JVM Classpath options (normally you should NOT use these): --cp:p <classpath> prepends <classpath> to classpath --cp:a <classpath> appends <classpath> to classpath Command-line options: --ui <UI class name> use given UI class as the IDE's Look & Feel --fontsize <size> use given number as the base font size of the IDE user interface, in points (11 default) (but see http://ui.netbeans.org/docs/ui/themes/themes.html) --locale <language[:country[:variant]]> use specified locale --userdir <path> user settings directory (${userdir} by default) Rarer options (definitely not supported!): --branding <token> use specified branding (- for default) --nologging do not create the log file --nosplash do not show the splash screen --nogui just start up internals, do not show GUI Open File Module options: --open FILE open FILE. --open FILE:LINE open FILE at line LINE (starting from 1).
Created attachment 12582 [details] Implementation
The implementation makes all options printed in help getopt complient (either one letter option or begins with --), but it keeps the old versions of options for backward compatibility. The implementation changes processing of --help in runide.sh to continue and invoke the java launcher, this it fixes issue 24183 because all option help from all available modules is printed at once. It also allows to move the final processing of --userdir argument into the java launcher, but this is not necessary (e.g. runide.exe can remain unchanged).
If user should not use -cp:a and -cp:p switches, why not changing them to something like --Xcp:a and --Xcp:p, the same way how JDK uses non-standard switches. It would clearly differentiate these 'advanced' switches from the ordinary ones. The same could apply to -branding (--Xbranding), -nosplash (--Xsplash)_, etc ...
I'd suggest a small change: General options: --help help on more parameters (not interpreted by launcher) --morehelp help on advanced options (put branding & other exotic options in --morehelp) Also, why not --java == -J-D?
+1 on --X prefix or similar for unsupported options, with --X itself printing help for these options - consistency with JDK.
I am affraid java consistency will not be seen as advantage, so following their examples -X might not be the good thing. Re. --branding. I suggest to move it to stable. Re. --nologging, --nosplash, --nogui, I suggest to support them, but not print inside --help, I will document in <api/> tags that they are deprecated. Re. --cp:x I prefer to remove the warning above or not printing the help at all to using -X option I propose to use "under development" stability for most options but --help
Re. --help, the description is incorrect, right now it prints all options, there is no other improved help.
Created attachment 12623 [details] Full output and output when JDK cannot be found
Created attachment 12624 [details] Implementation II.
Implementation II will be commited at the begining of year 2004. Thanks for reviews.
Patrick, this could also affect documentation. If I commit this week is everything ok for you.
Created attachment 12698 [details] Proposed changes in runide.cpp - not tested, I do not have a way to compile
Created attachment 12745 [details] Impl III. which comes with public static String org.netbeans.Main.usage() which should be used from runide.exe to get the java part of --help description
Created attachment 12747 [details] The previous patch contained some garbage (CloneableEditorSupport), this one removes it. Sorry.
In half an hour I will commit Yarda's patch and the additional changes in runide.cpp. I did a few modifications to Yarda's patch. --ui changed to --laf. --branding was removed from the help, it's not intended for end users. I also did some change in the help text itself, removed any mention of "IDE" there, added blank line b/w text sections and hopefully also improved the English
Mini spec from end user point of views 1) all well-known old options continue to work but should not be documented anywhere 2) on windows only runide.exe prints the usage to the console, not runidew.exe, this is consistent with java.exe/javaw.exe behaviour 3) if an unknown option is specified, a warning is printed into the console, and ignored, the IDE continues 4) options which are supported and intended to be used by end users are described by running the console launcher in the launcher with the --help switch. They are $ runide.sh --help Usage: runide.sh {options} arguments General options: --help show this help --jdkhome <path> path to Java(TM) 2 SDK, Standard Edition -J<jvm_option> pass <jvm_option> to JVM --cp:p <classpath> prepend <classpath> to classpath --cp:a <classpath> append <classpath> to classpath Core options: --laf <LaF classname> use given LookAndFeel class instead of the default --fontsize <size> set the base font size of the user interface, in points --locale <language[:country[:variant]]> use specified locale instead of the default --userdir <path> explicitely set user settings directory OpenFile module options: --open FILE open FILE. --open FILE:LINE open FILE at line LINE (starting from 1).
I18N/L10N note: the usage text is not localizable because half of it is printed by the launcher and we don't know how to internationalize shell script. Consider this is "by design" ;-( At least not a regression
committed the modified patch Windows launchers runide.exe and runidew.exe were fixed too
set target milestone to 3.6