Return-Path: Delivered-To: apmail-commons-user-archive@www.apache.org Received: (qmail 45142 invoked from network); 14 Aug 2007 14:16:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Aug 2007 14:16:44 -0000 Received: (qmail 39655 invoked by uid 500); 14 Aug 2007 14:16:38 -0000 Delivered-To: apmail-commons-user-archive@commons.apache.org Received: (qmail 39568 invoked by uid 500); 14 Aug 2007 14:16:37 -0000 Mailing-List: contact user-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Jakarta Commons Users List" Delivered-To: mailing list user@commons.apache.org Received: (qmail 39559 invoked by uid 99); 14 Aug 2007 14:16:37 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Aug 2007 07:16:37 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of flamefew@gmail.com designates 64.233.162.236 as permitted sender) Received: from [64.233.162.236] (HELO nz-out-0506.google.com) (64.233.162.236) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Aug 2007 14:16:34 +0000 Received: by nz-out-0506.google.com with SMTP id m22so659145nzf for ; Tue, 14 Aug 2007 07:16:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rAtvwG8op8xig4O5JeKxWn5l3LXjxFCKhIbI8FvR6nuaxJ0OcfekQiNEvAFj9aUGNaH+MhqtOlHmL8YBye6stgDbmw2ojB9xmQULCfRXOsD48E/Su1R3w8mtaJLK6nW+spoNY8JhZuKRXEGvJziDLieWA92+30IrqnD9AiwtK2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WHaLcTYs47GhgvIOQ6POsxx8NSOaZhcaaHgiigvPAUM35V7HGr1/9hj8/0+E02aRJhkywfmtdLB96uCQ5KUpntDLswWrmhKjMct1vKKxT7GImn2GfeXRC7nzt8fsKR/h+zp433xLpdFxDxeHywu7R1q/bCEIsFFAjJM2FaznWlc= Received: by 10.115.22.1 with SMTP id z1mr830420wai.1187100969244; Tue, 14 Aug 2007 07:16:09 -0700 (PDT) Received: by 10.115.92.8 with HTTP; Tue, 14 Aug 2007 07:16:09 -0700 (PDT) Message-ID: <31cc37360708140716j4447d20co15182b5ed1027b8e@mail.gmail.com> Date: Tue, 14 Aug 2007 15:16:09 +0100 From: "Henri Yandell" To: "Jakarta Commons Users List" Subject: Re: Commons CLI issue In-Reply-To: <1186993859.15457.245.camel@balin.russel.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1185899307.8698.100.camel@balin.russel.org.uk> <164D0ADE-C8FD-4EAA-BA63-33956B86B825@apache.org> <1186983472.15457.200.camel@balin.russel.org.uk> <3B490229-3817-42C0-869D-C584507EE5DF@apache.org> <1186993859.15457.245.camel@balin.russel.org.uk> X-Virus-Checked: Checked by ClamAV on apache.org On 8/13/07, Russel Winder wrote: > On Mon, 2007-08-13 at 09:19 +0200, Torsten Curdt wrote: > > > Please - please don't fork. I am sure we will get your patches in. We > > just need someone to push for it. +1 > I believe Henri is more interested in the 1.x branch, which is why the 2.x > branch has not been progressed, but I am speaking from a position of > fairly deep ignorance. I'm equally interested :) Getting a 1.1 release out made the most sense with the time available - plus Brian was energetic in that direction. When I tried to use CLI2 I didn't like the API a lot, but I was just dabbling and not trying to get the extra features that it supports (I assume). I seem to recall I found it much more verbose than CLI1 which surprised me. Now my energy for CLI is squarely available for CLI2 if there's interest out there. I can see a CLI 1.2 someday if need be, but hopefully it'll just be a few bugfixes and we can have people use the snapshots for that branch. > Clearly 1.1 has many bug fixes over 1.0 and so would be preferred. > However the combination of the change of semantics with hasArgs and > incorrect processing of parameters associated with the new semantics > (cf. CLI-137) means that there appears to be a blocking problem in > processing options such as -D where there can be any number of them on a > command line -- there appears to be no problem with options that do not > have Option.UNLIMITED_VALUES set. Any idea for how 2.0 works with this? Hen --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@commons.apache.org For additional commands, e-mail: user-help@commons.apache.org