On 6/13/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
4 items to fix:
1) Make the fields in HelpFormatter public. DONE.
2) Make the Option class cloneable again. See:
https://issues.apache.org/jira/browse/CLI-21
Brian had a nice patch adding clone(), but he did it the right way
(protected :) ), and that still fails backwards compat. So I've
modified his change to make the clone method public, and I catch the
CloneNotSupportedException and throw a RuntimeException.
Clirr didn't seem to care that a checked exception was being added to
a method. I'm not sure what would happen in that case without testing
- anyone know? Is it fine to add a checked exception without having to
consider it non-backwards compat?
3) Deal with the public boolean addValue->package private void addValue.
Current thinking is to move the new one to a new name and have the old
method throw an UnsupportedOperationException.
Done. New method is addValueForProcessing. The old method throws an
UnsupportedOperationException.
I see little point for this change and am only making it so clirr will
look pretty - if that's what is needed for a release. Is there any
difference between a NoSuchMethodError and an
UnsupportedOperationException at runtime? The short explanatory text
in the UOE is all I can think of.
4) Deal with the new methods on the CommandLineParser interface. I'm
tempted to just delete them from the interface and leave them on the
abstract Parser class. Thoughts?
Removed from the interface. Still in the abstract class.
Clirr is now a happy little camper, as is jardiff which only points
out that various bits have been deprecated.
Before I call a vote, it'd be good to know if these ugly soul
destroying hacks pass muster or not with the backwards compat view.
Any opinions?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
