Hi, IIRC I was told that what went into the Commons CLI was infact the commandline parser from Axis1!
Ajith On 9/15/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
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]
-- Ajith Ranabahu --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
