Re: [lang] Clover coverage report for Lang 2.0

http://www.thecortex.net/clover/index.html is the clover homepage btw. It used to integrate into Maven, so I assume it still does. I'm not sure what the ? marks in the margin mean. I guess that it can't test them. Hen On Wed, 30 Jul 2003, Henri Yandell wrote: > > I've been wanting to play with

[lang] Clover coverage report for Lang 2.0

I've been wanting to play with Clover, so took the time out to figure it out a little and run it on Lang. I generated the HTML report [there's a PDF, XML and a GUI as well] which is available at: http://www.flamefew.net/~hen/lang/clover_html/ Clover seems like a pretty good tool to show us which

RE: [lang] So, about that 2.0....

Apart from a few bug numbers [mostly javadoc, but I figured I'd list them], not much else to change in the release notes. Thanks Stephen for keeping them up to date with changes. Lots of javadoc improvement done over the last 2 weeks. Impressive. Hen On Tue, 29 Jul 2003, Henri Yandell wrote: >

cvs commit: jakarta-commons/lang RELEASE-NOTES.txt

bayard 2003/07/29 20:30:58 Modified:lang RELEASE-NOTES.txt Log: Backed the 1.0.1 out. Maybe it doesn't make sense. Revision ChangesPath 1.17 +2 -2 jakarta-commons/lang/RELEASE-NOTES.txt Index: RELEASE-NOTES.txt ===

cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateIntRange.js

rleland 2003/07/29 20:28:55 Modified:validator/src/javascript/org/apache/commons/validator/javascript validateIntRange.js Log: Bug 21751 report and patch provided by Kurt Post Allow intRange validation of select-one and radio fields. In Kurt's words: In

cvs commit: jakarta-commons/lang RELEASE-NOTES.txt

bayard 2003/07/29 20:21:43 Modified:lang RELEASE-NOTES.txt Log: Added in the bugs fixed in the last few weeks. Changed comment to say that these are the changes since 1.0.1. Revision ChangesPath 1.16 +10 -2 jakarta-commons/lang/RELEASE-NOTES.txt Index

DO NOT REPLY [Bug 19030] - [lang] EnumTest fails on Linux Sun JDK 1.3.0

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

[lang] IntHashMap

I thought this was meant to have package scope? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: [io][vote] FileUtils: decision on style

If others can't deal with private constructors, then I guess there isn't a choice. But in theory, I think protected constructors would be the best since they would allow the constructor to be accessible to subclasses, if necessary. On Tue, 2003-07-29 at 05:53, Jeremias Maerki wrote: > On 29.

[collections] NotifyingCollections - capturing rich non-uniform data

[stephen] > My goals for [collections] is to add something small and simple that doesn't prevent a user adding something more complex. [michael] > I think I would prefer multiple listener interfaces and a simple event to a single listener interface and either a hierarchy of event classes or a type

RE: [io][vote] FileUtils: decision on style

--- Neil O'Toole <[EMAIL PROTECTED]> wrote: > > At first glance I don't really see the `need to override > > behavior' > > argument -- if a user doesn't like the way a static method is > > implemented, can't they just implement their own in a separate class? > > > > Absolutely. I don't see any re

RE: [lang] commons-lang-2.0-rc1 ready for complaints

Fixed. The commons-lang-1.x also had them :) On Tue, 15 Jul 2003, Gary Gregory wrote: > The file commons-lang-2.0-rc1.jar contains overview.html and all of the > package.html files, which it should not. > > Gary > > -Original Message- > From: Phil Steitz [mailto:[EMAIL PROTECTED] > Sent:

cvs commit: jakarta-commons/lang build.xml

bayard 2003/07/29 18:32:09 Modified:lang build.xml Log: Changed so it stops putting .html files into the jar file. Revision ChangesPath 1.17 +2 -2 jakarta-commons/lang/build.xml Index: build.xml ===

Re: [lang] bulding under linux 1.2.2

If Lang itself did not build under 1.2, I'd think it is bad. I don't think we can trust a Lang that builds under 1.4 to necessarily work on all platforms. Currently the tests use the classes to build. Probably they should run against the built jar so a 1.2 built jar can be tested comfortably unde

Re: [lang] bulding under linux 1.2.2

I ran into this same problem, but did not mention it since I thought that the expectation was that the code built on 1.4 would *run* on 1.2+ The tests that I have been doing with 1.3 and 1.2 have used code and tests compiled using 1.4. Am I testing the wrong way? What exactly does it mean in Statu

Re: [lang] bulding under linux 1.2.2

Ah, it seems that when you call the getEnum method and provide the class, it only finds Enums of that class and not an extension of it. Which, looking at the code makes sense. Anonymous extensions do still work as $1.. etc gets stripped off. So, one solution is to declare explicit classes with i

[lang] bulding under linux 1.2.2

Just downloaded the 1.2.2 to my new linux dev-server. Up until now I've been building under 1.3 and 1.4. src/test/org/apache/commons/lang/enum/OperationEnum.java does not build under 1.2.2/Linux due to: [javac] /home/hen/jakarta/branch2.0/jakarta-commons/lang/src/test/org/apache/commons/lang

Re: [lang] DEVELOPERS-GUIDE.html

On Tue, 29 Jul 2003, Stephen Colebourne wrote: > Date: Tue, 29 Jul 2003 23:50:35 +0100 > From: Stephen Colebourne <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > Subject: Re: [lang] DEVELOPERS-GUIDE.h

RE: [lang][io] final classes

I agree completely that backwards compatibility is important! Your earlier comment: "I plan to change that to extend StringUtils once 2.0 is released" led me to assume that Ustring does not currently extend StringUtils. If that is the case, I'm terribly confused as to how backward compatibilit

DO NOT REPLY [Bug 21952] - [lang] Improved tests, javadoc for CharSetUtils, StringEscapeUtils

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang CharSetUtilsTest.java StringEscapeUtilsTest.java

scolebourne2003/07/29 17:08:38 Modified:lang/src/java/org/apache/commons/lang CharSetUtils.java lang/src/test/org/apache/commons/lang CharSetUtilsTest.java StringEscapeUtilsTest.java Log: Javadoc fixes and improved tests bug 21952, from Phil S

cvs commit: jakarta-commons/lang default.properties

bayard 2003/07/29 17:06:45 Modified:lang default.properties Log: Updated version so that new builds will be rc2. Revision ChangesPath 1.14 +1 -1 jakarta-commons/lang/default.properties Index: default.properties ===

DO NOT REPLY [Bug 21904] - NumberUtils.createBigDecimal("") NPE in Sun 1.3.1_08

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 21904] - NumberUtils.createBigDecimal("") NPE in Sun 1.3.1_08

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

[lang][io] final classes

Please don't miss the point here! I have 30 developers, and many projects, all happily using the class UString. I don't want them to all have to change their code. (Its called backwards compatability) By subclassing, I add lots of new methods (that are in StringUtils, and not in UString) with

RE: [io][vote] FileUtils: decision on style

Well, the non-instantiatable doesn't necessarily hold in this case - the other point which was clarified was that utility classes should have public no arg constructors documented as for use only by tools (apparently many of the currently extant frameworks require bean semantics and so require a

RE: [lang] DEVELOPERS-GUIDE.html

So this saves one import for every user of Ustring that needs to use a function currently available in StringUtils? Not meaning to be sarcastic at all - it just seems that this is the only savings you get. Even the documentation lookup will probably have to go to the JavaDoc for StringUtils?

RE: [io][vote] FileUtils: decision on style

So I think I'd agree completely with you here I've run into this far too often myself to really make lots of use of static implementations of functionality. (I do use static methods to delegate to singletons that provide the actual functionality, and which can be replaced with subclasses o

Re: [lang] DEVELOPERS-GUIDE.html

;-) I'll have another look at the differences once 2.0 is out. After - Original Message - From: "Michael Heuer" <[EMAIL PROTECTED]> > Maybe we just try to convince the author(s) of UString to donate their > additional String-related static utility methods to the Jakarta Commons > project?

cvs commit: jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/schema/rules - New directory

hlship 2003/07/29 15:20:22 jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/schema/rules - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/schema/impl - New directory

hlship 2003/07/29 15:20:22 jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/schema/impl - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/schema - New directory

hlship 2003/07/29 15:20:21 jakarta-commons-sandbox/hivemind/src/java/org/apache/commons/hivemind/schema - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

RE: [io][vote] FileUtils: decision on style

> At first glance I don't really see the `need to override > behavior' > argument -- if a user doesn't like the way a static method is > implemented, can't they just implement their own in a separate class? > Absolutely. I don't see any reason why utility methods should be overridden. If a method

RE: [lang] DEVELOPERS-GUIDE.html

Maybe we just try to convince the author(s) of UString to donate their additional String-related static utility methods to the Jakarta Commons project? ;) Overriding utility classes just seems icky to me. michael On Tue, 29 Jul 2003, Henri Yandell wrote: > > However, the following would

RE: [lang] DEVELOPERS-GUIDE.html

However, the following would work: UString ustring = new UString("foo"); ustring.capitalise(); if UString had: ...extends StringUtils... public void capitalise() { this.myStr = capitalise(this.myStr); } Not sure why someone would bother though :) Just as easy to do StringUtils.capitalise

RE: [lang] DEVELOPERS-GUIDE.html

Ah, but not really... ;-) A subclass cannot override methods that are declared static in the superclass. In other words, a subclass cannot override a class method. A subclass can /hide/ a static method in the superclass by declaring a static method in the subclass with the same signature as the st

cvs commit: jakarta-commons/betwixt/xdocs overview.xml tasks.xml

rdonkin 2003/07/29 14:33:32 Modified:betwixt/src/test/org/apache/commons/betwixt TestBeanReader.java betwixt/xdocs overview.xml tasks.xml Log: Added unit tests for ConvertUtil string to object conversion in BeanUtils. Revision ChangesP

cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt PartyBean.java

rdonkin 2003/07/29 14:33:00 Added: betwixt/src/test/org/apache/commons/betwixt PartyBean.java Log: Bean used in new ConvertUtils test case Revision ChangesPath 1.1 jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/PartyBean.java Index: P

cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/io AbstractBeanWriter.java

rdonkin 2003/07/29 14:32:15 Modified:betwixt/src/java/org/apache/commons/betwixt/io AbstractBeanWriter.java Log: Added code that calls ConvertUtils to perform the conversion (so that this matches the bean reading). Revision ChangesPath 1.17 +

cvs commit: jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/expression MethodUpdater.java

rdonkin 2003/07/29 14:31:24 Modified:betwixt/src/java/org/apache/commons/betwixt/expression MethodUpdater.java Log: Added more logging. Revision ChangesPath 1.8 +8 -5 jakarta-commons/betwixt/src/java/org/apache/commons/betwixt/expressio

cvs commit: jakarta-commons/betwixt project.xml

rdonkin 2003/07/29 14:30:16 Modified:betwixt project.xml Log: Upgraded to latest beanutils release (fix a bug) Revision ChangesPath 1.28 +1 -1 jakarta-commons/betwixt/project.xml Index: project.xml

Re: [lang] DEVELOPERS-GUIDE.html

In this use case, everybody uses UString, so you can effectively override. If you code the same method in the 'subclass', and refer to it using the subclass class then it will be called. Stephen - Original Message - From: "Gary Gregory" <[EMAIL PROTECTED]> > When you do that, do remember

RE: [lang] DEVELOPERS-GUIDE.html

When you do that, do remember that you cannot override static methods in the same way that you can with instance methods. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 14:07 To: Jakarta Commons Developers List Subject: Re: [lang]

Re: [lang] DEVELOPERS-GUIDE.html

Because I want to create a subclass of StringUtils. Use case: I curently have a string utility class named UString. I plan to change that to extend StringUtils once 2.0 is released. (Because I'll get lots of extra methods for free) But I can only do that if StringUtils is not final. Stephen ---

Re: [jxpath] Selection Handler

Jason, Very interesting. I have been thinking about something like this myself. I was not actually thinking about databases, but rather about XML. I am sure Xalan and a bunch of other implementations of XPath do a much better job traversing DOM than JXPath. So, wouldn't it be great to hand the

Re: [Modeler][Vote] 1.1 Release Plan

+1 Craig On Tue, 29 Jul 2003, Davanum Srinivas wrote: > Date: Tue, 29 Jul 2003 06:25:06 -0700 (PDT) > From: Davanum Srinivas <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > S

RE: [io][vote] FileUtils: decision on style

--- Henri Yandell <[EMAIL PROTECTED]> wrote: > > > On Tue, 29 Jul 2003, David Graham wrote: > > > --- Arun Thomas <[EMAIL PROTECTED]> wrote: > > > Hmmm From the last three notes - I think I understand clearly > the > > > motivation for requiring the public no-arg constructor, but I still >

RE: [io][vote] FileUtils: decision on style

--- Michael Heuer <[EMAIL PROTECTED]> wrote: > On Tue, 29 Jul 2003, David Graham wrote: > > > --- Arun Thomas <[EMAIL PROTECTED]> wrote: > > > Hmmm From the last three notes - I think I understand clearly > the > > > motivation for requiring the public no-arg constructor, but I still > > > do

RE: [io][vote] FileUtils: decision on style

On Tue, 29 Jul 2003, David Graham wrote: > --- Arun Thomas <[EMAIL PROTECTED]> wrote: > > Hmmm From the last three notes - I think I understand clearly the > > motivation for requiring the public no-arg constructor, but I still > > don't understand the reasoning behind the need for avoiding f

RE: [io][vote] FileUtils: decision on style

On Tue, 29 Jul 2003, David Graham wrote: > --- Arun Thomas <[EMAIL PROTECTED]> wrote: > > Hmmm From the last three notes - I think I understand clearly the > > motivation for requiring the public no-arg constructor, but I still > > don't understand the reasoning behind the need for avoiding

RE: [io][vote] FileUtils: decision on style

--- Arun Thomas <[EMAIL PROTECTED]> wrote: > Hmmm From the last three notes - I think I understand clearly the > motivation for requiring the public no-arg constructor, but I still > don't understand the reasoning behind the need for avoiding final. The > only reason I can see (with possibly

cvs commit: jakarta-commons/net/src/java/org/apache/commons/net FingerClient.java

dfs 2003/07/29 11:59:08 Modified:net/src/java/org/apache/commons/net FingerClient.java Log: Mark Himsley reported a problem where the underlying socket, library classes, or native code was fragmenting a finger/whois query. Some whois servers don't wait for the second frag

RE: [io][vote] FileUtils: decision on style

Hmmm From the last three notes - I think I understand clearly the motivation for requiring the public no-arg constructor, but I still don't understand the reasoning behind the need for avoiding final. The only reason I can see (with possibly poor vision) is to allow access to the methods o

[Modeler][Vote] 1.1 Release Plan

Hi, I've put together a draft of the release plan for commons-modeler 1.1: http://cvs.apache.org/viewcvs/jakarta-commons/modeler/RELEASE-PLAN-1.1.t xt This should be about as straightforward as releases come: no bugs have been reported since the 1.1-M1 release, no issues are open in bugzilla. I j

Re: [lang] DEVELOPERS-GUIDE.html

Plus1 Stephen > from:Henri Yandell <[EMAIL PROTECTED]> > date:Tue, 29 Jul 2003 14:00:23 > to: [EMAIL PROTECTED] > subject: Re: [lang] DEVELOPERS-GUIDE.html > > > Just noticed that DEVELOPERS-GUIDE.html doesn't mention whether our > XxxUtils class should be final or not. I'm pret

cvs commit: jakarta-commons-sandbox/io/src/java/org/apache/commons/io FileUtils.java IOUtils.java HexDump.java EndianUtils.java

jeremias2003/07/29 06:07:39 Modified:io/src/java/org/apache/commons/io FileUtils.java IOUtils.java HexDump.java EndianUtils.java Log: Remove private constructors because of problems with Velocity which needs an instance (Christoph Reck) some todos. Rev

[lang] DEVELOPERS-GUIDE.html

Just noticed that DEVELOPERS-GUIDE.html doesn't mention whether our XxxUtils class should be final or not. I'm pretty sure we ended up making them not final. Anyone object to this before I add a line to the guide? Hen - To unsu

Re: [io] Filenames: String or java.io.File?

On Tue, 29 Jul 2003 [EMAIL PROTECTED] wrote: > [EMAIL PROTECTED] wrote: > >> from:__matthewHawthorne <[EMAIL PROTECTED]> > >>I think that finding a way to break out the String methods will make things > >>cleaner, FileUtils can just focus on Files, and the other classes can > >>also just foc

Re: [io][vote] FileUtils: decision on style

On Tue, 29 Jul 2003 [EMAIL PROTECTED] wrote: > Hey thanks for the heads up! > > being one of the original authors/contributor of this class, I do > have some comments (mostly in favour of your proposal)... > > 1rst: you seem to have added a private constructor to prevent > instantiation, which h

Re: [io][vote] FileUtils: decision on style

On 29.07.2003 10:20:00 Christoph.Reck wrote: > Hey thanks for the heads up! > > being one of the original authors/contributor of this class, I do > have some comments (mostly in favour of your proposal)... > > 1rst: you seem to have added a private constructor to prevent > instantiation, which h

[DIGESTER] Removed unnecessary local variable "debug"

This patch is against the DIGESTER_1_5 CVS tag. * src/java/org/apache/commons/digester/Digester.java resolveEntity(): Removed unnecessary local variable "debug". Index: Digester.java === RCS file: /home/cvs/jakarta-commons/digeste

Re: [lang] So, about that 2.0....

Stephen Colebourne wrote: From: "Phil Steitz" <[EMAIL PROTECTED]> I did discover one small wrinkle in the behavior of CharSetUtils.translate. When the repl string has positive length and the with string is "", an ArrayOutOfBoundsException is thrown. The patch does not change this, just documents

Re: [io] Filenames: String or java.io.File?

[EMAIL PROTECTED] wrote: from:__matthewHawthorne <[EMAIL PROTECTED]> I think that finding a way to break out the String methods will make things cleaner, FileUtils can just focus on Files, and the other classes can also just focus on one type. +1 from me for this point of view. The original

Re: [lang] So, about that 2.0....

From: "Phil Steitz" <[EMAIL PROTECTED]> > I did discover one > small wrinkle in the behavior of CharSetUtils.translate. When the repl > string has positive length and the with string is "", an > ArrayOutOfBoundsException is thrown. The patch does not change this, > just documents it. Sounds wron

Re: [io][vote] FileUtils: decision on style

Hey thanks for the heads up! being one of the original authors/contributor of this class, I do have some comments (mostly in favour of your proposal)... 1rst: you seem to have added a private constructor to prevent instantiation, which hurts usage as in velocity, where you need an instance of a cl

Re: [lang] So, about that 2.0....

Henri Yandell wrote: Actually I lie, I'm at Defcon this weekend so unless anyone has other thoughts I'll aim to get release-notes Tuesday, and an rc2 up for Thursday evening EST. Major problem with the last one from memory was the inclusion of javadoc in the jar. Will ensure the jar is nicer this t

DO NOT REPLY [Bug 21952] - [lang] Improved tests, javadoc for CharSetUtils, StringEscapeUtils

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 21952] New: - [lang] Improved tests, javadoc for CharSetUtils, StringEscapeUtils

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu