You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Samisa Abeysinghe <sa...@gmail.com> on 2006/09/14 21:05:06 UTC
[Axis2] Codegen tool command line options
I have few problems with codegen command line options.
I would like it to have some getopt (see man page) like syntax. However
there are some problems 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 --
Second:
If I use -lc it breaks, I have to use -l c
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
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)
Thoughts please...
Samisa...
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
RE: [Axis2] Codegen tool command line options
Posted by Tom Jordahl <tj...@adobe.com>.
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:ajith.ranabahu@gmail.com]
Sent: Friday, September 15, 2006 4:27 PM
To: axis-dev@ws.apache.org; dims@apache.org
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 <da...@gmail.com> wrote:
> Samisa,
>
> Did you look into the parser inside Axis 1.X?
>
> On 9/14/06, Samisa Abeysinghe <sa...@gmail.com> 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: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
> --
> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service
Developers)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Ajith Ranabahu
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Codegen tool command line options
Posted by Ajith Ranabahu <aj...@gmail.com>.
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 <da...@gmail.com> wrote:
> Samisa,
>
> Did you look into the parser inside Axis 1.X?
>
> On 9/14/06, Samisa Abeysinghe <sa...@gmail.com> 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: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
> --
> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Ajith Ranabahu
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Codegen tool command line options
Posted by Davanum Srinivas <da...@gmail.com>.
Samisa,
Did you look into the parser inside Axis 1.X?
On 9/14/06, Samisa Abeysinghe <sa...@gmail.com> 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Codegen tool command line options
Posted by Samisa Abeysinghe <sa...@gmail.com>.
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Codegen tool command line options
Posted by Ajith Ranabahu <aj...@gmail.com>.
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.
> 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.
> 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.
--
Ajith Ranabahu
[1]http://ws.apache.org/axis/java/reference.html#WSDL2JavaReference
[2] http://jakarta.apache.org/commons/cli/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Codegen tool command line options
Posted by robert lazarski <ro...@gmail.com>.
GetOpt is the standard way on linux / unix to do command line parsing
and I like it alot. I wasn't aware that Xalan has one but there are a
few (non apache) java versions I've used. +1 .
Robert
On 9/14/06, Samisa Abeysinghe <sa...@gmail.com> wrote:
> I have few problems with codegen command line options.
>
> I would like it to have some getopt (see man page) like syntax. However
> there are some problems 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 --
>
> Second:
> If I use -lc it breaks, I have to use -l c
>
> 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
>
> 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)
>
> Thoughts please...
> Samisa...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org