Re: [all] Policies concerning migration from sandbox
Bill Barker wrote: Mark R. Diggory [EMAIL PROTECTED] wrote in message Finally, remove the old cvs project directory from the sandbox: $rm -Rf /home/cvs/jakarta-commons-sandbox/foo Please review this process and provide any comments/thoughts, Mark I would do a cvs delete for the final step (for recovery only), but otherwise, you've got a +1 from the peanut-gallery. It's really annoying that the history for commons-daemon stops at the import point, so I can't (easily) go back and compare to prior versions when I have a problem with it. The downfall in this is that up to that point we've worked hard to migrate all the history that was in this original location to the new location. Doesn't this make saving the original history by cvs deletion now an unnecessary duplication? -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party libraries
--- Mark R. Diggory [EMAIL PROTECTED] wrote: I'm trying organize this thread a little bit more than was accomplished in the discussion. Thanks, Mark. Good job. 1.) Argument exists concerning the dependency requirements of Commons Math. To in fact be modular and easily integrated some discrepancy arises concerning interdependency with other commons components. The main question is; Are all these dependencies really required? a.) logging: It sounds like a good idea to make logging a runtime/compile time dependency on only the test cases and not the main +1 b.) Some discussion arises concerning some of the higher level interfaces and their dependencies on commons such as Discovery. We should review and grade if this Discovery pattern will really of true value in the places we've applied it (As opposed to just providing simple method of instantiation on these object directly...) +1 c.) j2sdk1.3.1 vs. j2sdk1.4.1: we are a project in a group dedicated to providing tools that can operate in Java Servlet/EBJ environments. Many vendors are still operating on 1.3.1. We have concerns as to our stuff working there. Thus we need to make sure we use only mechanisms supported on 1.3.1 for the time being (and then operate on a longer timescale to determine how facilitate usage of 1.4.1 in the future). I +1 2.) Server vs Application schools, I tend to think this is a Red Herring, this arises primarily by some great comments Eric made I also think that if we do a good job addressing points 1a and 1b above, the issue of requiring or having dependencies on too many other jars will be ameliorated by simply having reduced the number upon which math depends. Al __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/dbcp/xdocs index.xml
dirkv 2003/11/16 09:34:26 Modified:dbcp/xdocs index.xml Log: fix page title Revision ChangesPath 1.5 +1 -1 jakarta-commons/dbcp/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-commons/dbcp/xdocs/index.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- index.xml 29 Sep 2003 21:08:09 - 1.4 +++ index.xml 16 Nov 2003 17:34:26 - 1.5 @@ -3,7 +3,7 @@ document properties - titleDBCP/title + titleOverview/title author email=[EMAIL PROTECTED]Commons Documentation Team/author /properties - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/pool/xdocs index.xml
dirkv 2003/11/16 09:34:32 Modified:pool/xdocs index.xml Log: fix page title Revision ChangesPath 1.9 +2 -2 jakarta-commons/pool/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-commons/pool/xdocs/index.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- index.xml 25 Aug 2003 16:23:55 - 1.8 +++ index.xml 16 Nov 2003 17:34:32 - 1.9 @@ -1,7 +1,7 @@ ?xml version=1.0? document properties - titleHome/title + titleOverview/title author email=[EMAIL PROTECTED]Commons Documentation Team/author author email=[EMAIL PROTECTED]Rodney Waldhoff/author revision$Id$/revision - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/cache/xdocs - New directory
dirkv 2003/11/16 09:34:46 jakarta-commons-sandbox/cache/xdocs - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/cache/src/test/org/apache/commons/cache/adt TestListableObject.java TestWListableObject.java
dirkv 2003/11/16 09:42:21
Modified:cache/src/test/org/apache/commons/cache TestFileCache.java
TestFileDelete.java TestShareableFileStash.java
TestSimpleMemoryCache.java
cache/src/test/org/apache/commons/cache/adt
TestListableObject.java TestWListableObject.java
Log:
assert = assertTrue
import cleanup
Revision ChangesPath
1.2 +37 -34
jakarta-commons-sandbox/cache/src/test/org/apache/commons/cache/TestFileCache.java
Index: TestFileCache.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/cache/src/test/org/apache/commons/cache/TestFileCache.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TestFileCache.java18 May 2001 19:33:10 - 1.1
+++ TestFileCache.java16 Nov 2003 17:42:21 - 1.2
@@ -12,10 +12,13 @@
package org.apache.commons.cache;
-import junit.framework.*;
import java.io.File;
import java.io.Serializable;
+import junit.framework.Test;
+import junit.framework.TestCase;
+import junit.framework.TestSuite;
+
public class TestFileCache extends TestCase {
public TestFileCache(String testName) {
super(testName);
@@ -65,8 +68,8 @@
}
for(int i=0;i1500;i++) {
String key = this is the key + i;
- assert(object + i + should be storeable,cache.store(key,buf,new
Long(System.currentTimeMillis()+60L),null));
- assert(object + i + should be in the cache,cache.contains(key));
+ assertTrue(object + i + should be storeable,cache.store(key,buf,new
Long(System.currentTimeMillis()+60L),null));
+ assertTrue(object + i + should be in the cache,cache.contains(key));
}
System.out.println(NUM_RETRIEVE_FOUND: +
cache.getStat(CacheStat.NUM_RETRIEVE_FOUND));
System.out.println(NUM_RETRIEVE_NOT_FOUND: +
cache.getStat(CacheStat.NUM_RETRIEVE_NOT_FOUND));
@@ -102,22 +105,22 @@
Serializable key3 = key 3;
Serializable value3 = value 3;
- assert(!cache.contains(key1));
- assert(cache.store(key1,value1,null,null));
- assert(cache.contains(key1));
+ assertTrue(!cache.contains(key1));
+ assertTrue(cache.store(key1,value1,null,null));
+ assertTrue(cache.contains(key1));
assertEquals(value1,cache.retrieve(key1));
- assert(!cache.contains(key2));
- assert(cache.store(key2,value2,null,null));
- assert(cache.contains(key2));
+ assertTrue(!cache.contains(key2));
+ assertTrue(cache.store(key2,value2,null,null));
+ assertTrue(cache.contains(key2));
assertEquals(value2,cache.retrieve(key2));
- assert(!cache.contains(key3));
- assert(cache.store(key3,value3,null,null));
- assert(cache.contains(key3));
+ assertTrue(!cache.contains(key3));
+ assertTrue(cache.store(key3,value3,null,null));
+ assertTrue(cache.contains(key3));
assertEquals(value3,cache.retrieve(key3));
- assert(cache.contains(key1));
+ assertTrue(cache.contains(key1));
assertEquals(value1,cache.retrieve(key1));
}
@@ -129,34 +132,34 @@
Serializable key3 = key 3;
Serializable value3 = value 3;
- assert(!cache.contains(key1));
- assert(cache.store(key1,value1,null,null));
- assert(cache.contains(key1));
+ assertTrue(!cache.contains(key1));
+ assertTrue(cache.store(key1,value1,null,null));
+ assertTrue(cache.contains(key1));
assertEquals(value1,cache.retrieve(key1));
- assert(!cache.contains(key2));
- assert(cache.store(key2,value2,null,null));
- assert(cache.contains(key2));
+ assertTrue(!cache.contains(key2));
+ assertTrue(cache.store(key2,value2,null,null));
+ assertTrue(cache.contains(key2));
assertEquals(value2,cache.retrieve(key2));
- assert(!cache.contains(key3));
- assert(cache.store(key3,value3,null,null));
- assert(cache.contains(key3));
+ assertTrue(!cache.contains(key3));
+ assertTrue(cache.store(key3,value3,null,null));
+ assertTrue(cache.contains(key3));
assertEquals(value3,cache.retrieve(key3));
cache.clear(key1);
- assert(!cache.contains(key1));
- assert(cache.contains(key2));
- assert(cache.contains(key3));
+ assertTrue(!cache.contains(key1));
+ assertTrue(cache.contains(key2));
+ assertTrue(cache.contains(key3));
cache.clear(key2);
- assert(!cache.contains(key1));
- assert(!cache.contains(key2));
- assert(cache.contains(key3));
+ assertTrue(!cache.contains(key1));
+ assertTrue(!cache.contains(key2));
+
cvs commit: jakarta-commons-sandbox/cache/xdocs downloads.xml index.xml navigation.xml
dirkv 2003/11/16 09:43:29 Modified:cache.cvsignore Added: cacheLICENSE.txt checkstyle.xml project.properties project.xml cache/xdocs downloads.xml index.xml navigation.xml Log: maven project/site Revision ChangesPath 1.2 +7 -0 jakarta-commons-sandbox/cache/.cvsignore Index: .cvsignore === RCS file: /home/cvs/jakarta-commons-sandbox/cache/.cvsignore,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- .cvsignore18 May 2001 19:32:29 - 1.1 +++ .cvsignore16 Nov 2003 17:43:29 - 1.2 @@ -1,2 +1,9 @@ build.properties dist +.classpath +.project +.checkstyle +target +maven.log +velocity.log +eclipse_classes 1.1 jakarta-commons-sandbox/cache/LICENSE.txt Index: LICENSE.txt === /* * $Source: /home/cvs/jakarta-commons-sandbox/cache/LICENSE.txt,v $ * $Revision: 1.1 $ * $Date: 2003/11/16 17:43:29 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999-2003 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 acknowledgement: * This product includes software developed by the *Apache Software Foundation - http://www.apache.org/; *Alternately, this acknowledgement may appear in the software itself, *if and wherever such third-party acknowledgements 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 Software Foundation. * * 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/cache/checkstyle.xml Index: checkstyle.xml === ?xml version=1.0? !DOCTYPE module PUBLIC -//Puppy Crawl//DTD Check Configuration 1.1//EN http://www.puppycrawl.com/dtds/configuration_1_1.dtd; !-- Checkstyle checks configured for Maven. -- module name=Checker !-- Checks that a package.html file exists for each package. -- !-- See http://checkstyle.sf.net/config_javadoc.html#PackageHtml -- module name=PackageHtml/ !-- Checks whether files end with a new line.-- !-- See http://checkstyle.sf.net/config_misc.html#NewlineAtEndOfFile -- module name=NewlineAtEndOfFile/ !-- Checks that property files contain the same keys. -- !-- See http://checkstyle.sf.net/config_misc.html#Translation -- module name=Translation/ module name=TreeWalker property name=cacheFile
Re: [Configuration] Formatting of dom4j digester tag
Eric, I think you are right with that className attribute. I have only restored support for it (for in the actual implementation it was not even evaluated) because the examples in the overview.html all had a className attribute. And at this time this was the easiest possibility to include HierarchicalDOM4JConfiguration as a configuration source for ConfigurationFactory. From a user's point of view it is surely cleaner to have a separate XML element. Should I change the code in ConfigurationFactory to completely get rid off this attribute (in theory it can be set for all other elements as well, but this doesn't make much sense)? Which element name do you prefer? hierarchical, hierarchicalDom4j, hieraDom4j, ...? (I have always trouble with comming up with a meaningful name). Hey, I really would like to see commons configuration comming out of the sandbox! Oli Eric Pugh wrote: Oliver, I was looking through the docs, and the /examples.html was a great way to go! Something that kinda jumped out at me, having really looked at the examples is the case where we want to load up a HierarchicalDOM4JConfiguration: dom4j className=org.apache.commons.configuration.HierarchicalDOM4JConfiguration fileName=tables.xml/ It looks a little weird to have this optional attribute className. I am thinking that we should change instead to: dom4j fileName=gui.xml/ !--normal dom4j -- hierarchicalDom4j fileName=gui.xml/ !--heriarchical dom4j -- or hierarchical fileName=gui.xml/ !--heriarchical dom4j -- I am thinking that this might be a little cleaner.. do you foresee ever havign multiple classes providing the dom4j implementation? The className makes sense if we had 3 or more, but with just two, where the attribute is optional, it seems a little confusing.. any opinons? I am hoping to work towards getting the polish done on commons-configuration and then push for a move out of commons sandbox... Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Proposal - Subpackages
+1 on the package hierarchy. I especially agree with: 3) The distinction between a decorator and a non-decorator is too fine for me, and non-obvious to the user. I think I would support a move of the Observable classes to a separate project, but I feel that moves the release that much further away. It might move the release of [observablecollections] away, but it would definitely speed up the release of [collections] to separate them out. The observable collections work is significantly larger in conceptual scope than [primitives], lots of classes involved, there are many many ways to implement and extend this area, and there is still significant implementation work to be done, all of which argues for a separate subproject. I think it would be good to get all the rest of the [collections] code out there asap. I would see doing a separate release as the best way of achieving this. neil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party libraries
Al Chou wrote: a.) logging: It sounds like a good idea to make logging a runtime/compile time dependency on only the test cases and not the main +1 I don't really agree here. I do think it is very useful for any system to be able to raise a logging verbosity at any-time so that bugs and misunderstandings can be tracked. Depending on commons-logging really isn't much, or is it ?? (it's applet friendly btw!). Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap - New directory
scolebourne2003/11/16 12:35:32 jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap - New directory
scolebourne2003/11/16 12:35:32 jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/iterators TestUnmodifiableMapIterator.java
scolebourne2003/11/16 12:35:47 Modified:collections/src/test/org/apache/commons/collections TestAll.java TestAllPackages.java collections/data/test DualHashBidiMap.fullCollection.version3.obj DualHashBidiMap.emptyCollection.version3.obj collections/src/test/org/apache/commons/collections/iterators TestUnmodifiableMapIterator.java Added: collections/src/test/org/apache/commons/collections/bidimap AbstractTestSortedBidiMap.java TestDualTreeBidiMap.java TestDualHashBidiMap.java AbstractTestOrderedBidiMap.java TestTreeBidiMap.java TestAll.java AbstractTestBidiMap.java collections/src/java/org/apache/commons/collections/bidimap OrderedBidiMap.java AbstractDualBidiMap.java DualHashBidiMap.java SortedBidiMap.java DualTreeBidiMap.java package.html TreeBidiMap.java BidiMap.java collections/data/test DualTreeBidiMap.fullCollection.version3.obj DualTreeBidiMap.emptyCollection.version3.obj collections/src/java/org/apache/commons/collections/map OrderedMap.java Removed: collections/src/test/org/apache/commons/collections TestDualTreeBidiMap.java TestTreeBidiMap.java AbstractTestSortedBidiMap.java TestDualHashBidiMap.java AbstractTestBidiMap.java collections/src/java/org/apache/commons/collections TreeBidiMap.java AbstractDualBidiMap.java DualTreeBidiMap.java SortedBidiMap.java DualHashBidiMap.java BidiMap.java Log: Refactor bidimap to interface based subpackage Revision ChangesPath 1.1 jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/AbstractTestSortedBidiMap.java http://cvs.apache.org/viewcvs/jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/AbstractTestSortedBidiMap.java?rev=1.1 1.1 jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/TestDualTreeBidiMap.java http://cvs.apache.org/viewcvs/jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/TestDualTreeBidiMap.java?rev=1.1 1.1 jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/TestDualHashBidiMap.java http://cvs.apache.org/viewcvs/jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/TestDualHashBidiMap.java?rev=1.1 1.1 jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/AbstractTestOrderedBidiMap.java http://cvs.apache.org/viewcvs/jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/AbstractTestOrderedBidiMap.java?rev=1.1 1.1 jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/TestTreeBidiMap.java http://cvs.apache.org/viewcvs/jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/TestTreeBidiMap.java?rev=1.1 1.1 jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/TestAll.java http://cvs.apache.org/viewcvs/jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/TestAll.java?rev=1.1 1.1 jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/AbstractTestBidiMap.java http://cvs.apache.org/viewcvs/jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/AbstractTestBidiMap.java?rev=1.1 1.54 +2 -5 jakarta-commons/collections/src/test/org/apache/commons/collections/TestAll.java http://cvs.apache.org/viewcvs/jakarta-commons/collections/src/test/org/apache/commons/collections/TestAll.java.diff?r1=1.53r2=1.54 1.7 +3 -2 jakarta-commons/collections/src/test/org/apache/commons/collections/TestAllPackages.java http://cvs.apache.org/viewcvs/jakarta-commons/collections/src/test/org/apache/commons/collections/TestAllPackages.java.diff?r1=1.6r2=1.7 1.1 jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap/OrderedBidiMap.java http://cvs.apache.org/viewcvs/jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap/OrderedBidiMap.java?rev=1.1 1.1 jakarta-commons/collections/src/java/org/apache/commons/collections/bidimap/AbstractDualBidiMap.java
cvs commit: jakarta-commons incl_nav.xml
psteitz 2003/11/16 12:55:13 Modified:.incl_nav.xml Log: Changed lang menu item to point to maven site. Revision ChangesPath 1.7 +1 -1 jakarta-commons/incl_nav.xml Index: incl_nav.xml === RCS file: /home/cvs/jakarta-commons/incl_nav.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- incl_nav.xml 4 Nov 2003 14:42:11 - 1.6 +++ incl_nav.xml 16 Nov 2003 20:55:13 - 1.7 @@ -84,7 +84,7 @@ item name=JXPath href=http://jakarta.apache.org/commons/jxpath/index.html/ item name=Lang -href=http://jakarta.apache.org/commons/lang.html/ +href=http://jakarta.apache.org/commons/lang/index.html/ item name=Latka href=http://jakarta.apache.org/commons/latka/index.html/ item name=Logging - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Elect Paul Libbrecht as a Jakarta Commons Committer
+1 On 15 Nov 2003, at 23:25, Henri Yandell wrote: +1. Surprised he's not a committer already. On Sat, 15 Nov 2003, Tim O'Brien wrote: +1 On Sat, 2003-11-15 at 15:11, Juozas Baliuka wrote: +1 - Original Message - From: peter royal [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, November 15, 2003 10:46 PM Subject: [VOTE] Elect Paul Libbrecht as a Jakarta Commons Committer Paul Libbrecht [EMAIL PROTECTED] has been contributing to Jelly in the form of patches and valued support on the user list for over a year now. I think its about time that he be gifted with the ability to take his involvement to the next level. +1 from me. -pete --- Vote: Elect Paul Libbrecht as a Jakarta Commons Committer [ ] +1 Yes let him commit! [ ] +0 [ ] -0 [ ] -1 No way (because of my reason included below...) --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Tim O'Brien - [EMAIL PROTECTED] - (847) 863-7045 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] emeritus committers?
On 14 Nov 2003, at 13:51, Rodney Waldhoff wrote: On Fri, 14 Nov 2003, Shapira, Yoav wrote: Howdy, BTW i think that exercise is something that we'll need to repeat sometime soon for the whole of jakarta. I agree, which is why I wanted to ask for the script/method used to produce this list of inactive committers for a given module. Me three, I just wanted to start small. sounds like a good plan :) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections build.xml
scolebourne2003/11/16 13:39:42
Modified:collections/src/test/org/apache/commons/collections/bidimap
AbstractTestSortedBidiMap.java
collections/src/test/org/apache/commons/collections
AbstractTestMap.java AbstractTestCollection.java
collections build.xml
Log:
Rework build script for new test classes
Revision ChangesPath
1.2 +9 -10
jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/AbstractTestSortedBidiMap.java
Index: AbstractTestSortedBidiMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/bidimap/AbstractTestSortedBidiMap.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- AbstractTestSortedBidiMap.java16 Nov 2003 20:35:46 - 1.1
+++ AbstractTestSortedBidiMap.java16 Nov 2003 21:39:42 - 1.2
@@ -71,10 +71,9 @@
import org.apache.commons.collections.AbstractTestSortedMap;
import org.apache.commons.collections.BulkTest;
-import org.apache.commons.collections.pairs.DefaultMapEntry;
/**
- * Abstract test class for [EMAIL PROTECTED] BidiMap} methods and contracts.
+ * Abstract test class for [EMAIL PROTECTED] SortedBidiMap} methods and contracts.
*
* @version $Revision$ $Date$
*
@@ -253,8 +252,8 @@
assertEquals(2, set.size());
Iterator it2 = set.iterator();
-Map.Entry firstEntry = new DefaultMapEntry((Map.Entry) it2.next());
-Map.Entry secondEntry = new DefaultMapEntry((Map.Entry) it2.next());
+Map.Entry firstEntry = cloneMapEntry((Map.Entry) it2.next());
+Map.Entry secondEntry = cloneMapEntry((Map.Entry) it2.next());
assertEquals(true, sm.containsKey(first));
assertEquals(true, sub.containsKey(first));
assertEquals(true, set.contains(firstEntry));
@@ -418,8 +417,8 @@
Set set = sub.entrySet();
Iterator it2 = set.iterator();
Object fromEntry = it2.next();
-Map.Entry firstEntry = new DefaultMapEntry((Map.Entry) it2.next());
-Map.Entry secondEntry = new DefaultMapEntry((Map.Entry) it2.next());
+Map.Entry firstEntry = cloneMapEntry((Map.Entry) it2.next());
+Map.Entry secondEntry = cloneMapEntry((Map.Entry) it2.next());
assertEquals(true, sm.containsKey(first));
assertEquals(true, sub.containsKey(first));
assertEquals(true, set.contains(firstEntry));
@@ -601,8 +600,8 @@
assertEquals(3, set.size());
Iterator it2 = set.iterator();
Object fromEntry = it2.next();
-Map.Entry firstEntry = new DefaultMapEntry((Map.Entry) it2.next());
-Map.Entry secondEntry = new DefaultMapEntry((Map.Entry) it2.next());
+Map.Entry firstEntry = cloneMapEntry((Map.Entry) it2.next());
+Map.Entry secondEntry = cloneMapEntry((Map.Entry) it2.next());
assertEquals(true, sm.containsKey(first));
assertEquals(true, sub.containsKey(first));
assertEquals(true, set.contains(firstEntry));
1.13 +11 -2
jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestMap.java
Index: AbstractTestMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestMap.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- AbstractTestMap.java 4 Nov 2003 23:35:35 - 1.12
+++ AbstractTestMap.java 16 Nov 2003 21:39:42 - 1.13
@@ -435,6 +435,15 @@
return new HashMap();
}
+/**
+ * Creates a new Map Entry that is independent of the first and the map.
+ */
+protected Map.Entry cloneMapEntry(Map.Entry entry) {
+HashMap map = new HashMap();
+map.put(entry.getKey(), entry.getValue());
+return (Map.Entry) map.entrySet().iterator().next();
+}
+
//---
/**
* Test to ensure the test setup is working properly. This method checks
1.9 +13 -5
jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestCollection.java
Index: AbstractTestCollection.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/AbstractTestCollection.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- AbstractTestCollection.java 4 Nov 2003 23:34:46 - 1.8
+++ AbstractTestCollection.java 16 Nov 2003 21:39:42 - 1.9
@@
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/observed TestObservableBuffer.java TestObservableCollection.java TestObservableSet.java TestObservableList.java TestObservableSortedSet.java TestObservableBag.java TestObservableSortedBag.java
scolebourne2003/11/16 14:15:12 Modified:collections/src/test/org/apache/commons/collections/primitives/adapters TestByteListList.java TestByteCollectionCollection.java TestDoubleListList.java TestCharCollectionCollection.java TestFloatListList.java TestDoubleCollectionCollection.java TestIntCollectionCollection.java TestShortCollectionCollection.java TestFloatCollectionCollection.java TestLongCollectionCollection.java TestIntListList.java TestShortListList.java TestLongListList.java TestCharListList.java collections/src/test/org/apache/commons/collections/list TestSetUniqueList.java TestTransformedList.java TestUnmodifiableList.java TestFixedSizeList.java TestPredicatedList.java collections/src/test/org/apache/commons/collections TestFlat3Map.java TestArrayList.java TestMultiHashMap.java TestCollectionUtils.java TestDoubleOrderedMap.java TestLinkedList.java TestSequencedHashMap.java TestCircularFifoBuffer.java TestCursorableLinkedList.java TestBufferUtils.java TestBoundedFifoBuffer.java TestBinaryHeap.java TestMapUtils.java TestFastHashMap.java TestBeanMap.java TestListUtils.java TestReferenceMap.java TestUnboundedFifoBuffer.java TestHashBag.java TestTreeBag.java TestTreeMap.java TestSetUtils.java TestStaticBucketMap.java collections/src/test/org/apache/commons/collections/set TestPredicatedSortedSet.java TestTransformedSet.java TestUnmodifiableSortedSet.java TestTypedSortedSet.java TestPredicatedSet.java TestTransformedSortedSet.java TestListOrderedSet.java collections/src/test/org/apache/commons/collections/bag TestPredicatedBag.java TestTypedSortedBag.java TestTypedBag.java TestTransformedBag.java TestPredicatedSortedBag.java TestTransformedSortedBag.java collections/src/test/org/apache/commons/collections/map TestUnmodifiableMap.java TestTransformedSortedMap.java TestFixedSizeMap.java TestPredicatedMap.java TestFixedSizeSortedMap.java TestListOrderedMap.java TestLazyMap.java TestTransformedMap.java collections/src/test/org/apache/commons/collections/collection TestPredicatedCollection.java TestTransformedCollection.java TestCompositeCollection.java collections/src/test/org/apache/commons/collections/primitives TestCharList.java TestLongList.java TestByteList.java TestAbstractLongArrayList.java TestIntList.java TestDoubleList.java TestShortList.java TestFloatList.java collections/src/test/org/apache/commons/collections/bidimap AbstractTestSortedBidiMap.java AbstractTestBidiMap.java collections/src/test/org/apache/commons/collections/observed TestObservableBuffer.java TestObservableCollection.java TestObservableSet.java TestObservableList.java TestObservableSortedSet.java TestObservableBag.java TestObservableSortedBag.java Added: collections/src/test/org/apache/commons/collections/list AbstractTestList.java collections/src/test/org/apache/commons/collections/set AbstractTestSortedSet.java AbstractTestSet.java collections/src/test/org/apache/commons/collections/bag AbstractTestSortedBag.java AbstractTestBag.java collections/src/test/org/apache/commons/collections/map AbstractTestMap.java AbstractTestSortedMap.java collections/src/test/org/apache/commons/collections/collection AbstractTestCollection.java Removed: collections/src/test/org/apache/commons/collections AbstractTestSortedBag.java AbstractTestList.java
cvs commit: jakarta-commons-sandbox/naming/factory project.properties
brett 2003/11/16 14:24:16
Modified:naming/core project.properties
naming/factory project.properties
Log:
should set the multiproject type
Revision ChangesPath
1.2 +1 -0 jakarta-commons-sandbox/naming/core/project.properties
Index: project.properties
===
RCS file: /home/cvs/jakarta-commons-sandbox/naming/core/project.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- project.properties2 Sep 2003 03:43:56 - 1.1
+++ project.properties16 Nov 2003 22:24:16 - 1.2
@@ -2,3 +2,4 @@
maven.junit.fork=true
maven.xdoc.date = left
maven.checkstyle.header.file=${basedir}/../LICENSE.txt
+maven.multiproject.type=jar
1.2 +1 -0 jakarta-commons-sandbox/naming/factory/project.properties
Index: project.properties
===
RCS file: /home/cvs/jakarta-commons-sandbox/naming/factory/project.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- project.properties2 Sep 2003 04:18:08 - 1.1
+++ project.properties16 Nov 2003 22:24:16 - 1.2
@@ -1,2 +1,3 @@
maven.checkstyle.properties=${basedir}/../checkstyle.xml
maven.checkstyle.header.file=${basedir}/../LICENSE.txt
+maven.multiproject.type=jar
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24737] New: - Non existant files and empty directories not detected
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=24737. 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=24737 Non existant files and empty directories not detected Summary: Non existant files and empty directories not detected Product: Commons Version: 1.1.0 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Net AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When using the method FTPClient.listFiles(pathname) on a non-existant file or an empty directory, incorrect results are returned - in both cases a null array would be expected. In the case of a non-existant file an array of size 1 is returned with the value being ... No such file or directory In the case of an empty directory an array of size 0 is returned. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester/plugins Declaration.java InitializableRule.java PluginCreateRule.java PluginDeclarationRule.java PluginManager.java PluginRules.java
rdonkin 2003/11/16 14:37:35
Modified:digester/src/java/org/apache/commons/digester/plugins
Declaration.java InitializableRule.java
PluginCreateRule.java PluginDeclarationRule.java
PluginManager.java PluginRules.java
Log:
Cosmetic changes to tidy up code formatting. Submitted by Simon Kitching.
Revision ChangesPath
1.7 +72 -81
jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/Declaration.java
Index: Declaration.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/Declaration.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- Declaration.java 2 Nov 2003 23:26:59 - 1.6
+++ Declaration.java 16 Nov 2003 22:37:35 - 1.7
@@ -85,31 +85,31 @@
public final static String DFLT_RULE_METHOD_NAME = addRules;
/** The class of the object to be instantiated. */
-private Class pluginClass_;
+private Class pluginClass;
/** The name of the class of the object to be instantiated. */
-private String pluginClassName_;
+private String pluginClassName;
/** See [EMAIL PROTECTED] #setId}. */
-private String id_;
+private String id;
/** See [EMAIL PROTECTED] #setRuleMethod}. */
-private String ruleMethodName_ = DFLT_RULE_METHOD_NAME;
+private String ruleMethodName = DFLT_RULE_METHOD_NAME;
/** See [EMAIL PROTECTED] #setRuleClass}. */
-private Class ruleClass_;
+private Class ruleClass;
/** See [EMAIL PROTECTED] #setRuleResource}. */
-private String ruleResource_;
+private String ruleResource;
/** See [EMAIL PROTECTED] #setRuleFile}. */
-private File ruleFile_;
+private File ruleFile;
/** See [EMAIL PROTECTED] #setAutoSetProperties}. */
-private boolean autoSetProperties_ = true;
+private boolean autoSetProperties = true;
/** See [EMAIL PROTECTED] #init}. */
-private boolean initialised_ = false;
+private boolean initialized = false;
//-- constructors --
@@ -117,15 +117,15 @@
* Constructor.
*/
public Declaration(Class pluginClass) {
-pluginClass_ = pluginClass;
-pluginClassName_ = pluginClass_.getName();
+this.pluginClass = pluginClass;
+this.pluginClassName = pluginClass.getName();
}
/**
* Constructor.
*/
public Declaration(String pluginClassName) {
-pluginClassName_ = pluginClassName;
+this.pluginClassName = pluginClassName;
}
//-- properties ---
@@ -135,14 +135,14 @@
* For plugins declared in-line, the id is null.
*/
public void setId(String id) {
-id_ = id;
+this.id = id;
}
/**
* Sets the name of a method which defines custom rules. May be null.
*/
public void setRuleMethod(String ruleMethodName) {
-ruleMethodName_ = ruleMethodName;
+this.ruleMethodName = ruleMethodName;
}
/**
@@ -150,7 +150,7 @@
* for the plugin class. May be null.
*/
public void setRuleClass(Class ruleClass) {
-ruleClass_ = ruleClass;
+this.ruleClass = ruleClass;
}
/**
@@ -158,7 +158,7 @@
* specifications of custom rules for the plugin class. May be null.
*/
public void setRuleResource(String ruleResource) {
-ruleResource_ = ruleResource;
+this.ruleResource = ruleResource;
}
/**
@@ -166,12 +166,12 @@
* for the plugin class. May be null.
*/
public void setRuleFile(File ruleFile) {
-ruleFile_ = ruleFile;
+this.ruleFile = ruleFile;
}
/** See [EMAIL PROTECTED] #autoSetProperties}. */
public void setAutoSetProperties(boolean autoSetProperties) {
-autoSetProperties_ = autoSetProperties;
+this.autoSetProperties = autoSetProperties;
}
/**
@@ -180,7 +180,7 @@
* @return The id value. May be null.
*/
public String getId() {
-return id_;
+return id;
}
/**
@@ -189,7 +189,7 @@
* @return The pluginClass.
*/
public Class getPluginClass() {
-return pluginClass_;
+return pluginClass;
}
/**
@@ -198,7 +198,7 @@
* @return The ruleClass value. May be null.
*/
public Class getRuleClass() {
-return ruleClass_;
+return ruleClass;
Re: [digester] repost : patch for plugins
On 15 Nov 2003, at 03:01, Simon Kitching wrote: On Thu, 2003-11-13 at 12:44, robert burrell donkin wrote: snip i don't want to get religious but it's good to have a convention (it really helps new developers). digester source keeps the catch brackets and the else brackets on the same line. No problems. I wasn't aware that this *was* the convention. no problem. we really should document this somewhere. You did remind me, though, that I promised early on that if Plugins was accepted as part of Digester that I would change all the proposed code to comply with Apache conventions. So here's a patch that does exactly that. cool. committed. Changes are: * remove trailing underscores (which I use to distinguish member variables from locals/params. Where necessary, apply this. to distinguish the two. * change catch clause brace indentation as described above * change method declaration parameter/throws indentation. * rename initialise to initialize (british-american spelling). bit of a moot point whether this is an convention or not. i'm in favour of leaving this up to the individual developer but i know some other people feel feel differently. Oh and BTW, all indentation is done with spaces, not tabs. That is the convention, isn't it? (I hate tabs) we all hate tabs :) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/primitives/xdocs faq.xml index.xml
rwaldhoff2003/11/16 15:20:21
Modified:primitives/xdocs index.xml
Added: primitives/xdocs faq.xml
Log:
add basic FAQ
Revision ChangesPath
1.7 +2 -1 jakarta-commons/primitives/xdocs/index.xml
Index: index.xml
===
RCS file: /home/cvs/jakarta-commons/primitives/xdocs/index.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- index.xml 6 Nov 2003 00:55:23 - 1.6
+++ index.xml 16 Nov 2003 23:20:21 - 1.7
@@ -13,7 +13,7 @@
p
Apache Jakarta Commons Primitives provides a collection of types and utilities
optimized
for working with Java primitives (boolean, byte, char, double, float, int, long,
short).
-Generally, the Commons-Primitives classes are faster, smaller and easier to work
with than
+Generally, the Commons-Primitives classes are smaller, faster and easier to work
with than
their purely Object based alternatives.
/p
/section
@@ -75,6 +75,7 @@
p
For more information on Commons Primitives, you might like to visit the
+a href=faq.htmlFAQ/a,
a href=./apidocs/index.htmlJavaDocs/a, a href=./project-info.htmlproject
information/a
or a href=./maven-reports.htmlproject reports/a.
/p
1.1 jakarta-commons/primitives/xdocs/faq.xml
Index: faq.xml
===
?xml version=1.0?
document
properties
titleCommons Primitives: FAQ/title
author email=[EMAIL PROTECTED]Commons Documentation Team/author
/properties
body
section name=The Primitives Component
dl
dtQ: Why would I use the primitive collections?/dt
dd
p
The main advantage of the primitive collections is that they are signficantly
smaller than their java.util equivalents.
How much smaller? Well, consider this table:
/p
table border=1 cellspacing=0
tr
thObject-based Collection/th
thBytes per Element/th
thPrimitive Collection/th
thBytes per Element/th
thSpace Savings/th
/tr
tr
tdArrayList of Bytes/td
td align=right16/td
tdArrayByteList/td
td align=right1/td
td align=right93.4%/td
/tr
tr
tdArrayList of Shorts/td
td align=right16/td
tdArrayShortList/td
td align=right2/td
td align=right87.5%/td
/tr
tr
tdArrayList of Characters/td
td align=right16/td
tdArrayCharList/td
td align=right4/td
td align=right75.0%/td
/tr
tr
tdArrayList of Floats/td
td align=right16/td
tdArrayFloatList/td
td align=right4/td
td align=right75.0%/td
/tr
tr
tdArrayList of Integers/td
td align=right16/td
tdArrayIntist/td
td align=right4/td
td align=right75.0%/td
/tr
tr
tdArrayList of Doubles/td
td align=right16/td
tdArrayDoubleList/td
td align=right8/td
td align=right50.0%/td
/tr
tr
tdArrayList of Longs/td
td align=right16/td
tdArrayLongList/td
td align=right8/td
td align=right50.0%/td
/tr
/table
p
Depending upon your circumstances, you may also find the primitive collections to be
faster,
both because of the reduction in time spent boxing and un-boxing the primitives and
their
Object wrappers, and because there are fewer bytes to move around when copying or
moving
data.
/p
p
In the pre-autoboxing (JDK 1.5) world, you may also find the primitive collections
easier
to work with, since you'll waste fewer keystrokes manually boxing and un-boxing the
primitives and their Object wrappers. For instance, to sum an ArrayList of
Integers, you
might write something like:
/p
preint sum = 0;
for(Iterator iter = list.iterator(); iter.hasNext(); ) {
sum += ((Integer)(iter.next())).intValue();
}/pre
p
The IntList equivalent would be:
/p
preint sum = 0;
for(IntIterator iter = list.iterator(); iter.hasNext(); ) {
sum += iter.next();
}/pre
/dd
dtQ: But isn't this overkill? Aren't the time and space efficiencies
insignificant for the size and number of collections used by most applications?/dt
dd
p
Yes.
/pp
The primitive collections are most useful for applications that create very many or
very large
collections of primitive types, or that process them very frequently.
/p
/dd
dtQ: Won't this functionality be available in JDK 1.5 using auto-boxing and
generics?/dt
dd
p
No.
/pp
Using generics, one can create collections that are specific to a particular Object
from a templated
implementation, for instance, a List of Integers or a List of Strings from the same
prototype
implemenation. Since the distinction between Java primitives and Java Objects is
not going away, it will
not be possible to, for example, instantiate a List of ints from that same prototype.
/pp
Using autoboxing, it will be possible to emulate the syntax of using the primitive
Re: [VOTE] Elect Paul Libbrecht as a Jakarta Commons Committer
+1 peter royal wrote: Paul Libbrecht [EMAIL PROTECTED] has been contributing to Jelly in the form of patches and valued support on the user list for over a year now. I think its about time that he be gifted with the ability to take his involvement to the next level. +1 from me. -pete --- Vote: Elect Paul Libbrecht as a Jakarta Commons Committer [ ] +1 Yes let him commit! [ ] +0 [ ] -0 [ ] -1 No way (because of my reason included below...) --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator ValidatorAction.java
rleland 2003/11/16 19:34:50
Modified:validator/src/share/org/apache/commons/validator
ValidatorAction.java
Log:
Bug 23972
Non printing characters were coming from buffer not
being read completely.
I thought I checked this change in back in October,
but it isn't in CVS.
Revision ChangesPath
1.16 +13 -10
jakarta-commons/validator/src/share/org/apache/commons/validator/ValidatorAction.java
Index: ValidatorAction.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/ValidatorAction.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- ValidatorAction.java 21 Aug 2003 21:43:05 - 1.15
+++ ValidatorAction.java 17 Nov 2003 03:34:50 - 1.16
@@ -440,18 +440,21 @@
}
if (is == null) {
+log.debug( Unable to read javascript name +javascriptFileName);
return null;
}
StringBuffer function = new StringBuffer();
try {
int bufferSize = is.available();
-
+int bytesRead;
while (bufferSize 0) {
byte[] buffer = new byte[bufferSize];
-is.read(buffer, 0, bufferSize);
-String functionPart = new String(buffer);
-function.append(functionPart);
+bytesRead = is.read(buffer, 0, bufferSize);
+if (bytesRead 0) {
+String functionPart = new String(buffer,0,bytesRead);
+function.append(functionPart);
+}
bufferSize = is.available();
}
@@ -465,8 +468,8 @@
log.error(readJavascriptFile(), e);
}
}
-
-return function.toString().equals() ? null : function.toString();
+String strFunction = function.toString();
+return strFunction.equals() ? null : strFunction;
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator Field.java
rleland 2003/11/16 19:35:30
Modified:validator/src/share/org/apache/commons/validator Field.java
Log:
Update JavaDocs
Revision ChangesPath
1.27 +5 -4
jakarta-commons/validator/src/share/org/apache/commons/validator/Field.java
Index: Field.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/Field.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- Field.java28 Sep 2003 20:39:57 - 1.26
+++ Field.java17 Nov 2003 03:35:30 - 1.27
@@ -258,6 +258,7 @@
/**
* Sets the validation rules for this field as a comma separated list.
+ * @param depends A comma separated list of validator names.
*/
public void setDepends(String depends) {
this.depends = depends;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateByte.js validateCreditCard.js validateDate.js validateEmail.js validateFloat.js validateFloatRange.js validateIntRange.js validateInteger.js validateMask.js validateMaxLength.js validateMinLength.js validateRequired.js validateShort.js
rleland 2003/11/16 20:57:50
Modified:validator/src/javascript/org/apache/commons/validator/javascript
validateByte.js validateCreditCard.js
validateDate.js validateEmail.js validateFloat.js
validateFloatRange.js validateIntRange.js
validateInteger.js validateMask.js
validateMaxLength.js validateMinLength.js
validateRequired.js validateShort.js
Log:
Bug 21043 Suggested fix by Colin Froggatt
Ignore validation criteria when field is disabled.
This was reported for mask but this was extended to all field types.
Revision ChangesPath
1.4 +6 -5
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateByte.js
Index: validateByte.js
===
RCS file:
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateByte.js,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- validateByte.js 22 Oct 2003 07:20:57 - 1.3
+++ validateByte.js 17 Nov 2003 04:57:50 - 1.4
@@ -12,10 +12,11 @@
for (x in oByte) {
var field = form[oByte[x][0]];
-if (field.type == 'text' ||
+if ((field.type == 'text' ||
field.type == 'textarea' ||
field.type == 'select-one' ||
-field.type == 'radio') {
+field.type == 'radio')
+field.disabled == false) {
var value = '';
// get field's value
1.4 +5 -4
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateCreditCard.js
Index: validateCreditCard.js
===
RCS file:
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateCreditCard.js,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- validateCreditCard.js 22 Oct 2003 07:20:57 - 1.3
+++ validateCreditCard.js 17 Nov 2003 04:57:50 - 1.4
@@ -12,7 +12,8 @@
for (x in oCreditCard) {
if ((form[oCreditCard[x][0]].type == 'text' ||
form[oCreditCard[x][0]].type == 'textarea')
-(form[oCreditCard[x][0]].value.length 0)) {
+(form[oCreditCard[x][0]].value.length 0)
+ form[oCreditCard[x][0]].disabled == false) {
if (!luhnCheck(form[oCreditCard[x][0]].value)) {
if (i == 0) {
focusField = form[oCreditCard[x][0]];
1.5 +99 -97
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateDate.js
Index: validateDate.js
===
RCS file:
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateDate.js,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- validateDate.js 22 Oct 2003 07:20:57 - 1.4
+++ validateDate.js 17 Nov 2003 04:57:50 - 1.5
@@ -16,67 +16,106 @@
// try loose pattern
if (datePattern == null)
datePattern = oDate[x][2](datePattern);
- if ((form[oDate[x][0]].type == 'text' || form[oDate[x][0]].type ==
'textarea')
- (value.length 0) (datePattern.length 0)) {
- var MONTH = MM;
- var DAY = dd;
- var YEAR = ;
- var orderMonth = datePattern.indexOf(MONTH);
- var orderDay = datePattern.indexOf(DAY);
- var orderYear = datePattern.indexOf(YEAR);
- if ((orderDay orderYear orderDay orderMonth)) {
- var iDelim1 = orderMonth + MONTH.length;
- var iDelim2 = orderDay + DAY.length;
- var delim1 = datePattern.substring(iDelim1, iDelim1 + 1);
- var delim2 = datePattern.substring(iDelim2, iDelim2 + 1);
- if (iDelim1 == orderDay iDelim2 == orderYear) {
-dateRegexp = new RegExp(^(\\d{2})(\\d{2})(\\d{4})$);
- } else if (iDelim1 == orderDay) {
-dateRegexp = new RegExp(^(\\d{2})(\\d{2})[ + delim2 +
](\\d{4})$);
- } else if (iDelim2 == orderYear) {
-dateRegexp = new RegExp(^(\\d{2})[ + delim1 +
](\\d{2})(\\d{4})$);
- } else {
-dateRegexp = new RegExp(^(\\d{2})[ + delim1 + ](\\d{2})[ +
delim2 + ](\\d{4})$);
- }
- var matched = dateRegexp.exec(value);
-
DO NOT REPLY [Bug 21043] - javascript mask validator fails when field is disabled
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=21043. 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=21043 javascript mask validator fails when field is disabled [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-11-17 04:58 --- This was extended to all field types so validation is ignored for disabled fields. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[general] screwed up Commons site
There are some problems on the Commons site cvs-wise at the moment. dbcp.html and pool.html have been edited locally. httpclient/ has also been edited locally. These will get merges when we do a cvs update to get the latest version of Lang out [as the url of the lang page is changing]. Not in itself a problem, but a potential one. More painfully, the Latka site has also been updated locally and has cvs clashes. If we do an update for Lang we're going to cause big problems here. DBCP, Pool, HttpClient could all just copy the files on minotaur over to a cvs repository that is not checked out as anonymous and commit them there. Latka needs more juggling. Any thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] emeritus committers?
+1 to all of the emeritus bits, both commons and long term jakarta. Are we able to simply comment peoples names out in the avail file so we know who has had access? I've not used avail in CVS before. Unsure if it's CVS or apache-specific. Hen On Sun, 16 Nov 2003, robert burrell donkin wrote: On 14 Nov 2003, at 13:51, Rodney Waldhoff wrote: On Fri, 14 Nov 2003, Shapira, Yoav wrote: Howdy, BTW i think that exercise is something that we'll need to repeat sometime soon for the whole of jakarta. I agree, which is why I wanted to ask for the script/method used to produce this list of inactive committers for a given module. Me three, I just wanted to start small. sounds like a good plan :) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] screwed up Commons site
Any thoughts? You want my view? As a matter of policy, changes that are not in CVS should not be considered changes. If you care to be nice, you could do cvs diff -u and e-mail the diff to the list before you blow the renegade file(s) away. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/math/xdocs/images - New directory
mdiggory2003/11/16 21:37:28 jakarta-commons/math/xdocs/images - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/math/xdocs/images math.psd math.gif
mdiggory2003/11/16 21:38:09 Modified:math project.xml Added: math/xdocs/images math.psd math.gif Log: Site Logo :-) Revision ChangesPath 1.31 +2 -2 jakarta-commons/math/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/math/project.xml,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- project.xml 15 Nov 2003 20:57:46 - 1.30 +++ project.xml 17 Nov 2003 05:38:09 - 1.31 @@ -6,7 +6,7 @@ idcommons-math/id currentVersion0.1-dev/currentVersion inceptionYear2003/inceptionYear - logo/ + logo/images/math.gif/logo shortDescription A library of lightweight, self-contained mathematics and statistics components. /shortDescription 1.1 jakarta-commons/math/xdocs/images/math.psd Binary file 1.1 jakarta-commons/math/xdocs/images/math.gif Binary file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
I'd like to add tables for the Current Status, but it appears that tables are not currently enabled for our wiki. I've requested that from the wiki admin folks, so hopefully I'll be able to add them soon. You have? I don't recall seeing ... OH! You must have posted to the Wiki Admin list instead of the infrastructure list. The current Wiki is expected to go hasta la bye-bye soon. The new Wiki technology can be seen at http://wiki.apache.org/. There are a few people who have volunteered to help migrate the data from the current wiki, so as soon as they have that worked out, hopefully we can migrate and cut over. When that happens, there will be a Wiki specifically for Jakarta. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
On Mon, 17 Nov 2003, Noel J. Bergman wrote: I'd like to add tables for the Current Status, but it appears that tables are not currently enabled for our wiki. I've requested that from the wiki admin folks, so hopefully I'll be able to add them soon. You have? I don't recall seeing ... OH! You must have posted to the Wiki Admin list instead of the infrastructure list. Yup. The WikiAdmin page lists you as one of them, too. ;-) The current Wiki is expected to go hasta la bye-bye soon. The new Wiki technology can be seen at http://wiki.apache.org/. There are a few people who have volunteered to help migrate the data from the current wiki, so as soon as they have that worked out, hopefully we can migrate and cut over. When that happens, there will be a Wiki specifically for Jakarta. Um, OK. I guess I missed that we're changing wikis (again?). Any idea what the timeframe is likely to be? I'd guess that it's not quite imminent, so we should find a workaround for the current wiki in the meantime? -- Martin Cooper --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
Yup. The WikiAdmin page lists you as one of them, too. ;-) I'm not subscribed to wikidiff, though. Um, OK. I guess I missed that we're changing wikis (again?). Again? The current Wiki is the original one that Andrew Oliver installed. The new one is MoinMoin, which has (amongst other benefits) the ability to have a Wiki per-PMC. That addresses oversight concerns that have been raised, plus it has a lot more functionality. Any idea what the timeframe is likely to be? It is up and running now. AFAIK, the only hangup is migrating existing pages. I'd guess that it's not quite imminent, so we should find a workaround for the current wiki in the meantime? Hmmm ... if you want, I could look into setting up the Jakarta Wiki, even without the data currently on nagoya. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24671] - Basic Authentification fails with non-ASCII username/password characters
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=24671. 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=24671 Basic Authentification fails with non-ASCII username/password characters --- Additional Comments From [EMAIL PROTECTED] 2003-11-17 03:23 --- I left it open to remind me to investigate this problem with digest authentication. I haven't been able to test it out, but I believe we have the same problem with digest. Has anyone tried digest with non-ASCII characters? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping Connections Alive
Hi Sam, I think this is definitely something that could be a useful addition to HttpClient. Though it would be possible to add this functionality to the MultiThreadedHttpConnectionManager (MTCM) I think I would like to keep it separate. Partially because I think MTCM is getting a little to complicated, but also because I think it could be used outside of the MTCM. In general I think we want a pluggable method for tracking the lifecycle of a connection. Something like a HttpConnection listener that is informed when a connection is created, assigned, released, etc. This listener could then handle closing the connections after some period of idleness. Any suggestions or contributions that you may have will be appreciated. Thanks, Mike On Nov 14, 2003, at 12:58 PM, Sam Berlin wrote: Thanks for the reply, Mike. Is there any interest in a feature that would close connections that have been unused for a certain amount of time? I imagine the easiest way to implement this would be to just add some settable parameters (set/getCloseConnectionTime) to MultiThreadedHttpConnectionManager along with another Thread that will occasionally iterate through the list of 'freeConnections' in the 'connectionPool', checking an amount of time has lapsed since the connection was last marked as free. HttpConnection (or HttpConnectionAdapater, since this feature would only be in MultiThreadedHttpConnectionManager) could have a new value added to it that stores the most recent time it was released. Note that this would all rely on the user correctly calling 'releaseConnection', but that's essentially a requirement already anyway. If people are interested in such a feature, I would be more than willing to write up such a patch (as I will probably be doing it for the version LimeWire uses anyway). Thanks, Sam Michael Becke wrote: Hi Sam, HttpClient does not do any active connection reclaiming, except when the resources are reused. In the case of the SimpleHttpConnectionManager the connection is never closed/reopened unless it is required for a new method execution. The case for MultiThreadedHttpConnectionManager is similar though a little more complicated. It keeps a pool of connections with a per-host and total connection limit. Again these connections are never closed until a request for a new connection warrants it. Mike On Nov 13, 2003, at 4:10 PM, Sam Berlin wrote: Hi All, I'd like to clarify a point about HttpClient that I do not fully understand. How/when does the actual connection to a server close? I understand that MultiThreadedHttpConnectionManager (and possibly SimpleConnectionManager as well) will keep the connection alive and reuse it for subsequent HTTP requests. Is there a way to set a limit on how long the connection should be kept alive before waiting for a subsequent request to reuse that connection? Thanks, Sam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
