You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2006/02/13 06:24:40 UTC
[cli] Moving forward
[included James in case he's not on commons-dev]
So the big question is....
What do we do with CLI? We have two implementations, cli1 and cli2 in
the same build. I'm thinking we should:
a) branch off a cli 1.1 based on HEAD, and delete the cli2 code from it.
b) delete the cli 1 code from cli2 and stride forward with cli2.
We do need to agree that cli2 is the way forward, comparing the APIs
to see if it feels better is one of my todo's. What do the rest of you
think? Martin/James/anyone else?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [cli] Moving forward
Posted by Torsten Curdt <tc...@apache.org>.
> We do need to agree that cli2 is the way forward, comparing the APIs
> to see if it feels better is one of my todo's. What do the rest of you
> think? Martin/James/anyone else?
I've already been pushing for a release of cli2 ages ago.
cli1 has quite a few problems when it comes down to the
little details.
+1
cheers
--
Torsten
Re: [cli] Moving forward
Posted by James Ring <sj...@jdns.org>.
Hi Stephen and all,
(Sorry for the late reply)
On Tuesday 14 February 2006 08:36, Stephen Colebourne wrote:
> Henri Yandell wrote:
> > On the compatibility interface; I'd rather just drop it and spend that
> > effort on migration documentation. Does raise the question of whether
> > the cli2 package name ever becomes cli. Having it as cli2 does avoid
> > any surprises; things flat out won't work.
>
> Or [commons-commandline], a completely 'new' commons project.
I think that we have a better chance of getting newer versions of CLI out to
developers if we keep it within the current project.
Take the Debian libcommons-cli-java package: Debian will much more readily
accept new upstream releases of the same package than they will the same
project under a new name (I think).
> Stephen
Regards,
James
--
James Ring
Re: [cli] Moving forward
Posted by Michael Heuer <he...@acm.org>.
Stephen Colebourne wrote:
> Henri Yandell wrote:
> > On the compatibility interface; I'd rather just drop it and spend that
> > effort on migration documentation. Does raise the question of whether
> > the cli2 package name ever becomes cli. Having it as cli2 does avoid
> > any surprises; things flat out won't work.
>
> Or [commons-commandline], a completely 'new' commons project.
+1
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [cli] Moving forward
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Henri Yandell wrote:
> On the compatibility interface; I'd rather just drop it and spend that
> effort on migration documentation. Does raise the question of whether
> the cli2 package name ever becomes cli. Having it as cli2 does avoid
> any surprises; things flat out won't work.
Or [commons-commandline], a completely 'new' commons project.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [cli] Moving forward
Posted by sebb <se...@gmail.com>.
The repository also contains a version of Avalon Excalibur CLI (as
used in JMeter).
There were some bugs in the Avalon code, and there did not seem to be
any likelihood of any fixes, so we imported the source into JMeter,
and fixed the bugs (and test cases).
Just in case someone else might find it useful, the code was copied to
the CLI repository - see:
http://issues.apache.org/bugzilla/show_bug.cgi?id=34672 for the
contribution.
It would be nice if there could be a release of this - we could import
the jar and drop the source from JMeter.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [cli] Moving forward
Posted by Henri Yandell <fl...@gmail.com>.
On 2/13/06, Torsten Curdt <tc...@apache.org> wrote:
> >
> > This is a tough question. There has already been a release of CLI
> > which did
> > not include the CLI2 API, and there are doubtless users of CLI out
> > there who
> > will not be interested in migrating to the CLI2.
>
> for sure
>
> >
> > However, CLI2 has the idea of argument validators, and I think
> > that's quite a
> > handy feature of the API.
>
> yepp +1
>
> >
> >> We do need to agree that cli2 is the way forward, comparing the APIs
> >> to see if it feels better is one of my todo's. What do the rest of
> >> you
> >> think? Martin/James/anyone else?
> >
> > I think you're right, we do need to compare the two APIs to make a
> > rational
> > decision. Maybe there's some scope for maintaining the current CLI
> > API while
> > merging in some of the nice validation stuff from CLI2? Whatever
> > the choice,
> > we should at least maintain a compatibility interface with this API
> > so that
> > users only have to change their code if they want to use the nice
> > parts of
> > CLI2.
>
> TBH cli1 has lived for sooo long without further releases
> why not only put it into bug fix mode and other than that
> move forward. The old jars won't go away.
+1. If we branch off a 1.x branch; it'll be releasable if people
clamour. Plus we can keep applying patches when applied; however there
will be a whole bunch of bugs that will just get marked as WONTFIX
beause the solution is to rewrite cli1.
On the compatibility interface; I'd rather just drop it and spend that
effort on migration documentation. Does raise the question of whether
the cli2 package name ever becomes cli. Having it as cli2 does avoid
any surprises; things flat out won't work.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [cli] Moving forward
Posted by Torsten Curdt <tc...@apache.org>.
>
> This is a tough question. There has already been a release of CLI
> which did
> not include the CLI2 API, and there are doubtless users of CLI out
> there who
> will not be interested in migrating to the CLI2.
for sure
>
> However, CLI2 has the idea of argument validators, and I think
> that's quite a
> handy feature of the API.
yepp +1
>
>> We do need to agree that cli2 is the way forward, comparing the APIs
>> to see if it feels better is one of my todo's. What do the rest of
>> you
>> think? Martin/James/anyone else?
>
> I think you're right, we do need to compare the two APIs to make a
> rational
> decision. Maybe there's some scope for maintaining the current CLI
> API while
> merging in some of the nice validation stuff from CLI2? Whatever
> the choice,
> we should at least maintain a compatibility interface with this API
> so that
> users only have to change their code if they want to use the nice
> parts of
> CLI2.
TBH cli1 has lived for sooo long without further releases
why not only put it into bug fix mode and other than that
move forward. The old jars won't go away.
My 2 cents
cheers
--
Torsten
Re: [cli] Moving forward
Posted by James Ring <sj...@jdns.org>.
Hi Henri and all,
On Monday 13 February 2006 16:24, Henri Yandell wrote:
> [included James in case he's not on commons-dev]
>
> So the big question is....
>
> What do we do with CLI? We have two implementations, cli1 and cli2 in
> the same build. I'm thinking we should:
>
> a) branch off a cli 1.1 based on HEAD, and delete the cli2 code from it.
> b) delete the cli 1 code from cli2 and stride forward with cli2.
This is a tough question. There has already been a release of CLI which did
not include the CLI2 API, and there are doubtless users of CLI out there who
will not be interested in migrating to the CLI2.
However, CLI2 has the idea of argument validators, and I think that's quite a
handy feature of the API.
> We do need to agree that cli2 is the way forward, comparing the APIs
> to see if it feels better is one of my todo's. What do the rest of you
> think? Martin/James/anyone else?
I think you're right, we do need to compare the two APIs to make a rational
decision. Maybe there's some scope for maintaining the current CLI API while
merging in some of the nice validation stuff from CLI2? Whatever the choice,
we should at least maintain a compatibility interface with this API so that
users only have to change their code if they want to use the nice parts of
CLI2.
> Hen
Thanks for copying me in on the discussion, I am on commons-dev also.
Looking forward to a fruitful discussion!
Regards,
James
--
James Ring