Thanks for this Simon,
Things have been a bit hectic this week so I haven't been able to keep
up with things. I should be able to be more help next week if there are
still issues.
Cheers,
Rob
Simon Kitching wrote:
Hi,
As there was general agreement on getting a 1.0.1 out I have gone
Torsten Curdt wrote:
Replacing the bad 1.0 on ibiblio with the correct one will make things
even more confusing I think. People who have already downloaded the 1.0
will not get the update (including maven users where the bad jar is
cached in ~/.maven/...).
But then at least what we have
sebb wrote:
On 7/11/05, Nigel Rantor [EMAIL PROTECTED] wrote:
sebb wrote:
Sorry, that's not what I meant.
The Avalon CLI code is a *different* implementation of CLI, but which
happened to have the same problem.
To use Avalon instead of another CLI would require quite a few
application code
Torsten Curdt wrote:
Could we come up with a decision on that one?
I think it's important to fix this.
Replace or delete the bogus 1.0 jar?
Personally I think this should be done ASAP - at least its stops the
problem from be being spread further.
Same here ...what about a quick vote?
Hmmm, this is interesting as negatives will look a lot like real
options... will have a look over the weekend sometime and get back to you.
Rob
Nigel Rantor wrote:
Hi all,
I've had a bit of a root about and can't find anyone mention of this in
the docs or on the MARC archives.
I'm using
Simon Kitching wrote:
On Wed, 2005-07-06 at 23:41 +0100, Rob Oxspring wrote:
Hi,
I've spent this evening merging changes from the trunk to the 1.x
branch, including both changes that bring it in line with the current
build system and licence requirements AND bugfixes applied to the 1.0
Simon Kitching wrote:
On Wed, 2005-07-06 at 23:41 +0100, Rob Oxspring wrote:
Hi,
I just had a go at building from the 1.0 tag and realised that it still
relies on the old commons/build system and uses Apache License 1.1.
I've spent this evening merging changes from the trunk to the 1.x
Simon Kitching wrote:
Hi,
As noted here, there is a bad commons-cli-1.0.jar file in circulation.
It would appear that a trunk build somehow got uploaded to ibiblio as
commons-cli-1.0.jar, ie every Maven user whose project depends on
commons-cli 1.0 is actually compiling against a snapshot of
licence, but
I'm not sure if that is desirable.
Thoughts?
Rob
Rob Oxspring wrote:
Simon Kitching wrote:
Hi,
As noted here, there is a bad commons-cli-1.0.jar file in circulation.
It would appear that a trunk build somehow got uploaded to ibiblio as
commons-cli-1.0.jar, ie every Maven user
widespread for this step.
Feel free to add more javadoc however, perhaps indicating the preferred
way to create these classes.
Stephen
Rob Oxspring wrote:
Thanks James,
The latter scenario is exactly the one I keep finding myself in! I
guess it's the naming that throws me - the collect() methods
! I've learned
that the hard way a few times (bad memory).
-Original Message-
From: Rob Oxspring [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 07, 2005 11:42 AM
To: Jakarta Commons Developers List
Subject: [collections] TransformedCollection
Hi,
I've just been burnt (and not for the first
Hi,
I've just been burnt (and not for the first time) by the fact that the
TransformedCollection doesn't transform the objects that are already in
the wrapped collection. For example:
Collection dates = ... // a collection with Date objects in it
Transformer toString = ... // a transformer
Thanks for that, fixed now.
Rob
robert burrell donkin wrote:
i think that the NOTICE file may be missing
- robert
On Wed, 2005-04-06 at 20:09 +0100, Rob Oxspring wrote:
Hi all,
CLI2 has been pretty stable and it hasn't had any code changes since the
end of Feb. Its a ground up rewrite of 1.0
Torsten Curdt wrote:
Torsten Curdt wrote:
The proposed release is available at:
http://people.apache.org/~roxspring/cli/
...another thing:
command --option1 -c -P --option2
currently CLI1 and CLI2 is treating this
as if it were
command --option1 -c -P --option2
which is not what I want. For
Torsten Curdt wrote:
The proposed release is available at:
http://people.apache.org/~roxspring/cli/
Rob,
I've been playing with the CLI2 stuff now.
Great stuff! ...but something I found confusing
Let's say I create my option like this:
final Set set = new HashSet();
set.add(a1);
Hi all,
CLI2 has been pretty stable and it hasn't had any code changes since the
end of Feb. Its a ground up rewrite of 1.0 aiming to be more flexible
and maintainable. The only remaining bugs are 1.0 issues that don't
apply / are fixed in 2.0, I plan to mark them resolved once 2.0 is
Thanks for the kick into action!
CLI2 is pretty stable and simple needs to be released. Thanks to this
reminder I've just proposed a release so hopefully a release will be
issued sooon.
Cheers,
Rob
Torsten Curdt wrote:
Guys,
can someone give me a short status on CLI?
The parsing in 1.0 is
in a
release-notes. Especially if we're using the changes.xml bit.
Hen
On Apr 5, 2005 9:57 AM, matthew.hawthorne [EMAIL PROTECTED] wrote:
Rob Oxspring wrote:
I recently replaced the use of my own CountingInputStream with the
commons-io and got burnt because io's CountingInputStream doesn't count
skipped
Hi,
I recently replaced the use of my own CountingInputStream with the commons-io
and got burnt because io's CountingInputStream doesn't count skipped bytes. I
have a patch with fix and patch if people are interested... or I could just
commit it...
Thoughts?
Rob
Index:
path, and no base URI was
provided.
-Message d'origine-
De : Rob Oxspring [mailto:[EMAIL PROTECTED]
Envoy : mardi 8 fvrier 2005 17:37
: Jakarta Commons Developers List
Objet : Re: RE : [VFS] Problem with Zip files
I haven't used vfs (yet) but I'm pretty sure the the file url should have 3
I haven't used vfs (yet) but I'm pretty sure the the file url should have 3
slashes:
file:///c:/temp/toto.zip
because urls reserve the spot between slash 2 and 3 for a host/port.
Rob
Stéphane Rault wrote:
XmlBeans doesn't matter in any way in my problem. Sorry for the confusion !!
But my real
The svn:externals property was set to check out the whole components rather
than just the trunks of each component. I've tested my commit privs by fixing
this (The working copy from a full checkout as below is now only 23M)
Otherwise, the structure looks pretty good and the cli conversion
Thanks for the testcase - I'll give it a shot in a while.
It sounds like the missing properties are accidental and should be
exposed via the builders, I'll try and address the group id later but
let me know about any others (or send a patch!).
I'll split my XML related reply into a separate
Modelling a cli in xml has been talked about in the past and there are a
couple of things you might want to take into consideration if you are
going to implement such a feature. Firstly, there is the question of
whether to parse the xml at runtime or build time - runtime introduces
another
Hi,
Sorry for the lack of response to your patch, I've been really busy with the
day job lately and CLI2 has effectively stalled in the meantime. Hopefully
I'll find some time between xmas and new year to get things in motion again.
The main thing that needs doing is to go through bugzilla
I've finally had a quick look at this bug and am not entirely sure I
understand the scenario where things start to fail. I'm a little wary about
your patch since it admits to being a partial solution only. Is there any
chance of sending a TestCase or at least a code sample that demonstrates
Henri Yandell wrote:
Looking at the site rather than the source. Would be nice if javadoc was a
link rather than hidden down in the Project Reports.
Go for it. I don't have the maven-foo and really don't have the
patience to hack the maven config more than I have to.
CLI2Converter confuses me.
CLI2 has been far too long in the making and has been stable for a long
time so I'd like to propose a beta release to be followed up by some
documentation and a proper release.
The open bugs mainly refer to 1.0 bugs that I'm nervous of fixing
without breaking something else. Given that the
I'm pretty sure CLI2 is ready as far as features are concerned, and is
just in need of more testing and documentation. I'd be happy to roll a
beta if someone could give me a few pointers on what how to get the
binaries and website in place (my jakarta foo is rusty)
Thats assuming that I ever
I've created a bugzilla entry and converted your example into a unit
test patch there: http://issues.apache.org/bugzilla/show_bug.cgi?id=30246
It definitely looks like a bug to me, but the obvious quick fix ended up
causing test failures elsewhere. I may come back to this and
investigate but
I'm a bit short of (online) time at the moment, so it may be a day or
two before I can have a proper look at this and the bugzilla patches.
In the meantime, it might be worth checking up on the differences
between the PosixParser and GnuParser, one of them (posix I think) will
take the string
(haven't studied [id] too hard so forgive me if I'm jumping in with
potential nonsense)
Stephen Colebourne wrote:
So two solutions:
1) Create one package scoped utils class in [id] with just the relevant
methods on it.
2) Produce two multiple files - id-all, id-uuid and id-simple, the first two
I've freshly set up my environment to do some work on commons-cli
(RESEARCH_CLI_2_ROXSPRING branch if that matters) and am really
struggling to get the build working.
Using a clean checkout of jakarta-commons, running maven (rc1) from the
cli directory ends up failing to compile any of the
John Keyes wrote:
On 26 Mar 2004, at 17:28, Rob Oxspring wrote:
Moving to list for general info and to get any feedback from John.
Thanks for checking. Regarding v2 (all IMHO):
2.0 release plan?
Several times now we've said in a month or in a couple of months.
Personally I think I'm out
I've been looking at how to resolve the jdepend test failure without
taking the ignoring approach (up the threshold to 0.3). I went in
search of a way to package things better and after thinking it through I
came up with the following proposed renamings:
1) o.a.c.c.HelpFormatter -
John Keyes wrote:
I've been looking at how to resolve the jdepend test failure without
taking the ignoring approach (up the threshold to 0.3). I went in
search of a way to package things better and after thinking it through
I came up with the following proposed renamings:
1)
Rob Oxspring wrote:
Moving to the list for wider comment. (will reply separately)
Original Message
Subject: Re: [CLI] PatternOptionBuilder
Date: Fri, 26 Mar 2004 17:39:21 -0500 (EST)
From: Michael Heuer [EMAIL PROTECTED]
To: Rob Oxspring [EMAIL PROTECTED]
On Fri, 26 Mar 2004
Original Message
Subject: Re: [CLI] PatternOptionBuilder
Date: Fri, 26 Mar 2004 17:53:11 -0500 (EST)
From: Michael Heuer [EMAIL PROTECTED]
To: Rob Oxspring [EMAIL PROTECTED]
I guess I'd also like it if
parser.parseAndHelp(String[])
did something better than return null
Moving to list for general info and to get any feedback from John.
Thanks for checking. Regarding v2 (all IMHO):
2.0 release plan?
Several times now we've said in a month or in a couple of months.
Personally I think I'm out of new features for now so I reckon it's time
to put a stake in the
Torsten Curdt wrote:
For me the point is ...I am currently writing about it.
Not sure if I should go for 2.0 branch already. And I am
also explainging the PatternOptionBuilder - which is
currently not fully working.
FWIW the cli2 branch is pretty stable and ready to be written about :)
That said
Rethreading on the [EMAIL PROTECTED] mailing list... :)
Hopefully someone will comment there,
Rob
Blume Samuel (KAID 41) wrote:
Extreme high memory use when using multipart HTML-forms.
Problem is obvious with following constellation:
- HTML-form with a lot of normal text input fields (like a
John Keyes wrote:
I spent today looking at realizing the v1 API with the v2 runtime.
After making some progress, I started to wonder was there any compeling
reason to do so.
Nothing compelling - just ease of adoption. Still haven't looked into
it in detail but an alternative to reimplementing
The sandbox cli project should be safe to remove now, it was being used
for some experimentation prior to v2 but all work has been moved to a
branch on cli proper which has been 2.0'd already (HEAD hasn't but no
release is expected there)
Rob
Henri Yandell wrote:
SANDBOX-PLAY
John Keyes wrote:
The specific exceptions now reside in the o.a.c.cli2.impl
package. These should be in the o.a.c.cli2 package so
caller's can catch the specific Exception if required.
My only reason for the current arrangement was that I was striving for a
good jdepend report. Not the most
Rob Oxspring wrote:
Thats all good then. Hopefully tonight I'll play with a little code
rather than just plot.
First up will be moving logic from CommandLineImpl to a new
WriteableCommandLineImpl so that CommandLineImpl can be used as a
simple base for other CommandLine implementations
John Keyes wrote:
Looking at the Argument API I was looking at the canPreProcess
and preProcess methods. I dislike the names as they don't
describe what the methods do.
Yeah - I wasn't so bothered when it was just preProcess but it is a bit
daft with canPreProcess too.
+1 on moving the logic
John Keyes wrote:
One of the failing unit tests on the ROXSPRING branch was the
testWithOption method on CommandLineDefaultsTests. The reason
it failed was the default value set during Option construction
was not accessible to CommandLine.getValue. So to make this
information accessible I
This is just a quick heads up to let you know what I've got planned in the next few
days for the cli2 package (on the ROXSPRING branch) it's mostly refactoring and minor
stuff before I get back to experimenting with option paths.
1) Refactor CommandLine. This class is getting pretty big and
Sorry for the slow response - I know I've been taken away from open source
for the last couple of weeks and I guess John's been busy too. We are
certainly open to contributions from non-committers but seeing a patch makes
it much easier to judge :)Personally I'd prefer patches against cli2
Hmm, well I've finished off the tests and committed my CommandLine changes
in the direction of flexible defaults.
I'm pretty sure there's room for manoeuvre between the two approaches.
Using CommandLines already allows hasOption(..), getSwitch(..), and
getValues(..) to delegate to the default
John Keyes wrote:
Now that we have jira on nagoya should we move to use this instead of
Bugzilla? No biggy, but it is much a nicer interface than bugzilla.
Not yet, please. We're still tuning the installation, and will
certainly
blow away the current database at least once more before
John Keyes wrote:
Our current group support is limited to mutually
exclusive groups. We need to support inclusive
groups also. This will allow more than one option
to have the same child options. Let me know if you
have any thoughts on it.
There's currently no problem with assigning the same
- Original Message -
From: John Keyes [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Friday, October 31, 2003 11:40 PM
Subject: Re: [CLI] 2.x Tasks
We definitely need to add these two tasks as well:
. mandatory groups
I think this can be achieved
I've been trawling through the mail archives and
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I've been trawling through the mail archives and open bugs to try and
produce a comprehensive task list for CLI2. The list is broadly broken down
into 6 sections and also contains a couple of items from my head. If we can
weed out any nonsense and add any missing tasks I'll then go through and
- Original Message -
From: Rob Oxspring [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Wednesday, October 22, 2003 3:19 PM
Subject: [CLI] 2.x Tasks
I've been trawling through the mail archives and open bugs to try and
produce a comprehensive task list
- Original Message -
From: John Keyes [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Wednesday, October 22, 2003 5:10 PM
Subject: Re: [CLI] 2.x Tasks
snip/
1.3) Enum Argument Values
Options should allow a list of possible values to validate
- Original Message -
From: John Keyes [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Wednesday, October 22, 2003 7:50 PM
Subject: Re: [CLI] Validation (was 2.x Tasks)
snip/
I can definitely understand your thinking but it is a feature I thought
was
Joakim,
As I understand things you are talking of something similar to the
reflection builder as John has pointed out. The builder will act as wrapper
around the CLI2 framework, using reflection to build a group of Options and
then making use of the CLI2's parsing and help formatter, before
Hi all,
I've just posted the latest snapshot of my CLI2 proposal to
http://www.oxspring.net/projects/cli/5/ (cheers for the prompting John).
I've concentrated on features and functionality and there is currently no
attempt at backwards compatability at all. Having said that, the whole thing
is
On Thu, 2 Oct 2003 22:25:17 +0100, Stephen Colebourne
[EMAIL PROTECTED] said:
From: Rodney Waldhoff [EMAIL PROTECTED]
Assuming pcollections is up and running (not necessarily released, but
with the code moved over, existing as commons proper component with
nightly builds and all that)
] would add another dependency to [CLI]. But
it could easily become a soft dependency (required to build but not
necessarily to run). The main problem is (IMHO) that [functor] is still
in the sandbox and thus there's no official binary release (yet).
Regards,
Herve
On Tue, 12 Aug 2003, Rob Oxspring
I haven't looked at the 1.0 code for a while but IIRC the cmdLineSyntax allows you to
supply the beginning of the command line that isn't dependant on the options. For
example the following usage line can be split into the section independant of options
java -jar myapp.jar and a section
Having discussed building a cli from xml before I've been a little unclear about what
sort of thing people are suggesting. So here
i've mapped out three ideas of how it could work to see how they compare with what
others are thinking. Note that suggestions 2 3
both ignore groups of options as
could have:
String countryCode = myCmd.getName();
int count = myCmd.getCount();
Which is stuff I end up doing in my apps now.
Gary
-Original Message-
From: Rob Oxspring [mailto:[EMAIL PROTECTED]
Sent: Monday, August 11, 2003 17:10
To: Jakarta Commons Developers List
Hi all,
I've finally got to another sensible point to present my CLI2 proposal. I've started
using the maven build process so this time I'm able to supply binaries as well as
sources, unfortunately though, I've not bothered to get them named sensibly yet.
Grab zips from
Gary,
At the moment there are two competing proposals for CLI2.
John Keyes has a branch in CVS (cli_1_x) that tidies up the current code to be much
more consistent. There hasn't been much talk about this since I stuck my oar in with
some alternative ideas. There may have been more work in
to do it better
Rob
- Original Message -
From: Rob Oxspring [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: John Keyes [EMAIL PROTECTED]
Sent: Sunday, July 06, 2003 10:26 PM
Subject: [CLI][Proposal] V2 Model
Hi all,
After posetive feedback from my previous model suggestion I've been working
and CommandLineParser and updated Argument at the
moment with more to follow as time allows. I've
also got thoughts about how to handle switches too but I'll mail about that separately.
Rob
- Original Message -
From: Rob Oxspring [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL
Hi Herve,
Cheers for the pointer, I'd forgotten about switches.
I figured I'd use this opportunity to plug my own CLI2 proposal a little more so
here's how I see switches slotting in:
A SwitchBuilder would be created to deal with a specific pair of enable / disable
prefixes:
SwitchBuilder
from the cli_1_x.
This will allow us to get the API in place. By this I mean adding the
XXXBuilder classes and the CommandLineParser class.
Let me know what you think and I'll get the ball rolling,
-John K
On Friday, Jun 20, 2003, at 00:27 Europe/Dublin, Rob Oxspring wrote
I've had a little look into implementing Commands as I described but wasn't sure how
I'd get them in without adding spaghetti to the
code. While looking around I was reminded of a few things that feel slightly wrong
and began to wonder whether the model might be
wrong. I'll outline the
- Original Message -
From: John Keyes [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Wednesday, June 11, 2003 12:24 AM
Subject: Re: [CLI] Support for CVS style command line
...
OptionsMap optionsMap = new OptionsMap();
// checkout command
- Original Message -
From: John Keyes [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Wednesday, June 11, 2003 12:27 AM
Subject: Re: [CLI][PATCH] Min and Max size for arguments
ArgumentBuilder.withSize(int) has been retained and sets both min and
max
- Original Message -
From: John Keyes [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Cc: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Wednesday, June 11, 2003 1:56 PM
Subject: Re: [CLI] Support for CVS style command line
Eitherway the
Big +1 on having the support, I'm just trying to get my head around the proposal for
now.
What does the validator do? I'd imagine the following call is all thats needed but the
... hints that I should be expecting
something more involved and have got the wrong end of the stick.
return
Attached is a patch that allows arguments to have specified a minimum and maximum
number of values rather than just the previous
size. An example of use might be where you are selecting a number of files for an
operation but want to ensure that at least one
value was specified:
- Original Message -
From: John Keyes [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Tuesday, March 04, 2003 10:12 PM
Subject: Re: [CLI] Version 2.0 - API
Still, the original poster had a point - isMandatory would typically
return a boolean, whereas
Okay the anonymous ones are used for things like goal in maven and
target in ant. The name is used for the HelpFormatter so it
can format this into [target1 [target2...[targetN]]].
An Arugment is anything that requires a value, so for example if
you are using the -buildfile argument for ant
-Original Message-
From: Jeff Varszegi [mailto:[EMAIL PROTECTED]]
Sent: 6 December 2002 17:15
To: Jakarta Commons Developers List
Subject: Re: [Collections] [SUBMIT] Trie
Map isn't appropriate for sure. The point of a trie seems to
be that you have a flexible indexed key for
. Partly the reason for suggesting we play with a few
implementations before committing to a final definition.
Rob
Jeff
--- Rob Oxspring [EMAIL PROTECTED] wrote:
-Original Message-
From: Jeff Varszegi [mailto:[EMAIL PROTECTED]]
Sent: 6 December 2002 17:15
To: Jakarta Commons
-Original Message-
From: Rich Dougherty [mailto:[EMAIL PROTECTED]]
-8---
Ok, I'll jump in and level a few criticisms at the interface
and implementation I submitted. :-)
--- Trie - is it the right name? ---
I must admit, the more I've looked at this, the more
uncomfortable
- Original Message -
From: Stephen Colebourne [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Thursday, December 05, 2002 12:13 AM
Subject: Re: [Collections] [SUBMIT] Trie
Hi,
I've taken a quick look at the code here, and that all looks fine.
for the
patch
it pointed me in the correct direction.
Thanks a million,
-John K
On Thursday, Nov 14, 2002, at 22:48 Europe/Dublin, Rob Oxspring wrote:
The list of options displayed by HelpFormatter was based only the
short options. In this patch helpOptions returns a list of all
Hi again,
A bunch of patches, mostly related to long only options. I've separated
them out to ease the accept/reject process.
OptionGroup:
Now uses long option as key if short not available. This allows
multiple long only options to be used in a group. I prefixed long
options with -- in line
Hi,
I've been playing with the CLI library (for almost 24 hours now!) and have stumbled
across a couple of long option related issues
that seem odd. The problems arise because I want to be able to use some options that
have a long option only. I would like to use
long-only options for some
Thanks John,
I'll have a look at what I can do about the first two items - as an exercise in
understanding your code if nothing else.
And as for the third item...
Third problem: --no-auth-cache doesn't parse
I need to add '-' as an allowed character, very simple fix.
Only bumped into
The list of options displayed by HelpFormatter was based only the short
options. In this patch helpOptions returns a list of all the options.
The test checks that the options added all appear in the helpOptions
method. I didn't spend long looking at the existing test cases so if
there is a more
- Original Message -
From: Ceki Gülcü [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Friday, May 10, 2002 4:07 PM
Subject: RE: Resisting the temptation
I'll be the first to admit that my reaction is a variant of NIH.
Okay then, I give up. What does NIH
89 matches
Mail list logo
