Samisa,
Did you look into the parser inside Axis 1.X?
On 9/14/06, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote:
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]
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
