#124 Command Line Interface
A simple command line interface is required for
JCommander for specifying certain actions on startup.
For now however the mainly required arguments are
required for the implementation of the feature requests
1366374 "Enforce singleton JCommander instance"
http://sourceforge.net/tracker/index.php?func=detail&aid=1366374&group_id=35271&atid=413698
and 1470472 "JCommander as a download manager"
http://sourceforge.net/tracker/index.php?func=detail&aid=1470472&group_id=35271&atid=413698
I propose the following initial version of the command
line interface:
-newTab [leftPanelRoot [rightPanelRoot]] - opens a new
tab in the last used JCommander window with the panels
pointing to the specified root directories (if any)
-newWindow [leftPanelRoot [rightPanelRoot]] - opens a
new JCommander window and opens a new tab in it with
the panels pointing to the specified root directories
(if any)
-copyFiles file(,file)* - opens the copy confirmation
dialog in the active tab of the last used JCommander window
-copyDefaultTarget file - specifies the default target
for the copy operation
The implementation should probably use Commons CLI
http://jakarta.apache.org/commons/cli/ library.
Logged In: YES
user_id=998154
With regard to the Singleton Instance it is needed to have
two more parameters - preferred port range and a way to
disable the singleton instance feature. I would propose the
following syntax:
-singletonPort <start>-<end>
-noSingleton
Logged In: YES
user_id=940779
These sound reasonable to me.
Logged In: YES
user_id=1473670
A command line option for comparing files and directories
would probably usefull, too. Something like
-compareFiles file, file
-compareFiles file, file, file (for left, right, ancestor)
Logged In: YES
user_id=998154
I think that after my tests I have collected the information
required regarding the CLI usage in JCMD. I will prepare a
sample design for the level after parsing parameters since I
think that after passing though the command line parser it
will be better to have something of higher level than just a
bunch of parameters and values.
Do you think it will be better design to have a single
object that will contain all possible parameters with their
default values, or have some set of objects implementing
some interface and proper instances will be added depending
on an option presence. My personal opinion is that a single
'run' configuration is better solution because it seems muck
clearer.
Logged In: YES
user_id=940779
Since there won't be a too big number of command line
arguments, I am of the same oppinion of using a single object.
Logged In: YES
user_id=998154
I would like to continue working on this feature, but I need
some clarity on the newWindow command which seems to be
almost obsolete.
As I see it, newWindow must mean that there should be no
check for already running instance. A new JCMD instance must
be allowed to run. Here comes the first question - should
this instance try to register istelf as a single instance if
it discovers that it is the first started instance?
Also, a problem will arise when closing the two
simultaneously running instance because they will save
different locations for the first tab.
For me there is another solution that seems clearer: add two
parameters (e.g. -left and -right) that will expect folder
locations. If the instance starting is a first inscance -
setup the default tab with the specifierd locations.
Otherwise act as if -newTab was specified. And have no
-newWindow command. We will keep the -newTab in order to be
able to run a first instance of JCMD and tell it to open the
specified locations in a new tab and not in the default one.
I await your comments.
Logged In: YES
user_id=940779
From how I see it, the newWindow parameter should open up a
new workbench window and not start another instance. It
should actually open the JCommander perspective in a
separate window. The problem right now is that window
management in JC isn't really working yet. For instance you
can set in the preferences for new perspectives to open up
in new workbench windows, but the exit confirmation, if
enabled, will show up when closing each of these windows.
And, additionally, the state of all the open windows is not
saved.
In fact the newWindow parameter should be the default
parameter when JC is launched without any parameters.
Right now I'm on vacation and I'm not really able to work on
JC, so I cannot really help out with coding at this time
(and up to the end of the next week). If the above
explanation is clear to you and you would like to deal with
the implementation of this parameter's behavior, then please
do so. I will be available though for additional discussions
in this period.