CLI Parser is not very extension friendly

• Key: CLI-142
• Type: Improvement
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Unassigned
• Reporter: Henning Schmiedehausen
• Component/s: CLI-1.x
• Affects Version/s: 1.1
• Fix Version/s: 1.2

Description

The Parser class is not really extension friendly.

• cmd is private, should either be protected or have a getter/setter pair
• options and requiredOptions should have getter/setters (requiredOptions depends on options)
• processProperties is private, should be protected
• processOptions is private, should be protected

Comments

[Henning Schmiedehausen]

BTW: If you are looking for an use case, here it is:

I have a dynamic Task executor, that has a fixed set of options (list, info, run) and loads an additional set of options depending on the service name given as an argument to list/info/run. So as soon as one of these three has been encountered, I use processOptions to dynamically query the task in question about its options and add it to the running parser.

(And I do it over JMX, hence I need serializable classes. )

[Henri Yandell]

It all seemed rather unextendable to me. Have you looked at CLI2, and do you have any thoughts on whether that looks more extendable?

I backed away from making things more extensible rather quickly in CLI1 when I hit bits like that, seemed like a lot of backwards compat issues just waiting to happen.

[Henri Yandell]

Consider for 1.2; or mark as WONTFIX if 2.0 looks to be better designed for this.

[Henning Schmiedehausen]

Legacy application, got it to work with that hack. I might consider moving to CLI 2 in the near future, for now, that patch did the trick for me.

[Henri Yandell]

Now 1.1 is out, applying this patch as it looks good.