Ajith Ranabahu wrote:
Hi,
Lemme add my thoughts here.
First:
It is the usual convention that we use -- for long options. Long options
are any option that has more than one char. e.g. ss, sd
Either we have to come up with single char alternatives to them or have
to change the syntax to --
The problem with always having 1 character short options is that they
become less descriptive and gets confusing soon. And it is not nice to
have them use the long version always. Perhaps we can go into an Axis
1.1 like options where uppercase and lowercase letters are used in
places of conflict [1]. However we have come long way with these
options and it will not be nice to break the whole thing by reverting
all the option names. We would have to do deprecate - drop cycle.
Second:
If I use -lc it breaks, I have to use -l c
Yes - the for the current commandline options parsers the parameters
need to be seperated by a space. I'm not sure whether this greatly
affects usability (linux/unix lovers may not agree with me on that ;))
but we can definitely improve the parser to take that into account.
Well I was looking into the parser to improve it. This is where I
concluded that we need GetOpt like thing.
The point is when we have both -lc -ss as options, then it converts to
option l with arg c
option s with arg s
However we treat ss as one option, so while the parser logic could be
improved, it becomes overly complex.
As a solution to the concern that you have raised against the use of --,
we can hide the user from -- by treating
-ss as -s a; -sd as -s d; -sn as -s n and -ssi as -s si internally.
This again is complex logic, but I hope we may live with it.
Third:
We have getopt like implementation in Java. e.g. Xalan has
src/org/apache/xalan/xsltc/cmdline/getopt/GetOpt.java
We can use this and improve command line option parsing
There is this thing called commons commandline [2]. I have tried
several times to put that in but did not get time to do it. I'm not
sure how suitable the xerces thing would be (It may give us a direct
dependancy on xerces that we do not want) so I guess something like
the commons CLI would be the right thing.
Well I was thinking copying GetOpt.java from Xalan and improving to that
to match our needs (Should be OK as it is the same licence). I had a
look at CLI, but for me, it is too complex for our requirement.
I could look into GetOpt.java and improve it, however to do that, I need
to know the number of args expected by each command line option
mentioned in
CommandLineOptionConstants.WSDL2JavaConstants. Could you please let me
know those numbers?
Thanks,
Samisa...
Fourth:
Without something like getopt, we cannot drop the need for -uri in the
current syntax (I think there a Jira requesting to drop -uri option)
Well you can :) But it'll rather be better to go ahead with commons
CLI and use the capabilities of that to deal with it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
