Sorry to jump in so late here, but yes the code in Axis 1.x is in fact from commons. We were trying to keep jar file dependencies down to the bare minimum (Axis2 folks take note!), so we just copied the (one) source file in to our tree.
It would have been nice if the Axis2 developers had *used* the Axis 1.x switches and code to maintain wsdl2java compatibility, but I suppose whining about that is non-productive. :-( Unless the current switch parsing code is *really* bad (which I don't think it is) I would recommend just keeping it and not bothering to use the commons CLI code. I didn't think it was a great win for Axis 1.0. Just make clear in the user docs how it works. That and make sure that "-v" means verbose. :-) -- Tom Jordahl Adobe ColdFusion Team -----Original Message----- From: Ajith Ranabahu [mailto:[EMAIL PROTECTED] Sent: Friday, September 15, 2006 4:27 PM To: axis-dev@ws.apache.org; [EMAIL PROTECTED] Subject: Re: [Axis2] Codegen tool command line options 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
