cvs commit: jakarta-commons-sandbox/attributes/src - New directory
jstrachan2002/11/14 00:09:21 jakarta-commons-sandbox/attributes/src - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/attributes/src/java/org - New directory
jstrachan2002/11/14 00:09:21 jakarta-commons-sandbox/attributes/src/java/org - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/attributes/src/java - New directory
jstrachan2002/11/14 00:09:21 jakarta-commons-sandbox/attributes/src/java - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/attributes/src/java/org/apache/commons - New directory
jstrachan2002/11/14 00:09:22 jakarta-commons-sandbox/attributes/src/java/org/apache/commons - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/attributes/src/java/org/apache/commons/attributes/impl - New directory
jstrachan2002/11/14 00:09:23 jakarta-commons-sandbox/attributes/src/java/org/apache/commons/attributes/impl - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/attributes/src/java/org/apache/commons/attributes - New directory
jstrachan2002/11/14 00:09:22 jakarta-commons-sandbox/attributes/src/java/org/apache/commons/attributes - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/attributes/src/java/org/apache - New directory
jstrachan2002/11/14 00:09:22 jakarta-commons-sandbox/attributes/src/java/org/apache - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/attributes/src/java/org/apache/commons/attributes/task - New directory
jstrachan2002/11/14 00:09:25 jakarta-commons-sandbox/attributes/src/java/org/apache/commons/attributes/task - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/attributes/src/test - New directory
jstrachan2002/11/14 00:09:28 jakarta-commons-sandbox/attributes/src/test - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/attributes/src/test/org - New directory
jstrachan2002/11/14 00:09:32 jakarta-commons-sandbox/attributes/src/test/org - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/attributes/src/test/org/apache/commons - New directory
jstrachan2002/11/14 00:09:38 jakarta-commons-sandbox/attributes/src/test/org/apache/commons - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/attributes/src/test/org/apache - New directory
jstrachan2002/11/14 00:09:35 jakarta-commons-sandbox/attributes/src/test/org/apache - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/attributes/xdocs - New directory
jstrachan2002/11/14 00:09:42 jakarta-commons-sandbox/attributes/xdocs - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/attributes/src/test/org/apache/commons/attributes - New directory
jstrachan2002/11/14 00:09:40 jakarta-commons-sandbox/attributes/src/test/org/apache/commons/attributes - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/attributes/xdocs/stylesheets - New directory
jstrachan2002/11/14 00:09:45 jakarta-commons-sandbox/attributes/xdocs/stylesheets - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/attributes/xdocs usage.xml navigation.xml index.xml
jstrachan2002/11/14 00:10:05 Added: attributes maven.xml LICENSE.txt .cvsignore project.properties project.xml attributes/src/java/org/apache/commons/attributes/impl DefaultAttributeFinder.java package.html attributes/src/test/org/apache/commons/attributes AttributesTest.java AttributesTestClass.java attributes/src/java/org/apache/commons/attributes/task package.html AttributesCompiler.java attributes/src/java/org/apache/commons/attributes AttributesException.java AttributeFinder.java package.html Attributes.java attributes/xdocs usage.xml navigation.xml index.xml Log: Added initial version of Commons Attributes. Commons Attributes provides a simple API to runtime metadata attributes. This allows runtime access to doclet tags etc. This is a refactor by Jon Tirsén of code he wrote for the Nanning project. http://nanning.sourceforge.net/ Revision ChangesPath 1.1 jakarta-commons-sandbox/attributes/maven.xml Index: maven.xml === project default=java:jar xmlns:jxr=jxr xmlns:j=jelly:core preGoal name=site:generate attainGoal name=clover/ /preGoal goal name=changelog:generate !-- don't have a repository yet, skip this -- /goal /project 1.1 jakarta-commons-sandbox/attributes/LICENSE.txt Index: LICENSE.txt === /* * $Header: /home/cvs/jakarta-commons/LICENSE,v 1.4 2002/04/11 13:24:02 dion Exp $ * $Revision: 1.4 $ * $Date: 2002/04/11 13:24:02 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999-2001 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names The Jakarta Project, Commons, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. * */ 1.1 jakarta-commons-sandbox/attributes/.cvsignore Index: .cvsignore === build.properties lib dist target *.log *.gz tmp .classpath .project 1.1 jakarta-commons-sandbox/attributes/project.properties Index:
Re: [lang] Bugs in JavaDoc comments
It should be xxxEnum, as a suggestion that all enum classes end in Enum. Stephen from:Martin Cooper [EMAIL PROTECTED] The JavaDoc comments for ValuedEnum are a little confused. There is a mixture of JavaVersion and JavaVersionEnum, probably caused by a change of mind at some point. ;-) I'd supply a patch, but I don't know which name you'd prefer to keep. -- Martin Cooper -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
[attributes][clazz]
James, I notice that you've checked in a new [attributes] project. This contains code to access metadata attributes if I'm reading it correctly. Since this is part of the goal of the [clazz] project, it would be good to be clear as to whether they are two projects ([clazz] depending on [attribute] using it as one possible attribute implementation), or whether the [attribute] code should be merged into [clazz]. I don't want to see duplicated work here ;-) Stephen -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14549] New: - Default charset
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14549. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14549 Default charset Summary: Default charset Product: Commons Version: Nightly Builds Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: HttpClient AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] As defined in RFC2616 the default character set is ISO-8859-1 an not US-ASCII as defined in HttpMethodBase. See 3.7.1 Canonicalization and Text Defaults at RFC 2616 -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/attributes project.xml
jstrachan2002/11/14 04:50:09 Modified:attributes project.xml Log: added XML depdendencies for JDK1.3 support with Maven Revision ChangesPath 1.2 +13 -2 jakarta-commons-sandbox/attributes/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/attributes/project.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- project.xml 14 Nov 2002 08:09:55 - 1.1 +++ project.xml 14 Nov 2002 12:50:09 - 1.2 -87,13 +87,24 /dependency dependency + idant/id + version1.5/version +/dependency + + !-- the following ultimately shouldn't be required once Maven can work without them -- +dependency idjunit/id version3.8.1/version /dependency dependency - idant/id - version1.5/version + idxml-apis/id + version1.0.b2/version +/dependency + +dependency + idxerces/id + version2.0.2/version /dependency /dependencies -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [attributes][clazz]
From: [EMAIL PROTECTED] James, I notice that you've checked in a new [attributes] project. This contains code to access metadata attributes if I'm reading it correctly. Since this is part of the goal of the [clazz] project, it would be good to be clear as to whether they are two projects ([clazz] depending on [attribute] using it as one possible attribute implementation), or whether the [attribute] code should be merged into [clazz]. I don't want to see duplicated work here ;-) The aim of the attributes project is to provide a small and simple unified API to allow the access of runtime doclet attributes used both in current AOP projects like Nanning and Rickard Öberg's AOP framework as well as hopefully to work with XDoclets XRAI project. (I'm hoping further down the road we can provide a unified API to both Nanning, XRAI and Rickard's framework). e.g. http://jakarta.apache.org/commons/sandbox/attributes/usage.html commons-attributes is simply a little component to access doclet attributes at runtime. At compile time the metadata will be created via QDox or XDoclet. I'm sure other mechanisms could be plugged in, like simple property files, XML files etc. So commons-attributes has a small, well defined scope. I still don't totally grok the aim or scope of clazz but at the very least it appears to be a broader higher level goal, more of being a component model, a new introspection mechanism, a meta-beans thing or something. Maybe commons-attributes might be useful in implementing clazz (I hope so) or maybe not, but these 2 projects do seem quite different. Or have I misunderstood what clazz is meant to be? James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
[GUMP] Build Failure - commons-jelly
This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2002-11-14/commons-jelly.html Buildfile: build.xml init: [mkdir] Created dir: /home/rubys/jakarta/jakarta-commons-sandbox/jelly/lib get-deps: compile: [mkdir] Created dir: /home/rubys/jakarta/jakarta-commons-sandbox/jelly/target/classes [javac] Compiling 325 source files to /home/rubys/jakarta/jakarta-commons-sandbox/jelly/target/classes [javac] /home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/ojb/BrokerTag.java:96: cannot access org.apache.commons.lang.exception.NestableRuntimeException [javac] file org/apache/commons/lang/exception/NestableRuntimeException.class not found [javac] broker = PersistenceBrokerFactory.defaultPersistenceBroker(); [javac] ^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/jetty/ResponseBodyTag.java:96: cannot resolve symbol [javac] symbol : method length () [javac] location: class org.mortbay.util.ByteArrayISO8859Writer [javac] httpResponse.setContentLength(writer.length()); [javac] ^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/task/JellyTask.java:80: warning: project in org.apache.tools.ant.ProjectComponent has been deprecated [javac] context.setVariable( project, project ); [javac] ^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/task/JellyTask.java:85: warning: location in org.apache.tools.ant.Task has been deprecated [javac] throw new BuildException(e, location); [javac] ^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/task/JellyTask.java:166: warning: project in org.apache.tools.ant.ProjectComponent has been deprecated [javac] context = new AntJellyContext(project, parentContext); [javac] ^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/task/JellyTask.java:196: warning: project in org.apache.tools.ant.ProjectComponent has been deprecated [javac] File file = project.resolveFile(name); [javac] ^ [javac] 2 errors [javac] 4 warnings BUILD FAILED file:/home/rubys/jakarta/jakarta-commons-sandbox/jelly/build.xml:34: Compile failed; see the compiler error output for details. Total time: 17 seconds -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [attributes][clazz]
from:James Strachan [EMAIL PROTECTED] From: [EMAIL PROTECTED] The aim of the attributes project is to provide a small and simple unified API to allow the access of runtime doclet attributes used both in current AOP projects like Nanning and Rickard Öberg's AOP framework as well as hopefully to work with XDoclets XRAI project. (I'm hoping further down the road we can provide a unified API to both Nanning, XRAI and Rickard's framework). One of the aims of [clazz] is a unified API to different metadata/attribute mechanisms. The mechanism is to be pluggable, so one solution is to use [attributes] as a pluggable implementation. But it might be better to just integrate it (otherwise you end up with two pluggable levels which adds to confusion). I still don't totally grok the aim or scope of clazz but at the very least it appears to be a broader higher level goal, more of being a component model, a new introspection mechanism, a meta-beans thing or something. Maybe commons-attributes might be useful in implementing clazz (I hope so) or maybe not, but these 2 projects do seem quite different. It aims to pull together DynaBeans, MetaData/Attributes and Introspection into one uniform API - Class manipulation. For attributes, [clazz] offers methods like: Clazz clazz = factory...; clazz.getProperty(surname).getAttribute(external); whereas [attributes] seems to have: Field field = AttributesTestClass.class.getDeclaredField(surname); Attributes.getAttribute(field, external); Thus one way to think of the difference is [attributes] is static, [clazz] is instance based. Stephen -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [attributes][clazz]
From: James Strachan [EMAIL PROTECTED] From: [EMAIL PROTECTED] One of the aims of [clazz] is a unified API to different metadata/attribute mechanisms. Maybe its time to update the PROSOAL.html which only really talks about being a new introspection reflection mechanism. It doesn't seem to mention metadata or doclet tags etc. Actually I went back and reread the proposal much more closely and it does actually mention this towards the end. Appologies - I'd missed this fact before. James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
[CLI] Options without short equivalent
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 options because short ones are in short supply and I would
like to keep options consistent across a suite
of applications (i.e.. -r should not mean recursive to foo while meaning revision to
bar - instead at least one of them should be
expanded into long form only)
Consider trying to mirror subversion's up subcommand, its options are presented below:
Valid options:
-r [--revision] arg : specify revision number ARG (or X:Y range)
-N [--nonrecursive] : operate on single directory only
-q [--quiet] : print as little as possible
--username arg : specify a username ARG
--password arg : specify a password ARG
--no-auth-cache : do not cache authentication tokens
--non-interactive: do no interactive prompting
The first problem: creating the options and displaying the usage information
Options such as revision quiet are easy:
options.addOption(OptionBuilder
.hasArg()
.withArgName(arg)
.withDescription(specify revision number ARG (or X:Y range))
.withLongOpt(revision)
.create(r)
);
options.addOption(OptionBuilder
.withDescription(print as little as possible)
.withLongOpt(quiet)
.create(q)
);
Producing usage information of:
-r,--revision arg specify revision number ARG (or X:Y range)
-q,--quietprint as little as possible
My first attempt at mirroring username was quite promising:
options.addOption(OptionBuilder
.hasArg()
.withArgName(arg)
.withDescription(specify a username ARG)
.withLongOpt(username)
.create()
);
options.addOption(OptionBuilder
.hasArg()
.withArgName(arg)
.withDescription(specify a password ARG)
.withLongOpt(password)
.create()
);
Output:
--password arg specify a password ARG
But only one of them is displayed in the usage information - clearly not good. Is
this a bug in HelpFormatter? it certainly seems
the most intuitive way to add long only options and the parsing works fine. Using the
long version as the create() argument is not
a great work around since the options no longet look like long options - the
distinctive '--' is no longer there.
The second problem: interpretting the results
Once the options are parsed there seems to be no way to check for the values by long
value. This seems odd since checking for the
long names of options would make for more readable code IMHO - e.g. the first of these
two lines reads reasonably while the second
cries out for an additional comment:
if(cmdLine.hasOption(quiet)){...}
if(cmdLine.hasOption(q)){...}
It seems to me that the CommandLine class has been overloaded with loads of
'convenience' methods at the expense of a couple of
useful ones:
public Option getOption(String shortName) maybe overload with a char version
public Option getLongOption(String longName)
The latter could be implemented by looping through the processed options and checking
invidually but a map lookup would make more
sense.
Third problem: --no-auth-cache doesn't parse
Only bumped into this while writing the email and doesn't really bother me at the
moment (the svn up stuff was just an example and
none of my options have hyphens in them). However I would have thought that long
options wouldn't restrict such characters - is
this a bug or is there a good reason for barfing on this? and if so shouldn't an
IllegalArgumentException be thrown?
I'm happy to work on patches to the above problems but wanted to check that I'm not
being daft first - do others agree with my
percieved bugs or should I be attacking things from another angle? And if i'm to code
any patches then pointers on where to start
would be good :)
Thanks,
Rob
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [CLI] Options without short equivalent
Hi Rob,
Comments below.
On Thu, 2002-11-14 at 16:15, Rob Oxspring wrote:
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 options because short ones are in short supply and I
would like to keep options consistent across a suite
of applications (i.e.. -r should not mean recursive to foo while meaning revision to
bar - instead at least one of them should be
expanded into long form only)
Consider trying to mirror subversion's up subcommand, its options are presented
below:
Valid options:
-r [--revision] arg : specify revision number ARG (or X:Y range)
-N [--nonrecursive] : operate on single directory only
-q [--quiet] : print as little as possible
--username arg : specify a username ARG
--password arg : specify a password ARG
--no-auth-cache : do not cache authentication tokens
--non-interactive: do no interactive prompting
The first problem: creating the options and displaying the usage information
Options such as revision quiet are easy:
options.addOption(OptionBuilder
.hasArg()
.withArgName(arg)
.withDescription(specify revision number ARG (or X:Y range))
.withLongOpt(revision)
.create(r)
);
options.addOption(OptionBuilder
.withDescription(print as little as possible)
.withLongOpt(quiet)
.create(q)
);
Producing usage information of:
-r,--revision arg specify revision number ARG (or X:Y range)
-q,--quietprint as little as possible
My first attempt at mirroring username was quite promising:
options.addOption(OptionBuilder
.hasArg()
.withArgName(arg)
.withDescription(specify a username ARG)
.withLongOpt(username)
.create()
);
options.addOption(OptionBuilder
.hasArg()
.withArgName(arg)
.withDescription(specify a password ARG)
.withLongOpt(password)
.create()
);
Output:
--password arg specify a password ARG
But only one of them is displayed in the usage information - clearly not good. Is
this a bug in HelpFormatter?
This looks like its a bug. I'll have a look at this later this evening.
it certainly seems
the most intuitive way to add long only options and the parsing works fine. Using
the long version as the create() argument is not
a great work around since the options no longet look like long options - the
distinctive '--' is no longer there.
You're constructing them in the correct manner alright.
The second problem: interpretting the results
Once the options are parsed there seems to be no way to check for the values by long
value. This seems odd since checking for the
long names of options would make for more readable code IMHO - e.g. the first of
these two lines reads reasonably while the second
cries out for an additional comment:
if(cmdLine.hasOption(quiet)){...}
if(cmdLine.hasOption(q)){...}
It seems to me that the CommandLine class has been overloaded with loads of
'convenience' methods at the expense of a couple of
useful ones:
public Option getOption(String shortName) maybe overload with a char version
public Option getLongOption(String longName)
The latter could be implemented by looping through the processed options and
checking invidually but a map lookup would make more
sense.
Again, this appears to be a bug, as this should be supported. Again
give me a couple of hours and I'll have a look at it.
Third problem: --no-auth-cache doesn't parse
I need to add '-' as an allowed character, very simple fix.
Only bumped into this while writing the email and doesn't really bother me at the
moment (the svn up stuff was just an example and
none of my options have hyphens in them). However I would have thought that long
options wouldn't restrict such characters - is
this a bug or is there a good reason for barfing on this? and if so shouldn't an
IllegalArgumentException be thrown?
An IllegalArgumentException should be thrown? I'll check this out too.
I'm happy to work on patches to the above problems but wanted to check that I'm not
being daft first - do others agree with my
percieved bugs or should I be attacking things from another angle? And if i'm to
code any patches then pointers on where to start
would be good :)
What XXXParser are you using BTW? You can have a go at the patches
yourself if you like but I can get to them this evening.
-John K
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
Re: [CLI] Options without short equivalent
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 this while writing the email and doesn't really bother me at the moment (the svn up stuff was just an example and none of my options have hyphens in them). However I would have thought that long options wouldn't restrict such characters - is this a bug or is there a good reason for barfing on this? and if so shouldn't an IllegalArgumentException be thrown? An IllegalArgumentException should be thrown? I'll check this out too. H as I said - this was an aside that I noticed while documenting the other problems. As such it didn't have the same level of investigation: It turns out the long option of no-auth-cache actually parses fine, it looks like I was using the short option work around at the time, i.e. -no-auth-cache doesn't parse which seems pretty reasonable. Also, I was obviously not concentrating when seeing the parse failure because it does fail fast and the error message I was seeing was in fact part of an IAE stack trace. So after all, nothing a cup of coffee and a pair of glasses wouldn't fix ;-) I'm happy to work on patches to the above problems but wanted to check that I'm not being daft first - do others agree with my percieved bugs or should I be attacking things from another angle? And if i'm to code any patches then pointers on where to start would be good :) What XXXParser are you using BTW? You can have a go at the patches yourself if you like but I can get to them this evening. I was using Basic but on more detailed checks demonstrate that Gnu and Posix behave just the same - perfectly reasonably. Rob (crawling under a rock) -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [Lang] Release 1.1?
hello fellow committers i'm not too sure where this thread ended up so... any objections to me starting to commit the MethodUtils stuff i've been working on? - robert -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14384] - ValidatorResources.get-method not working properly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14384. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14384 ValidatorResources.get-method not working properly --- Additional Comments From [EMAIL PROTECTED] 2002-11-14 18:11 --- We encountered this same bug as part of upgrading to Struts 1.1 nightly 20021105. In short, if the browser and server locales do not match, the struts JavascriptValidation tag fails to include the dynamic part of the javascript, and leaves the static part rendered on-screen. Our validation.xml has a single formset, with no specification of language, country or variant. Server was tomcat 4.0.4. Tested with servers set to locale en_US and en_GB. Tested with Mozilla and IE6 set to en_US and en_GB. The struts-validator example application showed the same symtoms on *all* combinations of server, browser and locale. The attached patch fixed our app. Haven't had time to check the validator app though. -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/swing SwingTagLibrary.java
jstrachan2002/11/14 10:23:07
Modified:jelly/src/java/org/apache/commons/jelly/tags/swing
SwingTagLibrary.java
Log:
Added patch from Paul Michael Reilly to add support for ButtonGroup. Thanks Paul!
Revision ChangesPath
1.15 +1 -0
jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/swing/SwingTagLibrary.java
Index: SwingTagLibrary.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/swing/SwingTagLibrary.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- SwingTagLibrary.java 30 Oct 2002 19:16:19 - 1.14
+++ SwingTagLibrary.java 14 Nov 2002 18:23:07 - 1.15
-177,6 +177,7
*/
protected void registerFactories() {
registerBeanFactory( button, JButton.class );
+ registerBeanFactory( buttonGroup, ButtonGroup.class );
registerBeanFactory( checkBox, JCheckBox.class );
registerBeanFactory( checkBoxMenuItem, JCheckBoxMenuItem.class );
registerBeanFactory( comboBox, JComboBox.class );
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
[Betwixt] linking multiple xml documents [WAS Re: AW: [Betwixt] Support of user defined XMLBeanInfo?]
On Tuesday, November 12, 2002, at 06:45 PM, [EMAIL PROTECTED] wrote: Hi Robert, hi Harald (i'm going to divide up your different topics.) snip What I was talking about in my previous mail was the ability to support a kind of XLink, which supports references between different XML documents. Until now I am not really sure, if this is a subject to Betwixt at all, because you will have to provide extra information or special objects for those references. At the moment I did not think about how to keep this flexible, if it is possible at all. i don't know if it's possible or whether it's an appropriate subject for betwixt either. that's what makes it interesting :) so, let's see if i've got it right. the idea would be that you want to process multiple xml files but create a single object model at the end. the idea is that the ID/IDREF would be used to match up a reference in one file with an object in another. is this right? - robert -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
[Betwixt] XMLBeanInfo customization [WAS Re: AW: [Betwixt] Support of user defined XMLBeanInfo?]
On Tuesday, November 12, 2002, at 06:45 PM, [EMAIL PROTECTED] wrote: Hi Robert, hi Harald snip But anyway I would like to use Betwixt in a more flexible way (e.g. having own XMLBeanInfos for some Beans). snip But on the other hand, if you are interested in making the way beans are written and read more flexible I would like to support you. For example what is it about the .betwixt files? I could not further information about them. .betwixt files are the way that betwixt allows XMLBeanInfo's to be customized. you can do things such as deciding which properties are going to be mapped to xml etc. there is (some) documentation on them on the web site (http://jakarta.apache.org/commons/betwixt). since XMLBeanInfo's were supposed to correspond to java.beans.BeanInfo. BeanInfo supports programmatic implementations. so if you had something like xxx.yyy.zzz.FooBean then betwixt might look for a xxx.yyy.zzz.FooBeanXMLBeanInfo class which would be a programmatic XMLBeanInfo. i don't know if adding this feature would help you or not. - robert -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
AW: [Betwixt] linking multiple xml documents [WAS Re: AW: [Betwixt] Support of user defined XMLBeanInfo?]
Yes, that's it. There are 2 problems: - ID/IDREF do not allow references between xml sources (they are just for internal references) - I need something like a proxy object, because otherwise I might result in reading almost all objects But corresponding to your next mail I might have a plain solution for this ... tbc - Harald -Ursprüngliche Nachricht- Von: robert burrell donkin [mailto:robertburrelldonkin;blueyonder.co.uk] Gesendet: Donnerstag, 14. November 2002 19:27 An: Jakarta Commons Developers List Betreff: [Betwixt] linking multiple xml documents [WAS Re: AW: [Betwixt] Support of user defined XMLBeanInfo?] On Tuesday, November 12, 2002, at 06:45 PM, [EMAIL PROTECTED] wrote: Hi Robert, hi Harald (i'm going to divide up your different topics.) snip What I was talking about in my previous mail was the ability to support a kind of XLink, which supports references between different XML documents. Until now I am not really sure, if this is a subject to Betwixt at all, because you will have to provide extra information or special objects for those references. At the moment I did not think about how to keep this flexible, if it is possible at all. i don't know if it's possible or whether it's an appropriate subject for betwixt either. that's what makes it interesting :) so, let's see if i've got it right. the idea would be that you want to process multiple xml files but create a single object model at the end. the idea is that the ID/IDREF would be used to match up a reference in one file with an object in another. is this right? - robert -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: Conversion utilities
Hi Travis,
On Thursday 14 November 2002 4:21 am, [EMAIL PROTECTED] wrote:
I also have a package of conversion classes that convert different
measurements from imperial to metric and vice versa for things like Length,
Pressure, Force, etc.
And along with that I have a Fraction and FractionFormat class that deals
with fractions (parsing, formatting, etc).
Wonder if commons might be a good fit for that?
Travis Reeder
--
To unsubscribe, e-mail:
mailto:commons-dev-unsubscribe;jakarta.apache.org For additional
commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Let me add some more stuff that might be the basis for something.
I need to represent currency ranges (in various currencies using the
ISO 4217 currency codes), and duration ranges (with various units: hours,
days, months, years).
I imagine the CurrencyRange would go like this
CONCEPTUAL API:
public interface CurrencyRange {
// ---
// Property Getters
// ---
Currency getCurrency();
o.a.c.lang.NumberRange getRange ();
}
The Currency class would be similar to java.util.Currency, but would be
available for JDK 1.3.1 users (me).
CurrencyRange would be immutable and possibly final (I've sketched it as an
interface above for discussion). Since my needs are completely covered by the
two properties above I have not added any further operations.
The DurationRange would be similar:
CONCEPTUAL APIs:
public interface DurationRange {
// ---
// Property Getters
// ---
DurationUnitEnum getUnit();
o.a.c.lang.NumberRange getRange ();
}
The constructor could be like this
DurationRange ( DurationUnitEnum, NumberRange range ) ;
(Once again DurationRange is likely to be a final class, not an interface.)
Travis' CalenderUtils.getRange ( int field, Date from, Date to ) method could
be used in a factory method on DurationRange
/**
* Return a DurationRange where min==max and min == to - from, and field is
* from Calender.
*/
public static DurationRange getInstance ( int field, Date from, Date to )
/**
* Return a DurationRange where field is from Calender.
*/
public static DurationRange getInstance ( int field, long min, long ) ;
For DurationUnitEnum:
import java.util.Calendar ;
public final class DurationUnitEnum extends ValuedEnum {
// enums based on code in Travis' CalendarUtils.getRange
public static final int DURATION_UNIT_SECOND_VALUE = Calendar.SECOND ;
public static final int DURATION_UNIT_MINUTE_VALUE = Calendar.MINUTE ;
public static final int DURATION_UNIT_HOUR_VALUE= Calendar.HOUR ;
public static final int DURATION_UNIT_DAY_VALUE = Calendar.DAY ;
public static final int DURATION_UNIT_WEEK_VALUE= Calendar.WEEK ;
public static final int DURATION_UNIT_MONTH_VALUE = Calendar.MONTH ;
public static final int DURATION_UNIT_YEAR_VALUE= Calendar.YEAR ;
public static final DurationUnitEnum DURATION_UNIT_SECOND
= new DurationUnitEnum
( Seconds, DURATION_UNIT_SECOND_VALUE );
snip/
public static final DurationUnitEnum DURATION_UNIT_YEAR
= new DurationUnitEnum
( Years, DURATION_UNIT_YEAR_VALUE );
private DurationUnitEnum name, int value) {
super( name, value );
}
public static DurationUnitEnum getEnum(String durationUnit) {
return (DurationUnitEnum) getEnum(DurationUnitEnum.class, durationUnit);
}
public static DurationUnitEnum getEnum(int durationUnit) {
return (DurationUnitEnum) getEnum(DurationUnitEnum.class, durationUnit);
}
public static Map getEnumMap() {
return getEnumMap(DurationUnitEnum.class);
}
public static List getEnumList() {
return getEnumList(DurationUnitEnum.class);
}
public static Iterator iterator() {
return iterator(DurationUnitEnum.class);
}
}
I'd be happy to contribute the basic attempt at CurrencyRange, if there is
interest and it doesn't overlap with anything else already in existance.
If anyone can point at a quantities library with this in already i'd be very
happy.
-Janek
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/reflect package.html
rdonkin 2002/11/14 10:50:59 Added: lang/src/java/org/apache/commons/lang/reflect package.html Log: Made a start on documentation for reflect. Revision ChangesPath 1.1 jakarta-commons/lang/src/java/org/apache/commons/lang/reflect/package.html Index: package.html === html head titlePackage Documentation for org.apache.commons.lang.reflect Package/title /head body bgcolor=white pPackage emorg.apache.commons.lang.reflect/em offers a collection of utility classes that assist in reflection. The aim is to create a simple, clean and clear API which can be built upon on by more sophisticated introspection schemes as well as fixes for bugs found in various java implementations./p h2Contents/h2 h2Accessibility Rules/h2 pThese determine which methods are in scope/p h3Java Language Specification Rules/h3 pThe emJava Language Specification Rules/em are those that are given in the emJava Language Specification/em as applied by the compiler. The aim of those methods who contract is given as the emJava Language Specification/em is to behave in an identical manner to compiled code. In other words, any code that would compile should be found by reflection and any code that would not should not/p h4Java 1.3 And Below/h4 pThis aim is actually easier said than done for some java versions. The reflection implementation is slow and buggy. If you are using one of these easier java versions, then you will probably find our code more reliable than the standard java implementation./p /body -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/reflect MethodUtils.java
rdonkin 2002/11/14 10:51:57
Modified:lang/src/java/org/apache/commons/lang/reflect
MethodUtils.java
Log:
Updated method utils with latest code from the beanutils version.
Revision ChangesPath
1.2 +217 -150
jakarta-commons/lang/src/java/org/apache/commons/lang/reflect/MethodUtils.java
Index: MethodUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/reflect/MethodUtils.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MethodUtils.java 24 Oct 2002 23:12:54 - 1.1
+++ MethodUtils.java 14 Nov 2002 18:51:57 - 1.2
-74,12 +74,20
* programmer. This can break an implementation if used incorrectly. This
* facility should be used with care.
*
- * author Based on code from BeanUtils
* author a href=mailto:scolebourne;apache.orgStephen Colebourne/a
+ * author Based on code from codeBeanUtils/code by: Craig R. McClanahan
+ * author Ralph Schaer
+ * author Chris Audley
+ * author Rey François
+ * author Gregor Raýman
+ * author Jan Sorensen
+ * author Robert Burrell Donkin
* version $Id$
*/
public class MethodUtils {
+public static final boolean debug = true;
+
/** An empty method array */
public static final Method[] EMPTY_METHOD_ARRAY = new Method[0];
-329,15 +337,15
args = ArrayUtils.EMPTY_OBJECT_ARRAY;
}
-return null;
-//Method method = getMatchingAccessibleMethod(
-//object.getClass(),
-//methodName,
-//parameterTypes);
-//if (method == null)
-//throw new NoSuchMethodException(No such accessible method: +
-//methodName + () on object: + object.getClass().getName());
-//return method.invoke(object, args);
+//return null;
+Method method = getMatchingAccessibleMethod(
+object.getClass(),
+methodName,
+parameterTypes);
+if (method == null)
+throw new NoSuchMethodException(No such accessible method: +
+methodName + () on object: + object.getClass().getName());
+return method.invoke(object, args);
}
-608,143 +616,202
}
-///**
-// * pFind an accessible method that matches the given name and has
compatible parameters.
-// * Compatible parameters mean that every method parameter is assignable from
-// * the given parameters.
-// * In other words, it finds a method with the given name
-// * that will take the parameters given.p
-// *
-// * pThis method is slightly undeterminstic since it loops
-// * through methods names and return the first matching method./p
-// *
-// * pThis method is used by
-// * {link
-// * #invokeMethod(Object object,String methodName,Object [] args,Class[]
parameterTypes)}.
-// *
-// * pThis method can match primitive parameter by passing in wrapper classes.
-// * For example, a codeBoolean/code will match a primitive
codeboolean/code
-// * parameter.
-// *
-// * param clazz find method in this class
-// * param methodName find method with this name
-// * param parameterTypes find method with compatible parameters
-// */
-//private static Method getMatchingAccessibleMethod(
-//Class clazz,
-//String methodName,
-//Class[] parameterTypes) {
-//// trace logging
-//if (log.isTraceEnabled()) {
-//log.trace(Matching name= + methodName + on + clazz);
-//}
-//
-//// see if we can find the method directly
-//// most of the time this works and it's much faster
-//try {
-//Method method = clazz.getMethod(methodName, parameterTypes);
-//return method;
-//
-//} catch (NoSuchMethodException e) { /* SWALLOW */ }
-//
-//// search through all methods
-//int paramSize = parameterTypes.length;
-//Method[] methods = clazz.getMethods();
-//for (int i = 0, size = methods.length; i size ; i++) {
-//if (methods[i].getName().equals(methodName)) {
-//// log some trace information
-//if (log.isTraceEnabled()) {
-//log.trace(Found matching name:);
-//log.trace(methods[i]);
-//}
-//
-//// compare parameters
-//Class[] methodsParams =
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang/reflect - New directory
rdonkin 2002/11/14 10:52:11 jakarta-commons/lang/src/test/org/apache/commons/lang/reflect - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang/reflect/priv - New directory
rdonkin 2002/11/14 10:52:37 jakarta-commons/lang/src/test/org/apache/commons/lang/reflect/priv - New directory -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang/reflect/priv PackageBean.java PrivateBean.java PrivateBeanFactory.java PrivateBeanSubclass.java PrivateDirect.java PrivateIndirect.java PublicSubBean.java
rdonkin 2002/11/14 10:53:36
Modified:lang build.xml
Added: lang/src/test/org/apache/commons/lang/reflect
AbstractChild.java AbstractParent.java
AlphaBean.java BetaBean.java Child.java
MethodUtilsTestCase.java PrimitiveBean.java
ReflectTestSuite.java TestBean.java
lang/src/test/org/apache/commons/lang/reflect/priv
PackageBean.java PrivateBean.java
PrivateBeanFactory.java PrivateBeanSubclass.java
PrivateDirect.java PrivateIndirect.java
PublicSubBean.java
Log:
Added unit tests for MethodUtils copied from the beanutils component.
Revision ChangesPath
1.6 +18 -2 jakarta-commons/lang/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/lang/build.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- build.xml 5 Nov 2002 16:45:45 - 1.5
+++ build.xml 14 Nov 2002 18:53:36 - 1.6
@@ -153,7 +153,15 @@
!-- == Unit Test Targets = --
- target name=test depends=compile.tests, test.lang, test.exception,
test.enum, test.builder, test.functor
+ target name=test depends=
+compile.tests,
+test.lang,
+test.exception,
+test.enum,
+test.builder,
+test.functor,
+test.reflect
+
description=Run all unit test cases
echo message=Running tests .../
/target
@@ -203,4 +211,12 @@
/java
/target
+ target name=test.reflect depends=compile.tests
+echo message=Running reflect package tests .../
+java classname=${test.runner} fork=yes
+failonerror=${test.failonerror}
+ arg value=org.apache.commons.lang.reflect.ReflectTestSuite/
+ classpath refid=test.classpath/
+/java
+ /target
/project
1.1
jakarta-commons/lang/src/test/org/apache/commons/lang/reflect/AbstractChild.java
Index: AbstractChild.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2002 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
Re: AW: [Betwixt] linking multiple xml documents [WAS Re: AW: [Betwix t] Support of user defined XMLBeanInfo?]
On Thursday, November 14, 2002, at 06:42 PM, [EMAIL PROTECTED] wrote: Yes, that's it. There are 2 problems: - ID/IDREF do not allow references between xml sources (they are just for internal references) this restriction only applies if the IDREF is defined in the DTD. you can tell betwixt that the IDREF is any attribute you want - it doesn't have to match the definition in the DTD. - I need something like a proxy object, because otherwise I might result in reading almost all objects But corresponding to your next mail I might have a plain solution for this ... tbc i'll look forward to that. - robert -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
AW: [Betwixt] XMLBeanInfo customization [WAS Re: AW: [Betwixt] Support of user defined XMLBeanInfo?]
... the solution you are suggesting would be very nice. I guess this could solve all my problems. I would provide a proxy object, which can be put in place of a object (reference). This object has getter and setter methods for a link and an object. The BeanReader and Writer then would just care about the link. The object will be read the first time the geter method is called, and the link will be changed, when the object has changed. I just have to make sure, that the object is not written either. This solution might not be perfect, but it would serve the purpose initially. So tell me, if I can support you enabling this feature in Betwixt. - Harald -Ursprüngliche Nachricht- Von: robert burrell donkin [mailto:robertburrelldonkin;blueyonder.co.uk] Gesendet: Donnerstag, 14. November 2002 19:38 An: Jakarta Commons Developers List Betreff: [Betwixt] XMLBeanInfo customization [WAS Re: AW: [Betwixt] Support of user defined XMLBeanInfo?] On Tuesday, November 12, 2002, at 06:45 PM, [EMAIL PROTECTED] wrote: Hi Robert, hi Harald snip But anyway I would like to use Betwixt in a more flexible way (e.g. having own XMLBeanInfos for some Beans). snip But on the other hand, if you are interested in making the way beans are written and read more flexible I would like to support you. For example what is it about the .betwixt files? I could not further information about them. .betwixt files are the way that betwixt allows XMLBeanInfo's to be customized. you can do things such as deciding which properties are going to be mapped to xml etc. there is (some) documentation on them on the web site (http://jakarta.apache.org/commons/betwixt). since XMLBeanInfo's were supposed to correspond to java.beans.BeanInfo. BeanInfo supports programmatic implementations. so if you had something like xxx.yyy.zzz.FooBean then betwixt might look for a xxx.yyy.zzz.FooBeanXMLBeanInfo class which would be a programmatic XMLBeanInfo. i don't know if adding this feature would help you or not. - robert -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Pleasedtameetcha, and a couple of questions
I'm a newbie to the Apache mailing lists; I ask forgiveness in advance for asking stupid questions. I've developed some things that I would like someone to take a look at to see if they are useful. The first is a LinkedList implementation that reduces object creation/garbage collection that works twice as fast as LinkedList. The second is a double-ended queue that offers good speed and deterministic delivery to waiting threads. In other words, if thread A requests something from the queue before thread B, thread A is guaranteed to get a result before thread B, even if both of them are initially forced to wait. This was an absolute requirement for some code I'm writing, and if it can be useful to someone I don't want to waste the chance. I would also like someone to look over the queue code, to check for correctness and maybe suggest improvements. Is there any interest in these two items? I have other general-purpose utility stuff too, but I'm not sure of the proper way to submit it all. Do I just send the code to this list, or what? I like what I see in the Commons project! I like Sun's Collections API in general, but there's nastiness everywhere-- unnecessary object creation, etc. Jeff Varszegi P.S. Anyone contribute a SkipList implementation yet? How about array-based Red-Black tree or something similar? I've found that most of the slowness in TreeSet and TreeMap is due to unnecessary object creation. __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
AW: AW: [Betwixt] linking multiple xml documents [WAS Re: AW: [Betwix t] Support of user defined XMLBeanInfo?]
--- There are 2 problems: - ID/IDREF do not allow references between xml sources (they are just for internal references) this restriction only applies if the IDREF is defined in the DTD. you can tell betwixt that the IDREF is any attribute you want - it doesn't have to match the definition in the DTD. This seems to me not the right way it should be handled. ID/IDREF are part of the XML specification. Afaik to use them in another way would violate the specification and might lead into troubles with other XML tools/libraries. - Harald -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: Conversion utilities
Janek,
I made an interface called Range that is supported by classes called ComparableRange
etc. The
ComparableRange class can use any objects that support Comparable (or, alternately,
any objects
with a supplied Comparator), and I also made specific versions for Date and Double to
eliminate
unnecessary casting. I needed the Date one for code I'm writing. I didn't get the
time to
implement any for primitive types yet. Range supports disjoint ranges of values,
checking to see
if a value falls within the range, merging two ranges, etc.
I will send my code as soon as I can-- right now I'm setting up a home network, and my
laptop
isn't on it yet. In the meantime, can you post the CurrencyRange code you've got?
Thanks a lot.
I definitely think it will be of general-purpose application. I don't know of any
quantities
library either, but I'd be thrilled to take a look at one.
Your friend,
Jeff
--- Janek Bogucki [EMAIL PROTECTED] wrote:
Hi Travis,
On Thursday 14 November 2002 4:21 am, [EMAIL PROTECTED] wrote:
I also have a package of conversion classes that convert different
measurements from imperial to metric and vice versa for things like Length,
Pressure, Force, etc.
And along with that I have a Fraction and FractionFormat class that deals
with fractions (parsing, formatting, etc).
Wonder if commons might be a good fit for that?
Travis Reeder
--
To unsubscribe, e-mail:
mailto:commons-dev-unsubscribe;jakarta.apache.org For additional
commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Let me add some more stuff that might be the basis for something.
I need to represent currency ranges (in various currencies using the
ISO 4217 currency codes), and duration ranges (with various units: hours,
days, months, years).
I imagine the CurrencyRange would go like this
CONCEPTUAL API:
public interface CurrencyRange {
// ---
// Property Getters
// ---
Currency getCurrency();
o.a.c.lang.NumberRange getRange ();
}
The Currency class would be similar to java.util.Currency, but would be
available for JDK 1.3.1 users (me).
CurrencyRange would be immutable and possibly final (I've sketched it as an
interface above for discussion). Since my needs are completely covered by the
two properties above I have not added any further operations.
The DurationRange would be similar:
CONCEPTUAL APIs:
public interface DurationRange {
// ---
// Property Getters
// ---
DurationUnitEnum getUnit();
o.a.c.lang.NumberRange getRange ();
}
The constructor could be like this
DurationRange ( DurationUnitEnum, NumberRange range ) ;
(Once again DurationRange is likely to be a final class, not an interface.)
Travis' CalenderUtils.getRange ( int field, Date from, Date to ) method could
be used in a factory method on DurationRange
/**
* Return a DurationRange where min==max and min == to - from, and field is
* from Calender.
*/
public static DurationRange getInstance ( int field, Date from, Date to )
/**
* Return a DurationRange where field is from Calender.
*/
public static DurationRange getInstance ( int field, long min, long ) ;
For DurationUnitEnum:
import java.util.Calendar ;
public final class DurationUnitEnum extends ValuedEnum {
// enums based on code in Travis' CalendarUtils.getRange
public static final int DURATION_UNIT_SECOND_VALUE = Calendar.SECOND ;
public static final int DURATION_UNIT_MINUTE_VALUE = Calendar.MINUTE ;
public static final int DURATION_UNIT_HOUR_VALUE= Calendar.HOUR ;
public static final int DURATION_UNIT_DAY_VALUE = Calendar.DAY ;
public static final int DURATION_UNIT_WEEK_VALUE= Calendar.WEEK ;
public static final int DURATION_UNIT_MONTH_VALUE = Calendar.MONTH ;
public static final int DURATION_UNIT_YEAR_VALUE= Calendar.YEAR ;
public static final DurationUnitEnum DURATION_UNIT_SECOND
= new DurationUnitEnum
( Seconds, DURATION_UNIT_SECOND_VALUE );
snip/
public static final DurationUnitEnum DURATION_UNIT_YEAR
= new DurationUnitEnum
( Years, DURATION_UNIT_YEAR_VALUE );
private DurationUnitEnum name, int value) {
super( name, value );
}
public static DurationUnitEnum getEnum(String durationUnit) {
return (DurationUnitEnum) getEnum(DurationUnitEnum.class, durationUnit);
}
public static DurationUnitEnum getEnum(int durationUnit) {
return (DurationUnitEnum) getEnum(DurationUnitEnum.class, durationUnit);
}
public static Map getEnumMap() {
return getEnumMap(DurationUnitEnum.class);
}
public static List getEnumList() {
return getEnumList(DurationUnitEnum.class);
}
public static Iterator iterator() {
Re: Conversion utilities
On Thu, 14 Nov 2002, Jeff Varszegi wrote: Janek, I made an interface called Range that is supported by classes called ComparableRange etc. The ComparableRange class can use any objects that support Comparable (or, alternately, any objects with a supplied Comparator), and I also made specific versions for Date and Double to +1. Why did no one think of this before? We're all fined one weeks pay. eliminate unnecessary casting. I needed the Date one for code I'm writing. I didn't get the time to implement any for primitive types yet. Range supports disjoint ranges of values, checking to see if a value falls within the range, merging two ranges, etc. So this is like NumberRange, but genericises it and makes it cool? I will send my code as soon as I can-- right now I'm setting up a home network, and my laptop isn't on it yet. In the meantime, can you post the CurrencyRange code you've got? Thanks a lot. I definitely think it will be of general-purpose application. I don't know of any quantities library either, but I'd be thrilled to take a look at one. Jade's the only one I've heard of. By a guy over in .fr I think. For quantities that is, always heard good things of it. Hen -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: Conversion utilities
Henri Yandell wrote: On Thu, 14 Nov 2002, Jeff Varszegi wrote: Janek, I made an interface called Range that is supported by classes called ComparableRange etc. The ComparableRange class can use any objects that support Comparable (or, alternately, any objects with a supplied Comparator), and I also made specific versions for Date and Double to Sounds like you could coordinating with the commons-validator package there is already a intRange(), floatRange(), in the GenerocValidator class. It could definately make use of your Range interface though ! -Rob -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14566] New: - NumberRange.getMaximum returns minimum
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14566. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14566 NumberRange.getMaximum returns minimum Summary: NumberRange.getMaximum returns minimum Product: Commons Version: 1.0 Final Platform: Other OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Lang AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] NumberRange.getMaximum returns the minimum value and not the max. -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 14566] - NumberRange.getMaximum returns minimum
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14566. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14566 NumberRange.getMaximum returns minimum [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-14 20:38 --- This is now fixed in CVS HEAD. -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: Re: Conversion utilities
The problem with the range interface when relating to dates is that with dates you would want to specify a field to give the range on, ex: days, months, weeks, etc. Travis Original Message From: Robert Leland [EMAIL PROTECTED] Sent: 2002-11-14 To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: Conversion utilities Henri Yandell wrote: On Thu, 14 Nov 2002, Jeff Varszegi wrote: Janek, I made an interface called Range that is supported by classes called ComparableRange etc. The ComparableRange class can use any objects that support Comparable (or, alternately, any objects with a supplied Comparator), and I also made specific versions for Date and Double to Sounds like you could coordinating with the commons-validator package there is already a intRange(), floatRange(), in the GenerocValidator class. It could definately make use of your Range interface though ! -Rob -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
[CLI][Patch] Help displays all options
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 appropriate class to put the one testcase in then feel free to move. Cheers, Rob Options.patch Description: Binary data OptionsTest.java Description: Binary data -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [lang] Notifier
I've been thinking that maybe Notifier belongs in [beanutils]. Events are pretty much part of the bean spec, rather than lang/util. So maybe this would be a better location. Of course that relies on [beanutils] being dependednt on [lang] (for the exception), but that should happen soon for the reflection code. Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] On Tue, 12 Nov 2002, Henri Yandell wrote: On Tue, 12 Nov 2002, Stephen Colebourne wrote: Some comments/suggestions: - Does JDK1.4 not have something similar? Does that matter? Does it? Damn. Hadn't been aware of it. There is Observer/Observable, but that's pretty useless. Do you mean EventListenerProxy? [along with EventListener]. It seems to not do much. At least looking at the source to GNU's Classpath project it seems to not do much. I think all they have is a common interface to all Listeners called EventListener, so the jdk 1.4 version of Notifier would check that the Class passed in was an EventListener class. [Side note, should we be storing a set of 'what to change when we go dependant on JDK 1.4' notes? :) ] Hen -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [Lang] Validate
Ola, Did you get a chance to code this class? Stephen - Original Message - From: Ola Berg [EMAIL PROTECTED] Experience from JUnit suggests otherwise. Logically, you could just have assertTrue(), in practice, it's convienent to have assertNotNull(), assertEquals(), and so on. Yes. That's why they were included. My question to you all was where to draw the line (the precise meaning of and so on so to speak). /O -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
[lang] StringUtils.isTrue()
The StringUtils.isTrue() method currently checks for 'true', 'on' and 'yes' Should it be changed to do a case insensitve check? Or just add checks for 'TRUE', 'ON', 'YES' ? Or is it fine as is ? Stephen -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [lang] [PATCH] ExceptionUtils.printRootCauseStackTrace
I like this idea, exception traces get s long. Shall we commit it? Stephen - Original Message - From: Dmitri Plotnikov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 08, 2002 2:55 PM Subject: [lang] [PATCH] ExceptionUtils.printRootCauseStackTrace Check out these methods I would like to propose for ExceptionUtils. They print very nice stack traces for nested exceptions. The idea is based on the observation that nested exceptions typically share a large portion of the stack trace. So, printRootCauseStackTrace trims those repeated parts. See attached sample stack trace. I attached diffs as well as full versions of the source files. If you are interested, just let me know, I can check this patch in myself. - Dmitri -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
[cli] Suggestions
I've just been writing my own Command Line Parsing library, when duh! I
looked to see what was out there, and came across commons-cli.
Its quite interesting to see the similarities between my implementation
and commons-cli
I have an Options type class as my main entry point, and posix
support (my library is built on top of the gnu-getopt package),
automatic generation of usage statements, command line parsing, and and
a similar usage pattern of create/parse/query.
Generally, the CLI implementation is neater and tidier.
However, my class has a number of features that CLI doesn't seem to
have (after a browse through the archives, I found that some of these
were anticipated by David below).
1. Options are typed (boolean, string, integer, double), with the type
being determined by the type of a default value that is passed in
during construction. This means that there are a *lot* of constructors,
as everything is heavily overloaded. From the user (developer)
perspective, if you pass the right kind of object in as a default, then
the library will do all the work (including checking the values
supplied on the command line). I saw what looked to be type support in
CLI, but it didn't seem very obvious how to use it.
3. Options can have a long name and no short name (flag). This is handy
for when you have a lot of parameters, and run out of suitable short
names.
3. Sets of options can be read from and written to properties files.
4. A set of default options is provided (disabled by default) that will
read properties files during parsing, and write them once parsing is
completed.
For example:
mycommand --properies-file in.properties --some-other-argument
some_value --write-properties-file out.properties
reads option values from in.properties, over-rides the value for
--some-other-argument, and dumps the properties out to out.properties.
The special property options names and flags can be fully customised
via method calls.
5. During interrogation, option values are retrieved via booleanValue,
stringValue, etc. calls. These are type-safe, in that trying to
retrieve a boolean value from an integer option will throw a
runtime-exception, which will be thrown the first time that the program
is run
(assuming, reasonably that you go through a create/parse/query phase
early in program initialisation).
I am pretty sure that most of this functionality could be added to CLI
without breaking the existing interfaces, and may be useful for some
people (not requiring a flag for each option, simple typing, and the
properties file functionality has been very handy for me).
If anyone is interested in this, mail me directly for further info. I'd
be happy to write patches if people think its a good idea.
cheers,
Martin
Date: Sat, 05 Jan 2002 20:05:40 -0500
From: David Dixon-Peugh [EMAIL PROTECTED]
Subject: [cli] Suggestions
Content-Type: text/plain; charset=us-ascii; format=flowed
I've been fooling with the CLI package in the
Sandbox, and I've got a few suggestions on how
it might be improved.
#1 - Usage Statement
Since we are setting up the Options class with
all the option possibilites and their descriptions,
it seems a logical place to generate a Usage
statement.
#2 - Default Values on Options
It seems that the default values are known when
the options are created. It makes sense to set
the defaults when the Options object is created.
#3 - Integrate with Properties Object
It would be nice, if I could write something like
this:
public static void main(String args[]) {
Options opt = new QuiltOptions(quilt.properties);
try {
Properties prop = opt.parse( args );
} catch (MissingArgumentException e) {
System.err.println( opt.getUsageStatement() );
System.exit( -1 );
}
}
What do you think? I think it makes the code look
an awful lot cleaner than the way it works now.
Thanks,
DDP
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/cli/src/test/org/apache/commons/cli ParseTest.java
jkeyes 2002/11/14 15:30:03
Modified:cli/src/java/org/apache/commons/cli CommandLine.java
cli/src/test/org/apache/commons/cli ParseTest.java
Log:
added fix for Rob's problem (2), so it is now possible to query using either the opt
or longOpt
Revision ChangesPath
1.13 +13 -2
jakarta-commons/cli/src/java/org/apache/commons/cli/CommandLine.java
Index: CommandLine.java
===
RCS file:
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli/CommandLine.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- CommandLine.java 11 Oct 2002 23:07:34 - 1.12
+++ CommandLine.java 14 Nov 2002 23:30:02 - 1.13
-91,6 +91,9
/** the processed options */
private Map options = new HashMap();
+/** the option name map */
+private Map names = new HashMap();
+
/** Map of unique options for ease to get complete list of options */
private Map hashcodeMap = new HashMap();
-179,8 +182,13
public String[] getOptionValues( String opt ) {
List values = new java.util.ArrayList();
-if( options.containsKey( opt ) ) {
-List opts = (List)options.get( opt );
+String key = opt;
+if( names.containsKey( opt ) ) {
+key = (String)names.get( opt );
+}
+
+if( options.containsKey( key ) ) {
+List opts = (List)options.get( key );
Iterator iter = opts.iterator();
while( iter.hasNext() ) {
-289,6 +297,9
String key = opt.getOpt();
if( .equals(key) ) {
key = opt.getLongOpt();
+}
+else {
+names.put( opt.getLongOpt(), key );
}
if( options.get( key ) != null ) {
1.6 +1 -0
jakarta-commons/cli/src/test/org/apache/commons/cli/ParseTest.java
Index: ParseTest.java
===
RCS file:
/home/cvs/jakarta-commons/cli/src/test/org/apache/commons/cli/ParseTest.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ParseTest.java19 Sep 2002 22:59:44 - 1.5
+++ ParseTest.java14 Nov 2002 23:30:03 - 1.6
-87,6 +87,7
assertTrue( Confirm -a is set, cl.hasOption(a) );
assertTrue( Confirm -b is set, cl.hasOption(b) );
assertTrue( Confirm arg of -b, cl.getOptionValue(b).equals(toast)
);
+assertTrue( Confirm arg of --bfile, cl.getOptionValue( bfile
).equals( toast ) );
assertTrue( Confirm size of extra args, cl.getArgList().size() == 2);
}
catch (ParseException e)
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [lang] StringUtils.isTrue()
case insenstive i reckon. s'cheap addition :) On Thu, 14 Nov 2002, Stephen Colebourne wrote: The StringUtils.isTrue() method currently checks for 'true', 'on' and 'yes' Should it be changed to do a case insensitve check? Or just add checks for 'TRUE', 'ON', 'YES' ? Or is it fine as is ? Stephen -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [collections] LoopingIterator
Jonathan, I was going to include your files in the CVS. However, I discovered that they do not cope with the situation where the collection being wrapped is altered. ie. hasNext() always returns the initially cached value, even if the list is clear()ed or it.remove() is called. Can you sort this? Also, if resubmitting could you place the code in the correct package and with an Apache licence (from another collections file) to confirm that this is an official donation of code :-) Thanks Stephen - Original Message - From: Jonathan Carlson [EMAIL PROTECTED] It is attached with updated unit tests. It was so easy that I'm surprised I didn't implement the remove() in the first place. Thanks! Jonathan Carlson Minneapolis, Minnesota --- Stephen Colebourne [EMAIL PROTECTED] wrote: From: Jonathan Carlson [EMAIL PROTECTED] I can add a remove method and test cases unless it's easier for you to just add it. I think it would just use the remove method on the Collection. If the iterator returned by the Collection implementer doesn't support it then this won't either. If you could submit the revised code and test case, I think that I'm willing to commit it to collections. Stephen As for a use-case, I am using it for a displaying a number of our banner ads on our e-commerce site. The round-robin task dispatcher mentioned earlier is another one. Jonathan Carlson --- Stephen Colebourne [EMAIL PROTECTED] wrote: [Jonathan, I have sent back to commons-dev mailing list which is the appropriate place for design/code discussions.] I took a quick look, and I believe that the code in the zip will work. However, my main concern is why this would be needed. Is there a use case for an iterator that never ends? I would also like to see the remove method implemented. It should be possible. Stephen - Original Message - From: Jonathan Carlson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 18, 2002 3:53 PM Subject: LoopingIterator Hi Stephen, Thanks for your work on the IteratorUtils. I thought this might be a good addition if it hasn't been added already. It's an iterator that loops continually. Unfortunately, it can't just decorate another iterator but has to wrap a collection due to the fact that iterators cannot be reset to the beginning of the collection. Included is a jUnit test case that shows it works as advertised. Hope this helps. Jonathan Carlson Minneapolis, Minnesota = Jonathan Carlson [EMAIL PROTECTED] Minneapolis, Minnesota __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com ATTACHMENT part 2 application/x-zip-compressed name=LoopingIterator.zip = Jonathan Carlson [EMAIL PROTECTED] Minneapolis, Minnesota __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org = Jonathan Carlson [EMAIL PROTECTED] Minneapolis, Minnesota __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: [lang] [PATCH] ExceptionUtils.printRootCauseStackTrace
+1 Steven Caswell [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving One ring to rule them all, one ring to find them... -Original Message- From: Stephen Colebourne [mailto:scolebourne;btopenworld.com] Sent: Thursday, November 14, 2002 6:18 PM To: Jakarta Commons Developers List Subject: Re: [lang] [PATCH] ExceptionUtils.printRootCauseStackTrace I like this idea, exception traces get s long. Shall we commit it? Stephen - Original Message - From: Dmitri Plotnikov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 08, 2002 2:55 PM Subject: [lang] [PATCH] ExceptionUtils.printRootCauseStackTrace Check out these methods I would like to propose for ExceptionUtils. They print very nice stack traces for nested exceptions. The idea is based on the observation that nested exceptions typically share a large portion of the stack trace. So, printRootCauseStackTrace trims those repeated parts. See attached sample stack trace. I attached diffs as well as full versions of the source files. If you are interested, just let me know, I can check this patch in myself. - Dmitri -- -- -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
[lang] MethodUtils - assignableFrom
Michael, you may want to have a look at the ClassUtils class in [lang]. This is where I moved some of the assignableFrom logic (ie. moved out of MethodUtils). ClassUtils has no tests, so if you have some for this method then that would be good ;-) (It was moved as its not dependent on reflection, just class identification) Stephen -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: [lang] StringUtils.isTrue()
+1 Steven Caswell [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving One ring to rule them all, one ring to find them... -Original Message- From: Henri Yandell [mailto:bayard;generationjava.com] Sent: Thursday, November 14, 2002 6:37 PM To: Jakarta Commons Developers List Subject: Re: [lang] StringUtils.isTrue() case insenstive i reckon. s'cheap addition :) On Thu, 14 Nov 2002, Stephen Colebourne wrote: The StringUtils.isTrue() method currently checks for 'true', 'on' and 'yes' Should it be changed to do a case insensitve check? Or just add checks for 'TRUE', 'ON', 'YES' ? Or is it fine as is ? Stephen -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [lang] [patch] Javadoc
Stephen Colebourne wrote: I tried to apply the patch, but it failed, so I've done it mostly by hand instead. You may want to check the CVS again ;-) Hi! I've attached a new patch with the most obvious changes that was missed. :) Index: StringUtils.java === RCS file: /home/cvspublic/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v retrieving revision 1.22 diff -r1.22 StringUtils.java 1530c1530 * param str the Object to check --- * param obj the Object to check Index: ArrayUtils.java === RCS file: /home/cvspublic/jakarta-commons/lang/src/java/org/apache/commons/lang/ArrayUtils.java,v retrieving revision 1.2 diff -r1.2 ArrayUtils.java 400c400,401 * param true if length of arrays matches, treating codenull/code as an empty array --- * return codetrue/code if length of arrays matches, treating * codenull/code as an empty array 418,419c419,421 * param true if length of arrays matches, treating codenull/code as an empty array */ --- * return codetrue/code if length of arrays matches, treating * codenull/code as an empty array */ 436,437c438,440 * param true if length of arrays matches, treating codenull/code as an empty array */ --- * return codetrue/code if length of arrays matches, treating * codenull/code as an empty array */ 454,455c457,459 * param true if length of arrays matches, treating codenull/code as an empty array */ --- * return codetrue/code if length of arrays matches, treating * codenull/code as an empty array */ 472,473c476,478 * param true if length of arrays matches, treating codenull/code as an empty array */ --- * return codetrue/code if length of arrays matches, treating * codenull/code as an empty array */ 490,491c495,497 * param true if length of arrays matches, treating codenull/code as an empty array */ --- * return codetrue/code if length of arrays matches, treating * codenull/code as an empty array */ 508,509c514,516 * param true if length of arrays matches, treating codenull/code as an empty array */ --- * return codetrue/code if length of arrays matches, treating * codenull/code as an empty array */ 526,527c533,535 * param true if length of arrays matches, treating codenull/code as an empty array */ --- * return codetrue/code if length of arrays matches, treating * codenull/code as an empty array */ 543c551 * param true if type of arrays matches --- * return codetrue/code if type of arrays matches -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [collections] BoundedCollection ?
I like this idea, and can see no problems with implementation. Would you
like to code it up as a new interface and patches to existing files (from
CVS head) ? Its the best way to get it included ;-)
In addition you could add convenience static methods to BufferUtils to do
this code
public static boolean isFull(Buffer buffer) {
if (myBuffer instanceof BoundedCollection)
bufferFull=((BoundedCollection)myBuffer).isFull();
else
bufferFull=false; // as long as there is some free memory left
}
(and also maxsize)
Stephen
- Original Message -
From: Herve Quiroz [EMAIL PROTECTED]
I have recently switched to the Jakarta Commons Collections 2.1 library. I
am mostly using it for Buffer implementations as I am working on a network
simulator using queues of messages. Unfortunately there is no method to
know if a buffer is full other than adding an object and catching a
BufferOverflowException... Which is quite annoying for me as the simulator
should only simulate the latency from some data tranfer only if the target
buffer is not full. And I can't predict if a given buffer will a bounded
one or not (depending on the scenario used for simulation).
So, I was planning on coding some utils to test whether a buffer is full
or not. But then I thought of another alternative, the BoundedCollection
interface :
public interface BoundedCollection extends java.util.Collection
{
public boolean isFull();
public int maxSize();
}
... of course implemented by the BoundedBuffer class.
So to test if a buffer if full :
if (myBuffer instanceof BoundedCollection)
{
bufferFull=((BoundedCollection)myBuffer).isFull();
}
else
{
bufferFull=false; // as long as there is some free memory left
}
Maybe I am just reinventing the wheel but if someone as a
{cheap,quick,simple} solution, please tell me. I had my own queue library
working until I changed all my sources to use commons-collections just to
realize I am stuck with this issue.
Regards
Herve Quiroz
--
To unsubscribe, e-mail:
mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:commons-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
[collections] Pleasedtameetcha, and a couple of questions
From: Jeff Varszegi [EMAIL PROTECTED] I'm a newbie to the Apache mailing lists; I ask forgiveness in advance for asking stupid questions. Quick hint - watch what others do before posting yourself...such as the [collections] tag in the Subject line ;-) The first is a LinkedList implementation that reduces object creation/garbage collection that works twice as fast as LinkedList. Sounds promising The second is a double-ended queue that offers good speed and deterministic delivery to waiting threads. In other words, if thread A requests something from the queue before thread B, thread A is guaranteed to get a result before thread B, even if both of them are initially forced to wait. This was an absolute requirement for some code I'm writing, and if it can be useful to someone I don't want to waste the chance. I would also like someone to look over the queue code, to check for correctness and maybe suggest improvements. May be too specialised. Don't know without looking. Does it implement our Buffer interface? Is there any interest in these two items? I have other general-purpose utility stuff too, but I'm not sure of the proper way to submit it all. Do I just send the code to this list, or what? I suggest starting a new thread (with a clear Subject line) for each submission, eg. [collections][SUBMIT] Faster LinkedList and attach the code P.S. Anyone contribute a SkipList implementation yet? How about array-based Red-Black tree or something similar? I've found that most of the slowness in TreeSet and TreeMap is due to unnecessary object creation. SkipList??? Tree was discussed about 8 months ago but never got in. It should do though. Stephen -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang StringUtils.java
scolebourne2002/11/14 16:06:40
Modified:lang/src/test/org/apache/commons/lang StringUtilsIsTest.java
lang/src/java/org/apache/commons/lang StringUtils.java
Log:
Change the isTrue() method to cope with strings case insensitively
Revision ChangesPath
1.3 +5 -1
jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsIsTest.java
Index: StringUtilsIsTest.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/StringUtilsIsTest.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- StringUtilsIsTest.java28 Oct 2002 04:33:29 - 1.2
+++ StringUtilsIsTest.java15 Nov 2002 00:06:40 - 1.3
-139,6 +139,10
assertEquals(true, StringUtils.isTrue(true));
assertEquals(true, StringUtils.isTrue(yes));
assertEquals(true, StringUtils.isTrue(on));
+assertEquals(true, StringUtils.isTrue(TRUE));
+assertEquals(true, StringUtils.isTrue(ON));
+assertEquals(true, StringUtils.isTrue(YES));
+assertEquals(true, StringUtils.isTrue(TruE));
}
public void testIsAlphaspace() {
1.23 +6 -8
jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java
Index: StringUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- StringUtils.java 14 Nov 2002 22:29:25 - 1.22
+++ StringUtils.java 15 Nov 2002 00:06:40 - 1.23
-1502,19 +1502,17
/**
* Checks if the String contains a 'true' value. These are defined
- * as the words 'true', 'on' and 'yes'.
+ * as the words 'true', 'on' and 'yes', case insensitive.
*
* param str the String to check
- * return true if the string is 'true|on|yes'
+ * return true if the string is 'true|on|yes' case insensitive
*/
public static boolean isTrue(String str) {
-if(true.equals(str)) {
+if (true.equalsIgnoreCase(str)) {
return true;
-} else
-if(on.equals(str)) {
+} else if (on.equalsIgnoreCase(str)) {
return true;
-} else
-if(yes.equals(str)) {
+} else if (yes.equalsIgnoreCase(str)) {
return true;
}
return false;
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/lang STATUS.html
scolebourne2002/11/14 16:07:26 Modified:lang STATUS.html Log: Add more TODOs Revision ChangesPath 1.27 +2 -1 jakarta-commons/lang/STATUS.html Index: STATUS.html === RCS file: /home/cvs/jakarta-commons/lang/STATUS.html,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- STATUS.html 14 Nov 2002 22:01:27 - 1.26 +++ STATUS.html 15 Nov 2002 00:07:26 - 1.27 -98,6 +98,7 liO(n) - Document all algorithm-implementing methods with the order. Possibly with an O(n) on the end of each parameterm or with an order tag./li liMoney and Currency/li liExceptionUtils - truncated stack trace, from Dmitri/li +liValidate - a utility to aid validation - Ola Berg working on this/li /ul -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [lang] [patch] Javadoc
Unfortunately its the patch format thats wrong (Eclipse doesn't like it). See: http://jakarta.apache.org/commons/patches.html (I think its the -u you're missing) Stephen - Original Message - From: Fredrik Westermarck [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Thursday, November 14, 2002 11:55 PM Subject: Re: [lang] [patch] Javadoc Stephen Colebourne wrote: I tried to apply the patch, but it failed, so I've done it mostly by hand instead. You may want to check the CVS again ;-) Hi! I've attached a new patch with the most obvious changes that was missed. :) Index: StringUtils.java === RCS file: /home/cvspublic/jakarta-commons/lang/src/java/org/apache/commons/lang/String Utils.java,v retrieving revision 1.22 diff -r1.22 StringUtils.java 1530c1530 * @param str the Object to check --- * @param obj the Object to check Index: ArrayUtils.java === RCS file: /home/cvspublic/jakarta-commons/lang/src/java/org/apache/commons/lang/ArrayU tils.java,v retrieving revision 1.2 diff -r1.2 ArrayUtils.java 400c400,401 * @param true if length of arrays matches, treating codenull/code as an empty array --- * @return codetrue/code if length of arrays matches, treating * codenull/code as an empty array 418,419c419,421 * @param true if length of arrays matches, treating codenull/code as an empty array */ --- * @return codetrue/code if length of arrays matches, treating * codenull/code as an empty array */ 436,437c438,440 * @param true if length of arrays matches, treating codenull/code as an empty array */ --- * @return codetrue/code if length of arrays matches, treating * codenull/code as an empty array */ 454,455c457,459 * @param true if length of arrays matches, treating codenull/code as an empty array */ --- * @return codetrue/code if length of arrays matches, treating * codenull/code as an empty array */ 472,473c476,478 * @param true if length of arrays matches, treating codenull/code as an empty array */ --- * @return codetrue/code if length of arrays matches, treating * codenull/code as an empty array */ 490,491c495,497 * @param true if length of arrays matches, treating codenull/code as an empty array */ --- * @return codetrue/code if length of arrays matches, treating * codenull/code as an empty array */ 508,509c514,516 * @param true if length of arrays matches, treating codenull/code as an empty array */ --- * @return codetrue/code if length of arrays matches, treating * codenull/code as an empty array */ 526,527c533,535 * @param true if length of arrays matches, treating codenull/code as an empty array */ --- * @return codetrue/code if length of arrays matches, treating * codenull/code as an empty array */ 543c551 * @param true if type of arrays matches --- * @return codetrue/code if type of arrays matches -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [lang] StringUtils.isTrue()
Done Stephen - Original Message - From: Steven Caswell [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Thursday, November 14, 2002 11:52 PM Subject: RE: [lang] StringUtils.isTrue() +1 Steven Caswell [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving One ring to rule them all, one ring to find them... -Original Message- From: Henri Yandell [mailto:bayard;generationjava.com] Sent: Thursday, November 14, 2002 6:37 PM To: Jakarta Commons Developers List Subject: Re: [lang] StringUtils.isTrue() case insenstive i reckon. s'cheap addition :) On Thu, 14 Nov 2002, Stephen Colebourne wrote: The StringUtils.isTrue() method currently checks for 'true', 'on' and 'yes' Should it be changed to do a case insensitve check? Or just add checks for 'TRUE', 'ON', 'YES' ? Or is it fine as is ? Stephen -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [lang] Money/Units/Quantities [was Re: Conversion utilities]
+1, I've got some code too that I can merge in to fill any gaps. I suggest we keep this in the [lang-sandbox] with CalendarUtils for the moment. Stephen - Original Message - From: Steven Caswell [EMAIL PROTECTED] I have a Money class that I can contribute to get the ball rolling. Steven Caswell [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving One ring to rule them all, one ring to find them... -Original Message- From: Stephen Colebourne [mailto:scolebourne;btopenworld.com] Sent: Thursday, November 14, 2002 4:29 PM To: Jakarta Commons Developers List Subject: [lang] Money/Units/Quantities [was Re: Conversion utilities] http://www.dautelle.com/jade is the most well known units and quantities package. It also follows the JSR on the subject. In some ways, it would be nice to see this work brought under the Jakarta Commons group, as there is much useful code there. Even if we don't intend to have a whole units package in [lang], we should probably have Money and Currency classes. They are pretty fundamental to many business applications. (I don't think that a [money] is required here ??) Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, November 14, 2002 7:54 PM Subject: Re: Conversion utilities On Thu, 14 Nov 2002, Jeff Varszegi wrote: Janek, I made an interface called Range that is supported by classes called ComparableRange etc. The ComparableRange class can use any objects that support Comparable (or, alternately, any objects with a supplied Comparator), and I also made specific versions for Date and Double to +1. Why did no one think of this before? We're all fined one weeks +pay. eliminate unnecessary casting. I needed the Date one for code I'm writing. I didn't get the time to implement any for primitive types yet. Range supports disjoint ranges of values, checking to see if a value falls within the range, merging two ranges, etc. So this is like NumberRange, but genericises it and makes it cool? I will send my code as soon as I can-- right now I'm setting up a home network, and my laptop isn't on it yet. In the meantime, can you post the CurrencyRange code you've got? Thanks a lot. I definitely think it will be of general-purpose application. I don't know of any quantities library either, but I'd be thrilled to take a look at one. Jade's the only one I've heard of. By a guy over in .fr I think. For quantities that is, always heard good things of it. Hen -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [Lang] Release 1.1? [wasRe: [Lang] Please fix this]
+1, a 1.0.1 now makes sense. Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Thursday, November 14, 2002 9:08 PM Subject: Re: [Lang] Release 1.1? [wasRe: [Lang] Please fix this] Okay, with the Range code suggestions today and Robert getting into MethodUtils I think there's still a lot of good development work ongoing and that a 1.0.1 should be done. This would include the following bugfixes: 14566 - NumberRange.getMaximum 13568 - Enum allows enums with same name 13527 - ExceptionUtils lacks common J2EE method names I don't think the other fixes are major enough to be splicing by hand. Does anyone care to volunteer? Else I'll just go ahead and follow Steve's instructions on this and get it happy. Hen On Fri, 8 Nov 2002, Steve Downey wrote: StringUtils is binary incompatible with the 1.0 version of StringUtils, so it certainly isn't 1.0.1. Plus, I've never liked mixing bugfix releases in with new functionality, which always imply new bugs. If we'd spotted the maximum() bug before release, it would have stopped the release. Fixing showstopper bugs is good cause for a bug fix release. And it's not that hard: cvs tag -b -r LANG_1_0 LANG_1_0_BRANCH lang cvs co -r LANG_1_0_BRANCH -d lang_1_0_branch lang cd lang_1_0_branch apply patch ant build ant test cvs commit edit default.properties to reflect new version number = 1.0.1 cvs commit then it's like doing any release. Tag it with LANG_1_0_1. On Friday 08 November 2002 10:07 am, [EMAIL PROTECTED] wrote: I would support a release (1.1 or 1.0.1?) I haven't yet had a chance to review the functor package now its in [lang] (I'm away from home on business ATM). ClassUtils, ArrayUtils and all of the reflect package should be excluded at present. A few other bugs have been sorted too. It would be good to see a list of changes from 1.0. IMHO, we should wait a week or so to allow more chance to look at functor, and then make a 1.1 release if its all OK. Stephen from:robert burrell donkin [EMAIL PROTECTED] date:Thu, 07 Nov 2002 20:08:09 to: [EMAIL PROTECTED] subject: Re: [Lang] Please fix this i feel very strongly that the code in reflect is not ready to be released. in particular, i would not like to see the current method names and structure become fixed by future requirements for backwards compatibility (just) yet. (gorden bennett! i've only made one commit and i'm already sounding like i own the shop ;) - robert On Thursday, November 7, 2002, at 07:15 PM, Steve Downey wrote: I agree that CVS head is not in a releaseable state. But the bug is fairly compelling. I think releasing off a branch from the release tag is the best solution. On Thursday 07 November 2002 12:05 pm, Henri Yandell wrote: Fixed in CVS, so will be in the nightly build tonight at the very least. And UnitTest made so Max and Min are being tested. Any views out there on the merits of a release? My judgement is that the current CVS tree is not releasable, so it would be a question of releasing against the tag. Any other bugs that should be included? Hen On Thu, 7 Nov 2002, [ISO-8859-1] Kasper Rönning wrote: Quite a bug in Commons-Lang: class NumberRange, method geMaximum() returns minimum. Could you make a new release? /Kasper Ronning -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache. org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache. org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [lang] [patch] Javadoc
Stephen Colebourne wrote:
Unfortunately its the patch format thats wrong (Eclipse doesn't like it).
See:
http://jakarta.apache.org/commons/patches.html
(I think its the -u you're missing)
You're right, I did miss the -u switch. Thats what happens when you try
to use an GUI-application... :)
Index: StringUtils.java
===
RCS file:
/home/cvspublic/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v
retrieving revision 1.22
diff -u -r1.22 StringUtils.java
--- StringUtils.java14 Nov 2002 22:29:25 - 1.22
+++ StringUtils.java15 Nov 2002 00:12:53 -
-1527,7 +1527,7
* Returns either the passed in Object as a String, or,
* if the Object is codenull/code, an empty String.
*
- * param str the Object to check
+ * param obj the Object to check
* return the passed in Object's toString, or blank if it was null
*/
public static String defaultString(Object obj) {
Index: ArrayUtils.java
===
RCS file:
/home/cvspublic/jakarta-commons/lang/src/java/org/apache/commons/lang/ArrayUtils.java,v
retrieving revision 1.2
diff -u -r1.2 ArrayUtils.java
--- ArrayUtils.java 14 Nov 2002 22:29:25 - 1.2
+++ ArrayUtils.java 15 Nov 2002 00:12:53 -
-397,7 +397,8
*
* param array1 the first array, may be codenull/code
* param array2 the second array, may be codenull/code
- * param true if length of arrays matches, treating codenull/code as an
empty array
+ * return codetrue/code if length of arrays matches, treating
+ * codenull/code as an empty array
*/
public static boolean isSameLength(Object[] array1, Object[] array2) {
if ((array1 == null array2 != null array2.length 0) ||
-415,8 +416,9
*
* param array1 the first array, may be codenull/code
* param array2 the second array, may be codenull/code
- * param true if length of arrays matches, treating codenull/code as an
empty array
- */
+ * return codetrue/code if length of arrays matches, treating
+ * codenull/code as an empty array
+ */
public static boolean isSameLength(long[] array1, long[] array2) {
if ((array1 == null array2 != null array2.length 0) ||
(array2 == null array1 != null array1.length 0) ||
-433,8 +435,9
*
* param array1 the first array, may be codenull/code
* param array2 the second array, may be codenull/code
- * param true if length of arrays matches, treating codenull/code as an
empty array
- */
+ * return codetrue/code if length of arrays matches, treating
+ * codenull/code as an empty array
+ */
public static boolean isSameLength(int[] array1, int[] array2) {
if ((array1 == null array2 != null array2.length 0) ||
(array2 == null array1 != null array1.length 0) ||
-451,8 +454,9
*
* param array1 the first array, may be codenull/code
* param array2 the second array, may be codenull/code
- * param true if length of arrays matches, treating codenull/code as an
empty array
- */
+ * return codetrue/code if length of arrays matches, treating
+ * codenull/code as an empty array
+ */
public static boolean isSameLength(short[] array1, short[] array2) {
if ((array1 == null array2 != null array2.length 0) ||
(array2 == null array1 != null array1.length 0) ||
-469,8 +473,9
*
* param array1 the first array, may be codenull/code
* param array2 the second array, may be codenull/code
- * param true if length of arrays matches, treating codenull/code as an
empty array
- */
+ * return codetrue/code if length of arrays matches, treating
+ * codenull/code as an empty array
+ */
public static boolean isSameLength(byte[] array1, byte[] array2) {
if ((array1 == null array2 != null array2.length 0) ||
(array2 == null array1 != null array1.length 0) ||
-487,8 +492,9
*
* param array1 the first array, may be codenull/code
* param array2 the second array, may be codenull/code
- * param true if length of arrays matches, treating codenull/code as an
empty array
- */
+ * return codetrue/code if length of arrays matches, treating
+ * codenull/code as an empty array
+ */
public static boolean isSameLength(double[] array1, double[] array2) {
if ((array1 == null array2 != null array2.length 0) ||
(array2 == null array1 != null array1.length 0) ||
-505,8 +511,9
*
* param array1 the first array, may be codenull/code
* param array2 the second array, may be codenull/code
- * param true if length of arrays matches, treating codenull/code as an
empty array
- */
+ * return codetrue/code
[lang] Fractions
I've taken a quick look, some comments:
- I would like to see Fraction be immutable
final
fields are private final
get methods
- I would like to see if else statements with {} brackets to conform with
our coding standards
- I would like to see an Apache licence and package, to confirm the code is
a donation
Otherwise they make sense as missing Java functionality. Would you like to
resubmit ;-)
Stephen
- Original Message -
From: [EMAIL PROTECTED]
Just looked through the Jade api and I see some related things in the
units package, but not seeing how to easily convert from say inches to
meters? Unless I'm missing something.
In any case, i've attached the Fraction and FractionFormat classes.
Original Message
From: [EMAIL PROTECTED]
Sent: 2002-11-14
To: [EMAIL PROTECTED]
Subject: Re: Conversion utilities
How does this relate to http://www.dautelle.com/jade/ ?
You may have covered similar ground. There are good concepts in here and
commons would seem to me to be a good ground for code like this.
I would suggest submitting the fraction classes to [lang] to begin with.
Stephen
from:[EMAIL PROTECTED]
I also have a package of conversion classes that convert different
measurements from imperial to metric and vice versa for things like Length,
Pressure, Force, etc.
And along with that I have a Fraction and FractionFormat class that
deals with fractions (parsing, formatting, etc).
Wonder if commons might be a good fit for that?
Travis Reeder
--
To unsubscribe, e-mail:
mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:commons-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail:
mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:commons-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail:
mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:commons-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang StringUtils.java ArrayUtils.java
scolebourne2002/11/14 16:25:45
Modified:lang/src/java/org/apache/commons/lang StringUtils.java
ArrayUtils.java
Log:
Javadoc fixes, from Fredrik Westermarck
Revision ChangesPath
1.24 +2 -2
jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java
Index: StringUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- StringUtils.java 15 Nov 2002 00:06:40 - 1.23
+++ StringUtils.java 15 Nov 2002 00:25:45 - 1.24
-1525,7 +1525,7
* Returns either the passed in Object as a String, or,
* if the Object is codenull/code, an empty String.
*
- * param str the Object to check
+ * param obj the Object to check
* return the passed in Object's toString, or blank if it was null
*/
public static String defaultString(Object obj) {
1.3 +26 -17
jakarta-commons/lang/src/java/org/apache/commons/lang/ArrayUtils.java
Index: ArrayUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/ArrayUtils.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ArrayUtils.java 14 Nov 2002 22:29:25 - 1.2
+++ ArrayUtils.java 15 Nov 2002 00:25:45 - 1.3
-64,6 +64,7
*
* author a href=mailto:scolebourne;apache.orgStephen Colebourne/a
* author Moritz Petersen
+ * author a href=mailto:fredrik;westermarck.comFredrik Westermarck/a
* version $Id$
*/
public class ArrayUtils {
-397,7 +398,8
*
* param array1 the first array, may be codenull/code
* param array2 the second array, may be codenull/code
- * param true if length of arrays matches, treating codenull/code as an
empty array
+ * return codetrue/code if length of arrays matches, treating
+ * codenull/code as an empty array
*/
public static boolean isSameLength(Object[] array1, Object[] array2) {
if ((array1 == null array2 != null array2.length 0) ||
-415,8 +417,9
*
* param array1 the first array, may be codenull/code
* param array2 the second array, may be codenull/code
- * param true if length of arrays matches, treating codenull/code as an
empty array
- */
+ * return codetrue/code if length of arrays matches, treating
+ * codenull/code as an empty array
+ */
public static boolean isSameLength(long[] array1, long[] array2) {
if ((array1 == null array2 != null array2.length 0) ||
(array2 == null array1 != null array1.length 0) ||
-433,8 +436,9
*
* param array1 the first array, may be codenull/code
* param array2 the second array, may be codenull/code
- * param true if length of arrays matches, treating codenull/code as an
empty array
- */
+ * return codetrue/code if length of arrays matches, treating
+ * codenull/code as an empty array
+ */
public static boolean isSameLength(int[] array1, int[] array2) {
if ((array1 == null array2 != null array2.length 0) ||
(array2 == null array1 != null array1.length 0) ||
-451,8 +455,9
*
* param array1 the first array, may be codenull/code
* param array2 the second array, may be codenull/code
- * param true if length of arrays matches, treating codenull/code as an
empty array
- */
+ * return codetrue/code if length of arrays matches, treating
+ * codenull/code as an empty array
+ */
public static boolean isSameLength(short[] array1, short[] array2) {
if ((array1 == null array2 != null array2.length 0) ||
(array2 == null array1 != null array1.length 0) ||
-469,8 +474,9
*
* param array1 the first array, may be codenull/code
* param array2 the second array, may be codenull/code
- * param true if length of arrays matches, treating codenull/code as an
empty array
- */
+ * return codetrue/code if length of arrays matches, treating
+ * codenull/code as an empty array
+ */
public static boolean isSameLength(byte[] array1, byte[] array2) {
if ((array1 == null array2 != null array2.length 0) ||
(array2 == null array1 != null array1.length 0) ||
-487,8 +493,9
*
* param array1 the first array, may be codenull/code
* param array2 the second array, may be codenull/code
- * param true if length of arrays matches, treating codenull/code as an
empty array
- */
+ * return
Re: [lang] [patch] Javadoc
Patch applied, thanks.
Stephen
- Original Message -
From: Fredrik Westermarck [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Friday, November 15, 2002 12:17 AM
Subject: Re: [lang] [patch] Javadoc
Stephen Colebourne wrote:
Unfortunately its the patch format thats wrong (Eclipse doesn't like
it).
See:
http://jakarta.apache.org/commons/patches.html
(I think its the -u you're missing)
You're right, I did miss the -u switch. Thats what happens when you try
to use an GUI-application... :)
Index: StringUtils.java
===
RCS file:
/home/cvspublic/jakarta-commons/lang/src/java/org/apache/commons/lang/String
Utils.java,v
retrieving revision 1.22
diff -u -r1.22 StringUtils.java
--- StringUtils.java 14 Nov 2002 22:29:25 - 1.22
+++ StringUtils.java 15 Nov 2002 00:12:53 -
@@ -1527,7 +1527,7 @@
* Returns either the passed in Object as a String, or,
* if the Object is codenull/code, an empty String.
*
- * @param str the Object to check
+ * @param obj the Object to check
* @return the passed in Object's toString, or blank if it was null
*/
public static String defaultString(Object obj) {
Index: ArrayUtils.java
===
RCS file:
/home/cvspublic/jakarta-commons/lang/src/java/org/apache/commons/lang/ArrayU
tils.java,v
retrieving revision 1.2
diff -u -r1.2 ArrayUtils.java
--- ArrayUtils.java 14 Nov 2002 22:29:25 - 1.2
+++ ArrayUtils.java 15 Nov 2002 00:12:53 -
@@ -397,7 +397,8 @@
*
* @param array1 the first array, may be codenull/code
* @param array2 the second array, may be codenull/code
- * @param true if length of arrays matches, treating
codenull/code as an empty array
+ * @return codetrue/code if length of arrays matches, treating
+ * codenull/code as an empty array
*/
public static boolean isSameLength(Object[] array1, Object[] array2)
{
if ((array1 == null array2 != null array2.length 0) ||
@@ -415,8 +416,9 @@
*
* @param array1 the first array, may be codenull/code
* @param array2 the second array, may be codenull/code
- * @param true if length of arrays matches, treating
codenull/code as an empty array
- */
+ * @return codetrue/code if length of arrays matches, treating
+ * codenull/code as an empty array
+ */
public static boolean isSameLength(long[] array1, long[] array2) {
if ((array1 == null array2 != null array2.length 0) ||
(array2 == null array1 != null array1.length 0) ||
@@ -433,8 +435,9 @@
*
* @param array1 the first array, may be codenull/code
* @param array2 the second array, may be codenull/code
- * @param true if length of arrays matches, treating
codenull/code as an empty array
- */
+ * @return codetrue/code if length of arrays matches, treating
+ * codenull/code as an empty array
+ */
public static boolean isSameLength(int[] array1, int[] array2) {
if ((array1 == null array2 != null array2.length 0) ||
(array2 == null array1 != null array1.length 0) ||
@@ -451,8 +454,9 @@
*
* @param array1 the first array, may be codenull/code
* @param array2 the second array, may be codenull/code
- * @param true if length of arrays matches, treating
codenull/code as an empty array
- */
+ * @return codetrue/code if length of arrays matches, treating
+ * codenull/code as an empty array
+ */
public static boolean isSameLength(short[] array1, short[] array2) {
if ((array1 == null array2 != null array2.length 0) ||
(array2 == null array1 != null array1.length 0) ||
@@ -469,8 +473,9 @@
*
* @param array1 the first array, may be codenull/code
* @param array2 the second array, may be codenull/code
- * @param true if length of arrays matches, treating
codenull/code as an empty array
- */
+ * @return codetrue/code if length of arrays matches, treating
+ * codenull/code as an empty array
+ */
public static boolean isSameLength(byte[] array1, byte[] array2) {
if ((array1 == null array2 != null array2.length 0) ||
(array2 == null array1 != null array1.length 0) ||
@@ -487,8 +492,9 @@
*
* @param array1 the first array, may be codenull/code
* @param array2 the second array, may be codenull/code
- * @param true if length of arrays matches, treating
codenull/code as an empty array
- */
+ * @return codetrue/code if length of arrays matches, treating
+ * codenull/code as an empty array
+ */
public static boolean isSameLength(double[] array1, double[]
cvs commit: jakarta-commons/validator .cvsignore
dion2002/11/14 16:33:10 Modified:validator .cvsignore Added: validator/xdocs .cvsignore Log: Add some ignored files Revision ChangesPath 1.1 jakarta-commons/validator/xdocs/.cvsignore Index: .cvsignore === stylesheets 1.2 +3 -1 jakarta-commons/validator/.cvsignore Index: .cvsignore === RCS file: /home/cvs/jakarta-commons/validator/.cvsignore,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- .cvsignore10 Jan 2002 07:01:32 - 1.1 +++ .cvsignore15 Nov 2002 00:33:10 - 1.2 -1,3 +1,5 build.properties build -dist \ No newline at end of file +dist +target +velocity.log -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
[validator] bug in javascript generation for regular expressions?
I think that this one is biting us:
Code snippet
} else if (Var.JSTYPE_REGEXP.equalsIgnoreCase(jsType)) {
results.append(
this.
+ varKey
+ =/
+ ValidatorUtil.replace(varValue, \\, )
+ /; );
/CodeSnippet
Since the javascript regexp starts with '/' shouldn't any embedded '/'s be
escaped?
I'll test it locally to see if it solves our problem and report back.
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: [lang] Dates/DateRanges [was Re: Re: Conversion utilities]
The Joda date support looks interesting (just took a brief glance, but I can see where it would be valuable). I'm wondering, though, if there is still not some place in [lang] for some basic utilities to help make the JDK Date and Calendar classes easlier to use. I'm thinking that this would be a filler for those who can't for whatever reason move over to using Joda. Unless of course you want to not make it easier for folks to not use Joda :) Having said that, though, I think we should try to limit the scope of date/calendar stuff in [lang]. We certainly don't want to reinvent a wheel that Joda would have already invented. Steven Caswell [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving One ring to rule them all, one ring to find them... -Original Message- From: Stephen Colebourne [mailto:scolebourne;btopenworld.com] Sent: Thursday, November 14, 2002 4:34 PM To: Jakarta Commons Developers List Subject: [lang] Dates/DateRanges [was Re: Re: Conversion utilities] blatant-self-advertising http://joda.sourceforge.net has code for handling TimePeriods and comparing dates (In fact its a complete rewrite of dates from the ground up). Only at 0.8 release though. /blatant-self-advertising This is my biggest concern with putting Date and Calendar code into [lang]. There is a lot that can be done to try to fix up the current Date/Calendar classes. But how much is worth it? Where do we in [lang] draw the line between useful methods, and the Joda complete rewrite? Stephen - Original Message - From: [EMAIL PROTECTED] The problem with the range interface when relating to dates is that with dates you would want to specify a field to give the range on, ex: days, months, weeks, etc. Travis Original Message From: Robert Leland [EMAIL PROTECTED] Sent: 2002-11-14 To: Jakarta Commons Developers List [EMAIL PROTECTED] Subject: Re: Conversion utilities Henri Yandell wrote: On Thu, 14 Nov 2002, Jeff Varszegi wrote: Janek, I made an interface called Range that is supported by classes called ComparableRange etc. The ComparableRange class can use any objects that support Comparable (or, alternately, any objects with a supplied Comparator), and I also made specific versions for Date and Double to Sounds like you could coordinating with the commons-validator package there is already a intRange(), floatRange(), in the GenerocValidator class. It could definately make use of your Range interface though ! -Rob -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [CLI] Options without short equivalent
Rob, I've checked in a fix for the second problem you were having, i.e. using getOptionValues( longOpt ). I've just seen your mail with the patch for the HelpFormatter stuff. I'll have a peek at this now and get back to you. -John K On Thursday, Nov 14, 2002, at 17:39 Europe/Dublin, Rob Oxspring wrote: 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 this while writing the email and doesn't really bother me at the moment (the svn up stuff was just an example and none of my options have hyphens in them). However I would have thought that long options wouldn't restrict such characters - is this a bug or is there a good reason for barfing on this? and if so shouldn't an IllegalArgumentException be thrown? An IllegalArgumentException should be thrown? I'll check this out too. H as I said - this was an aside that I noticed while documenting the other problems. As such it didn't have the same level of investigation: It turns out the long option of no-auth-cache actually parses fine, it looks like I was using the short option work around at the time, i.e. -no-auth-cache doesn't parse which seems pretty reasonable. Also, I was obviously not concentrating when seeing the parse failure because it does fail fast and the error message I was seeing was in fact part of an IAE stack trace. So after all, nothing a cup of coffee and a pair of glasses wouldn't fix ;-) I'm happy to work on patches to the above problems but wanted to check that I'm not being daft first - do others agree with my percieved bugs or should I be attacking things from another angle? And if i'm to code any patches then pointers on where to start would be good :) What XXXParser are you using BTW? You can have a go at the patches yourself if you like but I can get to them this evening. I was using Basic but on more detailed checks demonstrate that Gnu and Posix behave just the same - perfectly reasonably. Rob (crawling under a rock) -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org - - - - - - - - - - - - - - - - - - - - - - - Jakarta Commons CLI http://jakarta.apache.org/commons/cli -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Fwd: [CLI] Suggestions
I've just been writing my own Command Line Parsing library, when duh! I
looked to see what was out there, and came across commons-cli.
Its quite interesting to see the similarities between my implementation
and commons-cli
I have an Options type class as my main entry point, and posix
support (my library is built on top of the gnu-getopt package),
automatic generation of usage statements, command line parsing, and and
a similar usage pattern of create/parse/query.
Generally, the CLI implementation is neater and tidier.
However, my class has a number of features that CLI doesn't seem to
have (after a browse through the archives, I found that some of these
were anticipated by David below). Some of these might be there in CLI,
but I didn't see them after a brief perusal of the docs ...
1. Options are typed (boolean, string, integer, double), with the type
being determined by the type of a default value that is passed in
during construction. This means that there are a *lot* of constructors,
as everything is heavily overloaded. From the user (developer)
perspective, if you pass the right kind of object in as a default, then
the library will do all the work (including checking the values
supplied on the command line). I saw what looked to be type support in
CLI, but it didn't seem very obvious how to use it.
3. Options can have a long name and no short name (flag). This is handy
for when you have a lot of parameters, and run out of suitable short
names.
3. Sets of options can be read from and written to properties files.
4. A set of default options is provided (disabled by default) that will
read properties files during parsing, and write them once parsing is
completed.
For example:
mycommand --properies-file in.properties --some-other-argument
some_value --write-properties-file out.properties
reads option values from in.properties, over-rides the value for
--some-other-argument, and dumps the properties out to out.properties.
The special property options names and flags can be fully customised
via method calls.
5. During interrogation, option values are retrieved via booleanValue,
stringValue, etc. calls. These are type-safe, in that trying to
retrieve a boolean value from an integer option will throw a
runtime-exception, which will be thrown the first time that the program
is run
(assuming, reasonably that you go through a create/parse/query phase
early in program initialisation).
I am pretty sure that most of this functionality could be added to CLI
without breaking the existing interfaces, and may be useful for some
people (not requiring a flag for each option, simple typing, and the
properties file functionality has been very handy for me).
If anyone is interested in this, mail me directly for further info. I'd
be happy to write patches if people think its a good idea.
cheers,
Martin
Date: Sat, 05 Jan 2002 20:05:40 -0500
From: David Dixon-Peugh [EMAIL PROTECTED]
Subject: [cli] Suggestions
Content-Type: text/plain; charset=us-ascii; format=flowed
I've been fooling with the CLI package in the
Sandbox, and I've got a few suggestions on how
it might be improved.
#1 - Usage Statement
Since we are setting up the Options class with
all the option possibilites and their descriptions,
it seems a logical place to generate a Usage
statement.
#2 - Default Values on Options
It seems that the default values are known when
the options are created. It makes sense to set
the defaults when the Options object is created.
#3 - Integrate with Properties Object
It would be nice, if I could write something like
this:
public static void main(String args[]) {
Options opt = new QuiltOptions(quilt.properties);
try {
Properties prop = opt.parse( args );
} catch (MissingArgumentException e) {
System.err.println( opt.getUsageStatement() );
System.exit( -1 );
}
}
What do you think? I think it makes the code look
an awful lot cleaner than the way it works now.
Thanks,
DDP
--
To unsubscribe, e-mail:
mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:commons-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
[collections][SUBMIT] Queue (A double-ended thread-safe queue)
It has been suggested that I make this class implement the Buffer interface, so I will look into that at the first opportunity (tomorrow). This is a queue that can satisfy requests from multiple threads, delivering output to them in the proper order. It is double-ended, and supports blocking (indefinitely and for a specified number of milliseconds). It supports removal and peeking at entries. Javadoc is included, so take a look at that for a full explanation if you're interested. The internal mechanism is a doubly-linked list. All threads that block go into a separate internal doubly-linked list. Nodes of both types (to hold elements and waiting threads) are created anew only if there are none in the internal cache. I didn't use LinkedList inside the class because it is wasteful. In the end, it looks like this class is less than twice as slow as LinkedList, even though it is heavily synchronized. To avoid method-call overhead, method calls are flat-- only one deep. The only exceptions to this are convenience methods for using the queue as a single-ended queue; for instance, the remove() method calls removeFirst(). There are lots of comments inside the methods to explain what's going on. Please check the code for correctness and performance if you have a chance, and let me know any thoughts you may have. Jeff __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com Queue.java Description: Queuejava -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [cli] Suggestions
Hi Martin,
I've just been writing my own Command Line Parsing library, when duh!
I looked to see what was out there, and came across commons-cli.
Its quite interesting to see the similarities between my
implementation and commons-cli
I have an Options type class as my main entry point, and posix
support (my library is built on top of the gnu-getopt package),
automatic generation of usage statements, command line parsing, and
and a similar usage pattern of create/parse/query.
Generally, the CLI implementation is neater and tidier.
However, my class has a number of features that CLI doesn't seem to
have (after a browse through the archives, I found that some of these
were anticipated by David below).
1. Options are typed (boolean, string, integer, double), with the type
being determined by the type of a default value that is passed in
during construction. This means that there are a *lot* of
constructors, as everything is heavily overloaded. From the user
(developer) perspective, if you pass the right kind of object in as a
default, then the library will do all the work (including checking the
values supplied on the command line). I saw what looked to be type
support in CLI, but it didn't seem very obvious how to use it.
Check out this unit test which shows how to use typed options:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/cli/src/test/org/
apache/commons/cli/PatternOptionBuilderTest.java?rev=1.6content-
type=text/vnd.viewcvs-markup
2. Options can have a long name and no short name (flag). This is
handy for when you have a lot of parameters, and run out of suitable
short names.
This is possible in CLI, e.g. OptionBuilder.withLongOpt( username
).hasArg().create().
3. Sets of options can be read from and written to properties files.
No support for this. I have a TODO for myself (I must document it) to
have an XML reader and writer for configuring an Options instance. I
will document this TODO and also add yours. If you feel like having a
bash at the properties one that would be cool ;)
4. A set of default options is provided (disabled by default) that
will read properties files during parsing, and write them once parsing
is completed.
For example:
mycommand --properies-file in.properties --some-other-argument
some_value --write-properties-file out.properties
reads option values from in.properties, over-rides the value for
--some-other-argument, and dumps the properties out to out.properties.
The special property options names and flags can be fully customised
via method calls.
Might be that I'm a bit sleepy but I don't see what this achieves. Can
you
enlighten me please.
5. During interrogation, option values are retrieved via booleanValue,
stringValue, etc. calls. These are type-safe, in that trying to
retrieve a boolean value from an integer option will throw a
runtime-exception, which will be thrown the first time that the
program is run
(assuming, reasonably that you go through a create/parse/query phase
early in program initialisation).
The TypeHandler class does provide support for this at the interrogation
stage. Have a look at it and tell me if there is anything you think is
missing.
I am pretty sure that most of this functionality could be added to CLI
without breaking the existing interfaces, and may be useful for some
people (not requiring a flag for each option, simple typing, and the
properties file functionality has been very handy for me).
If anyone is interested in this, mail me directly for further info.
I'd be happy to write patches if people think its a good idea.
I'm glad you found CLI Martin, saves creating another package ;) Let
me know if you
have any other queries/comments.
BTW, this is the first time I have seen Davids mail as well.
-John K
cheers,
Martin
Date: Sat, 05 Jan 2002 20:05:40 -0500
From: David Dixon-Peugh [EMAIL PROTECTED]
Subject: [cli] Suggestions
Content-Type: text/plain; charset=us-ascii; format=flowed
I've been fooling with the CLI package in the
Sandbox, and I've got a few suggestions on how
it might be improved.
#1 - Usage Statement
Since we are setting up the Options class with
all the option possibilites and their descriptions,
it seems a logical place to generate a Usage
statement.
#2 - Default Values on Options
It seems that the default values are known when
the options are created. It makes sense to set
the defaults when the Options object is created.
#3 - Integrate with Properties Object
It would be nice, if I could write something like
this:
public static void main(String args[]) {
Options opt = new QuiltOptions(quilt.properties);
try {
Properties prop = opt.parse( args );
} catch (MissingArgumentException e) {
System.err.println( opt.getUsageStatement() );
System.exit( -1 );
}
}
What do you think? I think it makes the code look
an awful lot cleaner than the way it works now.
Thanks,
Re: [cli] Suggestions
Hi John,
thanks for your reply,
Check out this unit test which shows how to use typed options:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/cli/src/test/org/
apache/commons/cli/PatternOptionBuilderTest.java?rev=1.6content-
type=text/vnd.viewcvs-markup
2. Options can have a long name and no short name (flag). This is
handy for when you have a lot of parameters, and run out of suitable
short names.
This is possible in CLI, e.g. OptionBuilder.withLongOpt( username
).hasArg().create().
It seems quite awkward (IMHO) to chain together all of those method
calls. I got round this with method overloading.
I have a *lot* of constructors/factory methods in my lib, but there is
a simple set of rules that lets you determine what to write, so that
constructors work in a very concise, DWIM (do what I mean) fashion.
My base constructor is
/**
* param name The long name for the option.
* param flag The flag for the option.
* param argument A constant value indicating whether an argument is
not allowed/optional/required
* param defaultValue An object containing the default value
* param type A constant value indicating the type (boolean, string,
int or double) of the object
* param argName A string to use for the argument in usage messages
(e.g., filename).
* param description A description of the option.
*/
Option(String name, char flag, int argument, Object defaultValue, int
type, String argName, String description);
The rules for other constructors.
An option must have a name and/or a flag.
argument is optional (for boolean options, there is no argument,
otherwise required argument is assumed)
defaultValue/type are replaced by a single boolean, String, int or
double value, which indicates the default value and the type of the
option.
argName and description are optional.
That generates a lot of constructors in the library (I think I could
make argName optional as well---right now you either have to have
argName and description as well, or neither---which would add a lot
more constructors).
However, the constructors are pretty unambiguous to the end-user, so
the library ends up being very easy to use. For example, see the code
below.
CommandLineOptions options = new CommandLineOptions();
try{
options.addCommandLineOption(url, 'u', DEFAULT_URL_STRING);
options.addCommandLineOption(method, 'm', );
options.addCommandLineOption(secure, 's', false);
options.addCommandLineOption(help, 'h', false);
int lastArg = options.parseCommandLine(TestClient, args);
url = options.stringValue(url);
method = options.stringValue(method);
secure = options.booleanValue(secure);
if(options.booleanValue(help)) options.printUsage(System.out);
}
catch(CommandLineOptionException e){
e.printStackTrace();
}
I don't know whether any scheme like this could be added to CLI at this
point, but I think it makes things a lot more friendly for the end-user.
3. Sets of options can be read from and written to properties files.
No support for this. I have a TODO for myself (I must document it) to
have an XML reader and writer for configuring an Options instance. I
will document this TODO and also add yours. If you feel like having a
bash at the properties one that would be cool ;)
Maybe early next week. I should be able to port mine across pretty
easily.
4. A set of default options is provided (disabled by default) that
will read properties files during parsing, and write them once
parsing is completed.
For example:
mycommand --properies-file in.properties --some-other-argument
some_value --write-properties-file out.properties
reads option values from in.properties, over-rides the value for
--some-other-argument, and dumps the properties out to out.properties.
The special property options names and flags can be fully
customised via method calls.
Might be that I'm a bit sleepy but I don't see what this achieves.
Can you
enlighten me please.
sure.
imagine my code looks like
options = myCreateOptions();
options.setUsePropertiesOptions(true);
options.parseCommandLine(mycommand, args);
interrogateOptions(options);
Calling setUsePropertiesOptions with a true argument means that in
addition to the options that I defined, my commandline parsing will
also support a predefined set of options relating to properties, which
support reading option values in from a properties file, and writing
options out to a properties file, and specifying a prefix to add
to/subtract from property names.
This can be very useful if you have a *lot* of command-line options. I
have some simulation apps that run like this. Of course one could argue
that if you have so many options, you should be using a properties file
or some other mechanism anyway, but this approach lets you have the
best of both worlds ... specification of options in a properties file,
over-rideable from the command line.
so, for example
runApp
Re: [collections] Pleasedtameetcha, and a couple of questions
SkipList??? ftp://ftp.cs.umd.edu/pub/skipLists/skiplists.pdf There is other interesting information on William Pugh's website, including a paper on why the double-checked-locking idiom for lazy initialization doesn't work in Java. Jeff __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: [DBUtils] Introduction and some thoughts
Anybody looked at www.crossdb.com ? Travis Original Message From: Mike Bryant [EMAIL PROTECTED] Sent: 2002-11-14 To: [EMAIL PROTECTED] Subject: [DBUtils] Introduction and some thoughts Hello all, My name is Mike Bryant. I just wanted to send an email to introduce myself and say that I am excited about the DBUtils package. I've spent a good bit of time at my current job writing database utility code, a package like this could have really saved some time. The code so far looks great I think. I am especially impressed with the EnhancedResultSet class and the DbUtils.resultSetToArray method. Some thoughts I have on this package: - Data class (ColumnData) to hold a DB field's data. This might contain data like column index, data type, column name, value. - Method (similar to DbUtils.resultSetToArray method) that would build a List (or maybe Map) of ColumnData objects. This might be useful if users need more information than the resultSetToArray method provides. - Method to take a SQL stmt as a param, execute it, build a List of ColumnData objects (or a List of Strings), representing a vertical list of column data. An example of this would be to use a stmt like 'select user_name from users' to get a List of all users. Anyway, those are some general thoughts. I look forward to (hopefully) spending alot of time with this. Thanks Mike Bryant ([EMAIL PROTECTED]) -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [cli] Suggestions
Hi John, On Thursday, November 14, 2002, at 11:47 PM, John Keyes wrote: 3. Sets of options can be read from and written to properties files. No support for this. I have a TODO for myself (I must document it) to have an XML reader and writer for configuring an Options instance. I will document this TODO and also add yours. If you feel like having a bash at the properties one that would be cool ;) rereading your comment, I see that for XML, you're talking about configuring an options instance. I didn't make myself very clear, but I was talking (as was David, I think) about taking an Options instance, and a Properties object, and producing a CommandLine object or equivalent, so it would be more like a Parser object, except that that interface wouldn't be quite suitable. The appropriate prototype would be more like: public CommandLine parse(Options opts, Properties properties, boolean stopAtNonOption) or maybe public CommandLine parse(Options opts, Properties properties) or even public CommandLine parse(Options opts, Properties properties, Prefix prefix) (where prefix is a prefix that gets stripped off the inbound properties, so that you can embed relevant properties in a general properties file without fear of naming collisions). If that sounds useful, let me know, and I'll have a bash at it ... Returning to my previous reply, it would also be useful (IMHO, naturally) to be able to take this CommandLine object, and over-ride its settings via an actual command line, but I can't see any way to do that gracefully in CLI ... -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: [DBUtils] Introduction and some thoughts
Nope. Looks good, Apache licence too so it's usable. Why am I not surprised that Strachan is on it :) He gets everywhere. My rule of thumb is becoming: it's not an open source Java project if Strachan's not on it. [Damn, hurry up and join DbUtils James]. I'll try to learn more about it so that DbUtils doesn't grow in that direction, which a couple of Mike's suggestions concering the ColumnData might be getting towards (?). Assuming you're the Travis who's heading up crossdb.com, what do you think? Is DbUtils redundant? Can you see a clear separation of concern? Are there any things you think would go well there. The reason why I think there's not a cross-pupose: I'm not an amazing Db coder or anything, I do bits etc. When I look around at all the libraries to help me with DBs, they all involve me having to get religious about them, OO-db's, ObjectBridge, Castor/JDO, CrossDB[I think]. I like getting religious about things, but it's expensive to do properly [in time], so when I haven't got that time I like to just make the boring old religion that little bit easier. One of the issues I believe DbUtils has to watch for is introducing any religion. So, if someone _has_ to use a framework to get the power, then we're starting to compete with the other projects and not fitting the currently empty niche. Idea is just to make JDBC(tm) easier. Currently I'm wrestling with a DbPoller. It's a simple piece of code which polls the db to notify something when that table changes. Issues being: 1) I introduce a PKey class to hold a column-data info. Basically akin to Mike's suggestion. Is this a framework yet? 2) DB-specific. Oracle has some irritating bugs with jdbc and I extend DbPoller to get OracleDbPoller. This provides some issues for building, but I'm sure they can easily be fixed. More importantly, should DbUtils fill up with lots of DB-specific extensions [or in a side repository anyway]. Another idea is GUID/Sequencers. Would be nice to have a Sequencer interface and then I make an OracleSequencer which uses a select on nextval etc, or a MySql sequencer with last_insert_id. Issues being, how do I enforce the last transaction there? There'd also be java-level random-number Sequencers, which would use the sequence-id code from Patterns sandbox, or other ideas. Is this getting towards a framework? Thoughts? Hen On Thu, 14 Nov 2002 [EMAIL PROTECTED] wrote: Anybody looked at www.crossdb.com ? Travis Original Message From: Mike Bryant [EMAIL PROTECTED] Sent: 2002-11-14 To: [EMAIL PROTECTED] Subject: [DBUtils] Introduction and some thoughts Hello all, My name is Mike Bryant. I just wanted to send an email to introduce myself and say that I am excited about the DBUtils package. I've spent a good bit of time at my current job writing database utility code, a package like this could have really saved some time. The code so far looks great I think. I am especially impressed with the EnhancedResultSet class and the DbUtils.resultSetToArray method. Some thoughts I have on this package: - Data class (ColumnData) to hold a DB field's data. This might contain data like column index, data type, column name, value. - Method (similar to DbUtils.resultSetToArray method) that would build a List (or maybe Map) of ColumnData objects. This might be useful if users need more information than the resultSetToArray method provides. - Method to take a SQL stmt as a param, execute it, build a List of ColumnData objects (or a List of Strings), representing a vertical list of column data. An example of this would be to use a stmt like 'select user_name from users' to get a List of all users. Anyway, those are some general thoughts. I look forward to (hopefully) spending alot of time with this. Thanks Mike Bryant ([EMAIL PROTECTED]) -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [collections][SUBMIT] XMLProperties (a Properties-like class)
It's a good idea Jeff, and the xml.commons people may be interested, though they don't tend to view Commons in quite that way, but: import javax.xml.*; import javax.xml.parsers.*; import javax.xml.transform.*; import org.w3c.dom.*; import org.xml.sax.*; import org.apache.xpath.*; import org.w3c.dom.*; import org.xml.sax.*; is why I don't think it should go in Collections. My tuppence, Hen On Thu, 14 Nov 2002, Jeff Varszegi wrote: An implementation of a Properties-like utility class that can store and retrieve different data types, can store comments for properties, and stores/loads data using XML. If you think it is useful, feel free to use it. Jeff __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [cli] Suggestions
On Fri, 15 Nov 2002, Martin Redington wrote: Hi John, 5. During interrogation, option values are retrieved via booleanValue, stringValue, etc. calls. These are type-safe, in that trying to retrieve a boolean value from an integer option will throw a runtime-exception, which will be thrown the first time that the program is run (assuming, reasonably that you go through a create/parse/query phase early in program initialisation). The TypeHandler class does provide support for this at the interrogation stage. Have a look at it and tell me if there is anything you think is missing. I'll check it out ... I was in the same position as yourself a while back. I had my own library and wanted to dump it for CLI but CLI lacked this feature. I wanted to do: flags = a:bc%d/ which means d is a File, c a Number, c a boolean and a a String. PatternOptionsBuilder does this and uses TypeHandler to do its dumbie conversions. BeanUtils has a converter package that realy should become more highprofile and CLI would use this for its conversion. I think :) It's been way down on my todo lists :( Hen -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [GUMP] Build Failure - krysalis-ruper
David Bernard wrote: The purpose of gump is to get all cvs HEAD to compile against each other. Although you can specify supplied. The perfered method is to get it to work against the HEAD. I know this (it's what I dislike Gump approach). The purpose of Gump is to get people talking. If you depend on something that is supported commons-cli 1.0, then it would be nice if cli were to preserve these interfaces for at least one release, possibly deprecating them. It is a lot easier to have this discussion before CLI has it's next release (without the support that you need) than after. http://cvs.apache.org/builds/gump/2002-11-14/krysalis-ruper.html - Sam Ruby -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [validator] bug in javascript generation for regular expressions?
Sorry, this is a struts 1.1 issue
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
[EMAIL PROTECTED] wrote on 15/11/2002 12:10:30 PM:
I think that this one is biting us:
Code snippet
} else if (Var.JSTYPE_REGEXP.equalsIgnoreCase(jsType)) {
results.append(
this.
+ varKey
+ =/
+ ValidatorUtil.replace(varValue, \\, )
+ /; );
/CodeSnippet
Since the javascript regexp starts with '/' shouldn't any embedded '/'s
be
escaped?
I'll test it locally to see if it solves our problem and report back.
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
--
To unsubscribe, e-mail:
mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:commons-dev-help;jakarta.apache.org
ForwardSourceID:NT0008ED16
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
