commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russel Winder <>
Subject Re: Release of commons-cli?
Date Wed, 28 May 2008 16:01:42 GMT

On Wed, 2008-05-28 at 02:01 -0700, Henri Yandell wrote:
> On Wed, May 28, 2008 at 12:30 AM, Russel Winder
> > What is needed to move 2.0 to release?  Given that the policy decision
> > was made to shift any new activity to 2.0, saying 2.0 is defunct is
> > equivalent to saying Commons CLI is defunct.
> No life happened on 2.0. I've been applying patches that show up for
> the 1.x branch, just because. :)

I think this is a chicken and egg problem.  No-one is doing anything
proactive at the minute because the Commons CLI development team is the
empty set.  No-one is providing bug reports for 2.x because 2.0 is not
publicly available in any form.

It is good that you are doing the 1.x patching, but I think a bit of
decisive management is in order.  For me the options would appear to be:

1.  Declare Commons CLI end of life and let it gently disappear.  People
will then move to those projects that have activity.

2.  Declare Commons CLI 2.x the active branch -- even to renaming the
package to cli instead of cli2, put out a snapshot so people can use it
and provide bug reports, nominate a couple of the volunteers to the
development team -- basically use the little interest there is in CLI to
boostrap a more lively community.  Oh and schedule a putative release
date for 2.0 and publicize it so that an RC programme can be started.

3.  Declare Commons CLI 2.x a dead branch, revert to 1.x as the only
line of development, make a Maven 2 build for it.  Then do exactly the
same as above, get the few volunteers into a formal development team,
announce a release date and begin an RC programme.

Sorry if I am being a bit over-pushy here but the Commons CLI 1.0 issue
is really annoying a few of the Groovy developers.

> > Can I suggest that
> > 2.0-SNAPSHOT could happily be released into the snapshot repository to
> > give things a kick start?
> I'll get that done. Been a while since I remember doing a snapshot
> release so have asked how we do that nowadays on dev@.

I have no idea about the Apache system but at Codehaus deployments go to
the snapshot repository automatically if the version number has
-SNAPSHOT at the end.   For the Gant project (which let's be honest is
the only one I actually know about), it all Just Works (tm).

> > Alternatively, the decision to move to 2.0 could be rescinded and 1.x
> > treated as the mainline.  However, I had understood that the 1.x
> > architecture was fundamentally inferior to the 2.x architecture.
> That's what they say. As a user I didn't feel too excited about the 2.x API.

If there is a compelling reason for the 1.x -> 2.x API change, is there
a document somewhere that explains it? Or is the information trapped in
the heads of the development team who fled the project? I can do a
little to do some analysis and recommendation but not masses.

It would actually be interesting to know why the 2.x developers
effectively abandoned the project.

> > I think there is more to CLI-137 than is currently listed.  From memory
> > (I will try and dig up the test cases) processing multiple options (e.g.
> > -D) fails to work in CLI 1.1.  So unless someone has fixed that I would
> > deem 1.2 as unusable just as 1.1 is :-(
> Test cases much appreciated :)

I'll have a look tomorrow to see if I can turn all my rantings and bad
examples into some proper test cases.

> > This is actually an opportune moment for something to happen with
> > COmmons CLI as there are gumblings again about still having to use CLI
> > 1.0 for Groovy.  Current favourite is to switch to a new CLI package
> > that has some energy, i.e. someone is actually working on it :-)
> > Currently mooted to move to are JSAP or JOpt.
> >
> > If however there was a Commons CLI 1.2 and it fixed the bugs we found in
> > the Groovy project that mean that 1.1 is basically broken and unusable,
> > then that would be great.  Shifting a version of a package is easier
> > than shifting packages.
> I don't see why not for a 1.2 release that fixed the bugs. All I got
> from the previous problems was that unfortunately .hasArg had to be
> changed to .hasArgs, so more test cases for the problems would be
> great. I was focused on JIRA issues rather than the mailing list
> archives though.

There is the problem behind that that there seemed to be errors in the
implementation which meant that multiple option occurrences actually
caused total chaos.  Also the PosixParser and GnuParser both behave
differently to what the documentation says they should do.

Again I have rants but I need to turn them into test cases.

I have to admit I got bored with trying to sort it all out when I
realized I was totally on my own trying to sort it out.  All the Groovy
guys just want to abandon Commons CLI in favour of a package that has
some active development or at least maintenance.  An active programme to
release Commons CLI 1.2 and 1.3 would be a boon and save us a lot of
hassle and work.  Switching to 2.0 is predicated on 2.1 being scheduled
and 2.0-SNAPSHOT hitting the Maven repository.
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077

View raw message