commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: [cli] [patch] build bug
Date Thu, 20 Apr 2006 04:22:20 GMT
On 4/19/06, sebb <sebbaz@gmail.com> wrote:
> On 19/04/06, Henri Yandell <flamefew@gmail.com> wrote:
> > 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 ...]

Sure, sure.  (I was on crack)

> 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.

I think our priorities should be:

* Breathe activity back into cli - which means getting passed the
impasse it has arrived at by dumping cli-1.0 support from the 2.0 jar.
* Support old cli 1.0 users with a minor bugfix version, 1.0.1.
* Consider 1.0 and Avalon facades to 2.0.

The Avalon one is worth finding out more about - especially if people
think it's an improvement over the current cli2 code. It'd also be
interesting to know why it's not an excalibur component - I thought
that project was still slightly active.

So my suggested plan is:

1) Create 1.x branch. Dump 2.x, avalon code from it.
2) Create Avalon branch. Dump 2.x, 1.x code from it.
3) Dump 1.x, avalon code from trunk.
4) Split bugs into 1.x or 2.x bugs.
5) Release 1.0.1 and 2.0-rc1.
6) Reassess situation. Including facade creation to support other
projects, and release of avalon branch.

How does that sound?

I'll plod along if that sounds okay and 1-3 shouldn't take that long.
Thoughts, patches and contributions on 4) would be very welcome.

Hen

---------------------------------------------------------------------
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