commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [cli] [patch] build bug
Date Thu, 20 Apr 2006 00:30:46 GMT
On 19/04/06, Henri Yandell <flamefew@gmail.com> wrote:
> On 4/19/06, Andrew Shirley <aks@decisionsoft.co.uk> wrote:
> > On Wed, Apr 19, 2006 at 09:36:49AM +1000, James.Ring@ga.gov.au 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message