On 19/04/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > On 4/19/06, Andrew Shirley <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 19, 2006 at 09:36:49AM +1000, [EMAIL PROTECTED] wrote: > > > Hi Henri, > > > > > > > What do you think? Is the cli2 package clearly superior to the cli[1] > > > > package? > > > > I think so. There doesn't seem to be any advantage to cli[1], cli2 is better > > designed and the avalon code appears to be simpler (I havn't actually > > used it). > > > > > > Should we dump the old one, test the issues reported against > > > > cli[1] that are now fixed in cli2 and move on; or should we dump the > > > > cli2 package and stick with the cli one? > > > > > > This is a tricky question, because people already use the current CLI > > > API. The CLI2 API is quite different, so people would have to migrate > > > their code to the new API, and I can imagine that a lot of people would > > > be loathe to do that. > > > > > > I think we should investigate the possibility of having CLI as a façade > > > to the (superior) CLI2 package. This could ease migration problems, as > > > well as solve the outstanding parsing issues. > > > > > > My vote is to move towards CLI2, but do it in such a way that we can > > > avoid disturbing users of CLI as much as possible. > > > > > > > My gut instinct is that it shouldn't be too difficult to effectively > > reimplement cli1 using cli2 as I havn't encountered anything that can be > > done in cli but not cli2. > > > > Generally, I think we should be moving away from cli1 whether that is by > > simply deprecating it or reimplementing it as a facade > > Seems to be pretty overwhelmingly in favour of cli2 - good to hear > that people are using it and are happy. > > Another option is to split the two packages up and keep cli1 on a > branch. Then we can do a cli1.1 release, but for a lot of the bugs > we'll just be saying "Sorry, move to cli2". > > Another question - why keep the Avalon logger? (Presuming we were to > release cli 2.0 and an easier cli 1.1). What's its raison d'etre?
[It's not a logger ...] Because projects may still be using it. And it works, and has a fairly extensive test package, and (hopefully) adequate documentation. It just needs to be packaged and released. When I looked at converting JMeter to CLI, it seemed to be a lot of effort, as the way the options are defined is very different. CLI2 was not ready at the time, so I did not investigate that. Converting from the original Excalibur Avalon version to the updated Avalon version merely requires changing at most 4 import statements. JMeter has its own copy of the source, as the commons-cli version has not been released. So it does not matter to us if it is dropped. But it seems a shame to force other projects to change to a different package merely to get an updated CLI parser. But maybe there are no other projects using it. > Hen > > --------------------------------------------------------------------- > 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]
