On Wed, May 28, 2008 at 12:30 AM, Russel Winder <[EMAIL PROTECTED]> wrote: > On Tue, 2008-05-27 at 23:54 -0700, Henri Yandell wrote: >> CLI 2.0 I don't see any time soon (ever) unless someone gets a big urge. > > 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. :) > 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 [EMAIL PROTECTED] > 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. >> CLI 1.2 I have on my list as a 'sometime soon' along with the next >> Collections 3.x and Codec 1.x - looking at it I think it could go very >> easily, none of the 4 tickets are blocked (ignoring that CLI-137 is a >> painful one to close as WONTFIX). > > 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 :) > 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. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
