There are three incompatibilities introduced by this commit into the client shell:

1) now requires commons-cli
2) get no longer returns stat information by default, however there is a "-s" option that will result in the stat being included
3) a deprecated message is reported in some cases, when the old command format is used. As a result the output of the command may be different compared to client output prior to this change.

There are three incompatibilities introduced by this commit into the client shell:
1) now requires commons-cli
2) get no longer returns stat information by default, however there is a "-s" option that will result in the stat being included
3) a deprecated message is reported in some cases, when the old command format is used. As a result the output of the command may be different compared to client output prior to this change.

Description

The command line parsing in zookeepermain is very basic.We should use some kind of cli parsing (commons-cli?) or something else that is standard and improve our command line parsing. This will remove the scattered code that we have in zookeepermain and we will have much better command line parsing.

There are three incompatibilities introduced by this commit into the client shell:

1) now requires commons-cli
2) get no longer returns stat information by default, however there is a "-s" option that will result in the stat being included
3) a deprecated message is reported in some cases, when the old command format is used. As a result the output of the command may be different compared to client output prior to this change.

The options for some commands were changed to match the option usage in commons-cli.
But to maintain the compatibility the old argument style for these commands was preserved. This could be removed in a future revision.

does this mean the new client is 100% backward compatible with the old client or not? If not we should mark this as an incompatible change (there's a flag for this) and document in the "release notes".

Patrick Hunt
added a comment - 17/Mar/12 00:58 Nice job! I'm reviewing now. Question though:
The options for some commands were changed to match the option usage in commons-cli.
But to maintain the compatibility the old argument style for these commands was preserved. This could be removed in a future revision.
does this mean the new client is 100% backward compatible with the old client or not? If not we should mark this as an incompatible change (there's a flag for this) and document in the "release notes".

A attached a patch with my work to refactor the CLI to use commons-cli.
Every command has now its own java-class, with CliCommand.java as base.class.

The options for some commands were changed to match the option usage in commons-cli.
But to maintain the compatibility the old argument style for these commands was preserved. This could be removed in a future revision.

The commands with changed options are:
get [-s][-w] path, old version was: get path [watch]
ls [-w] path, old version was ls path [watch]
ls2 [-w] path, old version was ls2 path [watch]
stat [-w] path, old version was stat path [watch]

Hartmut Lang
added a comment - 04/Mar/12 14:43 A attached a patch with my work to refactor the CLI to use commons-cli.
Every command has now its own java-class, with CliCommand.java as base.class.
The options for some commands were changed to match the option usage in commons-cli.
But to maintain the compatibility the old argument style for these commands was preserved. This could be removed in a future revision.
The commands with changed options are:
get [-s] [-w] path, old version was: get path [watch]
ls [-w] path, old version was ls path [watch]
ls2 [-w] path, old version was ls2 path [watch]
stat [-w] path, old version was stat path [watch]
Please have a look.