Re: [validator] UrlValidator
Question 3)
Changing the UrlValidator should be a matter of getting the regular
expression correct I believe(?) for the empty path parts.
One thought I had on port validation was to attempt to construct a
java.net.URL and do something like
2 problems with thatg:
1 ) I believe there is no URL validation under JDK 1.3,
there was even a comment about how validation would
be a good thing to add. So it probably passes to underlying
OS to see if it fails.
2) For maintainability its best if the JS Java methods mirror one another.
True there is no JS URLValidator but if there were then it would have to
rely on RegEx, so why not just stick with that method.
if (u.getPort() 0 u.getDefaultPort() 0) {
return false;
}
which I think would mean the protocol handler for the scheme has a known
default port. Does this sound like a good approach? or is there a case where
someone has a protocol handler with default port that java.net.URL wouldn't
know about? Or a case where java.net.URL is going to throw
MalFormedUrlException where UrlValidator.isValid would otherwise return
true?
NP on the 1.1.4 status for me. If getting patches in can get it to 1.1.3
that'd be good too, either way.
Thanks,
-TR
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] Ted Husted as Committer
+1 To Ted. David Graham wrote: --- robert burrell donkin [EMAIL PROTECTED] wrote: +1 but please don't roll a release before the upcoming beanutils dependency hell fix is released. this will allow the problematic validator dependency on commons collections to be removed by upgrading to the next beanutils release. Actually, the removal of collections classes from validator will take a bit longer. Why is it that we want to remove FastHashMap ? is there a performance penalty ? Rob We still have protected FastHashMap variables that need to be replaced with Maps. David
Re: [Validator] Don Brown as Committer
David Graham wrote: Don has been a positive member of the Struts community so he'll be a good addition to the validator team. +1 +1. And he has worked with other frameworks which a big +1 David --- Ted Husted [EMAIL PROTECTED] wrote: Don Brown is an active Apache Struts Committer who would like to apply some patches to the Validator, with the hope of moving toward another release. Here's my +1 -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] Why doesn't commons-validator include functional validators?
We wanted add a standard isValid() type method a years ago, but there was not clear use case for that. Now we have the use cases ! Don Brown wrote: Just to be clear, the approach I feel would be simplest is to add isValid(Object bean, Field field)-type methods to each validator. This way, the validators commons-validator provides can be used as they are or front-ended like how Struts' FieldChecks class interacts with them. I've already gone through several validators, adding unit tests as I go, and things are looking good. Before I finish the rest of the validators, however, I want to make sure this is a good idea in the eyes of everyone else. For example, the new DateValidator looks like this: public boolean isValid(Object bean, Field field); public boolean isValid(Object bean, Field field, Locale locale); public boolean isValid(String value, String datePattern, boolean strict); public boolean isValid(String value, Locale locale); The top two methods do four things: 1. Pull the necessary parameters out of field variables (ie datePattern out of a field var to be passed to the third method) 2. Extract the field value as a String 3. Return true if the value is blank or null since the field may not be required (the bottom two methods return false in such a case) 4. Delegate handling to the bottom two methods Any objections? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] Niall Pemberton as Committer
Ted Husted wrote: Niall Pemberton is an Apache Struts Committer who would like to apply some patches to the Validator, with the hope of moving toward another release. Here's my +1 +1, yes I am a bit behind on my email. :-} ! -Ted. - 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: [validator] Schematron-type/XPath Validator
Don Brown wrote: I have seen how powerful JXPath can be in projects like PMD Just to be cautious maybe we could place the code initially in a contrib folder, to take a look at it ? I wrote a simple Validator that uses JXPath to implement a schematron-style validation where fields are evaluated against boolean XPath expressions. The idea is from the XMLForms project (http://www.xmlform.org), previously of Cocoon. JXPath makes it easy to write complex validations on many types of objects that can span object trees. The initialization of the validator looks like this: validator name=jxpath classname=org.apache.commons.validator.JXPathValidator method=isValid methodParams=java.lang.Object,org.apache.commons.validator.Field msg=/ and a sample usage: field property=value depends=jxpath var var-nametest/var-name var-valuenumber(.) 0 and number(.) lt; 10/var-value /var /field The test variable contains the xpath expression to evaluate. The property attribute contains the xpath expression to narrow the scope of the tested xpath. Thanks to JXPath, this validator works on many different types of Java objects, including JavaBeans, and can handle field property xpath expressions that match multiple nodes or values. If this validator would be useful for the commons-validator project, I can supply code for the validator, unit tests, and any patches to existing files, through bugzilla of course. Don - 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: [Validator] 1.1.3 Release
Thanks for giving that a work out ! -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 09:39 PM To: ''Jakarta Commons Developers List'' Subject: RE: [Validator] 1.1.3 Release works fine with nightly builds from struts thanks! -Original Message- From: Robert Leland [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 10:20 PM To: Jakarta Commons Developers List Subject: Re: [Validator] 1.1.3 Release +1, Thanks If anyone would like to try out that release before hand the can go to http://apache.org/~rleland/commons-validator I uploaded it based on a build from the 1_1_2_BRANCH last night. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] 1.1.3 Release
+1, Thanks If anyone would like to try out that release before hand the can go to http://apache.org/~rleland/commons-validator I uploaded it based on a build from the 1_1_2_BRANCH last night. -Rob -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 08:09 PM To: [EMAIL PROTECTED] Subject: [Validator] 1.1.3 Release If there are no objections, I'd like to roll a 1.1.3 release Friday, April 30, sometime after 5PM EST (GMT-5). -Ted. - 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: cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator ValidatorAction.java
No problem, you're focusing on the 1.2.0.
I am trying to keep the 1.1.3 branch upto date so when
the next RM is ready to cut it will be ready to go.
-Rob
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 13, 2004 12:53 PM
To: 'Jakarta Commons Developers List'
Subject: Re: cvs commit:
jakarta-commons/validator/src/share/org/apache/commons/validator ValidatorAction.java
Sorry I forgot to make the change on the branch too. Thanks for
remembering :-).
David
--- [EMAIL PROTECTED] wrote:
rleland 2004/04/12 22:49:22
Modified:validator/src/share/org/apache/commons/validator Tag:
VALIDATOR_1_1_2_BRANCH ValidatorAction.java
Log:
PR: 28257 Backported patch David made to use reader instead of
InputStream
to work around bug in JWS 1.4 under JRE prior to 1.3.1_05
Revision ChangesPath
No revision
No revision
1.20.2.1 +16 -19
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.20
retrieving revision 1.20.2.1
diff -u -r1.20 -r1.20.2.1
--- ValidatorAction.java 21 Feb 2004 17:10:29 - 1.20
+++ ValidatorAction.java 13 Apr 2004 05:49:22 - 1.20.2.1
@@ -21,8 +21,10 @@
package org.apache.commons.validator;
+import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
+import java.io.InputStreamReader;
import java.io.Serializable;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
@@ -428,32 +430,27 @@
return null;
}
-StringBuffer function = new StringBuffer();
+StringBuffer buffer = new StringBuffer();
+BufferedReader reader = new BufferedReader(new
InputStreamReader(is));
try {
-int bufferSize = is.available();
-int bytesRead;
-while (bufferSize 0) {
-byte[] buffer = new byte[bufferSize];
-bytesRead = is.read(buffer, 0, bufferSize);
-if (bytesRead 0) {
-String functionPart = new
String(buffer,0,bytesRead);
-function.append(functionPart);
-}
-bufferSize = is.available();
+String line = null;
+while ((line = reader.readLine()) != null) {
+buffer.append(line + \n);
}
} catch(IOException e) {
-log.error(readJavascriptFile(), e);
+log.error(Error reading javascript file., e);
} finally {
try {
-is.close();
+reader.close();
} catch(IOException e) {
-log.error(readJavascriptFile(), e);
+log.error(Error closing stream to javascript file.,
e);
}
}
-String strFunction = function.toString();
-return strFunction.equals() ? null : strFunction;
+
+String function = buffer.toString();
+return function.equals() ? null : function;
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
-
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]
[Validator] call for testers.
I would like to entice developers to give the Struts Nightly and/or the commons-validator a try. I am announcing this only on the 'dev' list in the belief that since you subscribed to the 'dev' list you are generally more advanced. Also since I will be in a crunch for the next few days I can't promise, that I'll be able to help out is you hit a snag, so having a adventurous spirit helps. if you haven't been scared away yet theh congradulations ! If you find the following validator features useful, then help us find any bugs that may be lurking so that the next release of Struts will hopefully make the beta or better rating. The 2 Validator features which would be of the most interest are 1) Ability to use multiple forms on the same page. 2) Validation inheritance. #2 is particularly useful if you have internationalized applications and you don't want to duplicate validations. The commons-validator CVS repository has unit tests demonstrating its use. Make sure to use the new DTD to use these new features. By the way --both-- features were user contributions, and greatly enhanced the validators usefulness. Note Struts 1.1 cannot be used with the nightly version of Struts. The Night build of struts is built with the current Validator. http://cvs.apache.org/builds/jakarta-struts/nightly/ If you use Validator stand alone: http://cvs.apache.org/builds/jakarta-commons/nightly/commons-validator/ I would love to know how many people use Validator standalone. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] Url Validation Patch - [Bug 28190]
Niall Pemberton wrote: Any feedback on the patch I submitted adding the ability to return an error code from when validating Url's? http://issues.apache.org/bugzilla/show_bug.cgi?id=28190 Niall I have a deadline this Friday that will probably stretch over the weekend. After that I'll have a chance to review it. Looking at it briefly, the patch itself looks ok. The main items I would look at is how it fits in with the other validations and if there was any mechanism that might be generalized to keep the validations consistent. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] Url Validation Patch - [Bug 28190]
Robert Leland wrote: Niall Pemberton wrote: Any feedback on the patch I submitted adding the ability to return an error code from when validating Url's? http://issues.apache.org/bugzilla/show_bug.cgi?id=28190 Niall I have a deadline this Friday that will probably stretch over the weekend. After that I'll have a chance to review it. Looking at it briefly, the patch itself looks ok. The main items I would look at is how it fits in with the other validations and if there was any mechanism that might be generalized to keep the validations consistent. -Rob I am inclined to simplify the code and always return the expandedCode, that would make the control flow simpler. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [betwixt] extensible optional parameters in .betwixt file
my proposed name for the tag is 'option' (since property could be how about 'behavior' ? -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] 1.1.2 build issues
-Original Message- From: David Graham [mailto:[EMAIL PROTECTED] What do we want to do with validator_1_1_2.dtd? I think we can remove it completely because, AFAICT, Rob removed the only new changes so it's now functionally equivalent to the 1.1 dtd. +1 David Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [Validator] Validator 1.1.2 release
Martin Cooper wrote: --- Vote: Commons Validator 1.1.2 Release [X] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason) --- Here is my +1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Validator] release(was : Re: Counting down to the 1.2.1 release)
Martin Cooper wrote: There have been some Validator discussions going on on commons-dev, related to JavaScript, so I'm going to wait for a green light from someone (David G?) before I roll Validator 1.1.2. Ok, Validator is now using DOM Level 1 compatable calls to resolve the form name. Thanks to Nacho and Matthew for reading the comments on the CVS log ! Also are you going to propose a release VOTE on commons ? -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Vote][Result] Release of Commons Validator 1.1.1
After having withdrawn http://marc.theaimsgroup.com/?l=jakarta-commons-devm=107152616626163w=4 the [Validator 1.1.1] http://marc.theaimsgroup.com/?l=jakarta-commons-devm=107147957701779w=4 release to have a proper vote http://marc.theaimsgroup.com/?l=jakarta-commons-devm=107154253909393w=4, the result was: 5 +1 votes, (If you count my Implied +1 vote) 0 0 votes 0 -1 votes. So it is again available for download at http://jakarta.apache.org/~rleland/ValidatorAlpha/1.1.1 -Rob Robert Leland wrote: For the moment I have withdrawn commons-validator, and we'll take a vote on its release, see bottom. The following release plan is proposed for Validator 1.1.0: * /Tag Date/ - Tuesday, December 15, 2003, 02:00:00 EST * /Release Manager/ - Robert Leland * /Alpha Release Announcement/ - To the following mailing list: o [EMAIL PROTECTED] o [EMAIL PROTECTED] * /Beta/General Release Announcement/ - To the following mailing lists: o [EMAIL PROTECTED] o [EMAIL PROTECTED] o [EMAIL PROTECTED] o [EMAIL PROTECTED] o [EMAIL PROTECTED] The release process shall follow the same general procedures established for the Apache HTTPD project http://httpd.apache.org/dev/release.html and Jakarta Commons products http://jakarta.apache.org/commons/releases/, and utilize the HTTPD numbering scheme. The release will initially be given an Alpha status and made available through the Release Manager's home directory. Pursuant to a Majority Vote on the /commons-dev/ Mailing List, the release may be moved to the public release directory. The vote may also serve to reclassify the release to be of *Beta* or *General Availability* (GA) quality, as defined by the Apache HTTPD project. Subsequent votes may reclassify the release, either to promote it or to demote it, as need be. Issues There are currently 3 outstanding Bugs reports http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22781 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20579 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22124 Bug 20579 22124 Both deal with the Email validation. Unit tests have been added to cover these items so tests fail.I propose that these bugs be marked LATER and addressed in afollow up release. Known existing Struts validator applications work correctly, in both english and in French. Using Mozilla 1.4 IE 6. It has also been tested undet the latest tomcat 3.3.1a, and Tomcat 4.1.29 This Release contains the same jar dependencies as the 1.1.0 release: commons-beanutils 1.6.1 commons-collections 2.1 commons-digester 1.5 commons-logging 1.0.3oro 2.0.7 xml-apis 2.0.2 junit 3.8.1 Finally I propose that we release the tip of the main trunk in CVS as Commons Validator 1.1.1. A set of release notes has been uploaded to the validator web site. http://jakarta.apache.org/commons/validator/tasks.html Voting will end Sunday December 21, 12 Noon. --- Vote: Commons Validator 1.1.1 Release [ ] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Commons-Validator 1.1.1 released
Commons Validator 1.1.1 is now available for testing. Please refer to http://jakarta.apache.org/commons/validator/tasks.html that details the changes that have taken place since the 1.1.0 release. Downloads: http://jakarta.apache.org/~rleland/ValidatorAlpha/1.1.1 Just a reminder : The release process is following the same general procedures established for the Apache HTTPD project http://httpd.apache.org/dev/release.html and Jakarta Commons products http://jakarta.apache.org/commons/releases/, and utilize the HTTPD numbering scheme. The release will initially be given an Alpha status and made available through the Release Manager's home directory. Pursuant to a Majority Vote on the /commons-dev/ Mailing List, the release may be moved to the public release directory. The vote may also serve to reclassify the release to be of *Beta* or *General Availability* (GA) quality, as defined by the Apache HTTPD project. Subsequent votes may reclassify the release, either to promote it or to demote it, as need be. Rob
[Vote] Release of Commons Validator 1.1.1
For the moment I have withdrawn commons-validator, and we'll take a vote on its release, see bottom. The following release plan is proposed for Validator 1.1.0: * /Tag Date/ - Tuesday, December 15, 2003, 02:00:00 EST * /Release Manager/ - Robert Leland * /Alpha Release Announcement/ - To the following mailing list: o [EMAIL PROTECTED] o [EMAIL PROTECTED] * /Beta/General Release Announcement/ - To the following mailing lists: o [EMAIL PROTECTED] o [EMAIL PROTECTED] o [EMAIL PROTECTED] o [EMAIL PROTECTED] o [EMAIL PROTECTED] The release process shall follow the same general procedures established for the Apache HTTPD project http://httpd.apache.org/dev/release.html and Jakarta Commons products http://jakarta.apache.org/commons/releases/, and utilize the HTTPD numbering scheme. The release will initially be given an Alpha status and made available through the Release Manager's home directory. Pursuant to a Majority Vote on the /commons-dev/ Mailing List, the release may be moved to the public release directory. The vote may also serve to reclassify the release to be of *Beta* or *General Availability* (GA) quality, as defined by the Apache HTTPD project. Subsequent votes may reclassify the release, either to promote it or to demote it, as need be. Issues There are currently 3 outstanding Bugs reports http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22781 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20579 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22124 Bug 20579 22124 Both deal with the Email validation. Unit tests have been added to cover these items so tests fail. I propose that these bugs be marked LATER and addressed in a follow up release. Known existing Struts validator applications work correctly, in both english and in French. Using Mozilla 1.4 IE 6. It has also been tested undet the latest tomcat 3.3.1a, and Tomcat 4.1.29 This Release contains the same jar dependencies as the 1.1.0 release: commons-beanutils 1.6.1 commons-collections 2.1 commons-digester 1.5 commons-logging 1.0.3 oro 2.0.7 xml-apis 2.0.2 junit 3.8.1 Finally I propose that we release the tip of the main trunk in CVS as Commons Validator 1.1.1. A set of release notes has been uploaded to the validator web site. http://jakarta.apache.org/commons/validator/tasks.html Voting will end Sunday December 21, 12 Noon. --- Vote: Commons Validator 1.1.1 Release [ ] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). --- -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Release of Commons Validator 1.1.1
Noel J. Bergman wrote: Vote: Commons Validator 1.1.1 Release [ ] +1 I am in favor of the release, and will help support it [X] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). Questions: Did you read http://httpd.apache.org/dev/release.html under the Oops section? As you cut 1.l.1-alpha, the code for that version is frozen (and tagged in CVS). So if there were problems requiring a change, the eventual Release build would have another version number. Did we adopt that policy? Yes, the code is tagged, and if there are any problems we just rev to 1.1.2. Essentially, once there is approval. I'll just make the same 1.1.1 version that was available before. Can we please clear up the difference between the nomenclature used by HTTP Server and the established nomenclature on the Jakarta download pages? Do I interpret this approach as being post Milestone, and part of the process for certifying a Release build? --- 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: [validator] API docs missing from site
Phil Steitz wrote: The links to both the legacy 1.0.2 and current (maven report) javadocs are currently broken on the validator site. Looks like the API docs have been moved or deleted. Phile, Fixed, Thanks ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] EmailTest failing
Peter Courcoux wrote: Hi all, I did a fresh checkout of validator this evening and the EmailTest failed. Your correct, those tests were added as a reminder to review the RFC822.txt and handle cases of specialized characters in the users name. Most of the time the character string needs to be commented. Unfortunately, I have not had time lately to go back and added this to the regular expressions. I'll look into this myself when I have a moment. However, I Patches or code review is always welcome ! thought I'd ask if this is a known issue? I didn't see anything in the archives. Regards, -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Company Acknowledgements [was :Re: [HiveMind] 1.0 Beta]
[EMAIL PROTECTED] wrote: Robert Leland [EMAIL PROTECTED] wrote on 05/11/2003 01:52:48 PM: [snip] (Maven has some hidden acknowledgments in it's plug-in docs) says you I saw them back in September at the very bottom of page the PMD plugin docs: http://maven.apache.org/reference/plugins/pmd/ And last but not least - thanks to Together Teamlösungen http://www.together.at for their support of Open Source Software and their contributions such as Enhydra Application Server 5.0 (Aonyx) http://www.enhydra.org and a couple of Maven plugins. The last part about Enhydra Application Server 5.0 (Aonyx) http://www.enhydra.org make it look like an advertisement, because I don't know what that has to do with tem PMD plugin. -Rob Huh, what are these hidden acknowldegments? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Company Acknowledgements [was :Re: [HiveMind] 1.0 Beta]
Howard M. Lewis Ship wrote: So, what would you propose? Strip HiveMind out of the sandbox CVS? Track down any backup mirrors and erase them? Kidnap its users and brain wash them? You've acknowledged that when you commit any code to Apache you give up ownership of that code. Also what is said on the Web site is governed by the same Apache license. In order to endorse any product or company on an Apache web site there needs to be written permission from the Apache Foundation. The fact that no other company is officially endorsed (Maven has some hidden acknowledgments in it's plug-in docs) says you are asking for a new precedent to be set. While you certainly could make suggestions in the negotiating terms, if that is what the Apache Foundation member, wants to do, is not your responsibility. It is your responsibility to bring this matter to the Apache Foundation as a good steward. Also plain committers like us are not Apache Foundation members. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com
Company Acknowledgements [was :Re: [HiveMind] 1.0 Beta]
[EMAIL PROTECTED] wrote: Once it goes beta, I'll start monitoring the user list as well as the developer list. Unless beta coincides with promotion to top level, in which case there will be a hivemind-user and hivemind-dev lists. WebCT will be getting back to me soon to finalize the wording for promotion (I developed HiveMind partially on their time, so they have a say -- they want to ensure they get proper credit). You will also probably need to get guidance from the Apache Foundation, on Acknowledging WebCT before moving HiveMind to Commons/Jakarta level. [EMAIL PROTECTED] Many companies like Sun/IBM have contributed many man years of labor to Jakarta Projects and they just get very minimal acknowledgment. http://jakarta.apache.org/site/acknowledgements.html If WebCT requires the acknowledgment to be larger than the existing acknowledgments for Sun/IBM for example and Apache isn't as a whole won't allow it,...and you agree then a viable alternative might be to move the project elsewhere like Source Forge. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: float ( 0.8 and 0.9 ) struts validator problem
flavio mendes rabelo wrote: Hi, I have the following problem. I need validate the type float. when i type values equal the 0.8 or 0.9 these values are not considered float number; but if I type y.8 or y.9 ( y 0 ) or only .8 or .9 the validation is ok, the problem is whe I use the format x.8 or x.9 ( x = 0 ). My struts configuration files is ok. thanks This is fixed in the CVS head version of Validator. The nightly version of Struts uses this version. It was also fixed in version 1.1.0 of validator released in August, which at this time is considered an 'Alpha'. Found at http://jakarta.apache.org/~rleland/ValidatorAlpha Flavio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] Password fields [WAS] Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateMaxLength.js validateMinLength.js
David Graham wrote:
It is inherently insecure to reveal the specific details of password
validation in client side scripting. Validator and Struts should be as
secure as possible out of the box so I am -1 on this change. Please
revert the changes until we come up with a better solution. Bugzilla
isn't the easiest place to have this discussion so it might be better
suited for commons-dev.
I thought that the length was only revealed in the error message but it is
indeed shown in snippets like:
this.maxlength='4'; this.minlength='4';
I agree that the best solution at the moment is not to use validator on
password forms.
David
Also the server side validations reveal max/min lengths, there.
Currently, the validator server side
validations are loosely coupled. A solution would be to prevent the user
from using max/min length
checks either client or server side would increase coupling. One
possible attempt to solve this
by placing an optional attribute for the user to tell us that the field is
a password so we could disallow maxlength or minlength would not work
because they would just
not mark the field as a 'password'.
A proactive step might be to have the generated javascript create a
dialog if the field is a
'password' field and it attempts to validate a max/minlength constraint.
It would warn them that
validating max/min fields is discouraged. A client side validation would
be allowed by setting parameter
in the html:javascript tag. This would catch both client side and
server side cases, given that javascript
is enabled.
Generally though I believe it would be cleanest if the commons-validator
didn't dictate what field types
could/could not be validated. This decision could be left up to the
enclosing framework, as I described
above.
--- [EMAIL PROTECTED] wrote:
rleland 2003/10/06 20:00:15
Modified:
validator/src/javascript/org/apache/commons/validator/javascript
validateMaxLength.js validateMinLength.js
Log:
Bug#: 12473
Let max/min length also cover passwords fields.
If users don't want the password min/max parameters
revealed then they shouldn't use the validator.
Currently in struts the min/max values are still
in the html, anyway. There is no easy/clean workaround.
Just don't use validator.
Revision ChangesPath
1.3 +4 -3
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js
Index: validateMaxLength.js
===
RCS file:
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMaxLength.js,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- validateMaxLength.js 15 Aug 2003 20:22:03 - 1.2
+++ validateMaxLength.js 7 Oct 2003 03:00:15 - 1.3
@@ -13,6 +13,7 @@
var field = form[oMaxLength[x][0]];
if (field.type == 'text' ||
+field.type == 'password' ||
field.type == 'textarea') {
var iMax = parseInt(oMaxLength[x][2](maxlength));
1.4 +4 -3
jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js
Index: validateMinLength.js
===
RCS file:
/home/cvs/jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript/validateMinLength.js,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- validateMinLength.js 15 Aug 2003 20:22:03 - 1.3
+++ validateMinLength.js 7 Oct 2003 03:00:15 - 1.4
@@ -13,6 +13,7 @@
var field = form[oMinLength[x][0]];
if (field.type == 'text' ||
+field.type == 'password' ||
field.type == 'textarea') {
var iMin = parseInt(oMinLength[x][2](minlength));
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New commons proper component - pcollections
Stephen Colebourne wrote: There is an additional point, in that [collections] is very widely dispersed and used. To increase its size by over 100% suggests that something should at least be looked at. This is not an issue. If a class is not used it will not be be loaded into the JVM. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] Password fields [WAS] Re: cvs commit: jakarta-commons/validator/src/javascript/org/apache/commons/validator/javascript validateMaxLength.js validateMinLength.js
David Graham wrote: The validation rules are only exposed if you use Struts' html:javascript Not true they are exposed by server side validation also. The error messages clearly state the min/max values. I'm still -1 on this last commit for the reasons stated. Please revert this change to not validate password fields in the javascript. +1, will do it tomorrow. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/iterators ArrayListIterator.java
Phil Steitz wrote:
jakarta-commons\collections\data\test
seems to have test data with a version number. My guess is cloning the
data and substuting
NullComparator.version2.obj2
NullComparator.version3.obj
Might work
The changes to getCompatabilityVersion() below seem to be causing the
compatability tests to fail. I am getting errors like the following now:
[java] 1)
testEmptyListCompatibility(TestCommonsLinkedList.testEmptyListCompatibility)
java.io.FileNotFoundException:
data/test/CommonsLinkedList.emptyCollection.version3.0.obj (No such
file or directory)
[java] at java.io.FileInputStream.open(Native Method)
[java] at
java.io.FileInputStream.init(FileInputStream.java:106)
[java] at
java.io.FileInputStream.init(FileInputStream.java:66)
[java] at
org.apache.commons.collections.AbstractTestObject.readExternalFormFromDisk(AbstractTestObject.java:317)
[java] at
org.apache.commons.collections.AbstractTestList.testEmptyListCompatibility(AbstractTestList.java:974)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[java] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
I have no clue how to fix this(other than to change the values
back to 2.2, which makes the problem go away ;-)
I am also now getting multiple failures for TestHashBidiMap.
Phil
[EMAIL PROTECTED] wrote:
scolebourne2003/10/05 16:21:07
Modified:collections/src/test/org/apache/commons/collections
TestNodeCachingLinkedList.java
TestCommonsLinkedList.java
collections/src/test/org/apache/commons/collections/comparators
TestBooleanComparator.java
collections/src/java/org/apache/commons/collections/comparators
BooleanComparator.java
collections/src/java/org/apache/commons/collections/iterators
ArrayListIterator.java
Log:
Update version numbers for next release
Revision ChangesPath
1.7 +3 -3
jakarta-commons/collections/src/test/org/apache/commons/collections/TestNodeCachingLinkedList.java
Index: TestNodeCachingLinkedList.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/TestNodeCachingLinkedList.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- TestNodeCachingLinkedList.java5 Oct 2003 21:23:21 -1.6
+++ TestNodeCachingLinkedList.java5 Oct 2003 23:21:07 -1.7
@@ -89,7 +89,7 @@
}
public String getCompatibilityVersion() {
-return 2.2;
+return 3.0;
}
public void testShrinkCache() {
1.6 +3 -3
jakarta-commons/collections/src/test/org/apache/commons/collections/TestCommonsLinkedList.java
Index: TestCommonsLinkedList.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/TestCommonsLinkedList.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- TestCommonsLinkedList.java5 Oct 2003 21:11:06 -1.5
+++ TestCommonsLinkedList.java5 Oct 2003 23:21:07 -1.6
@@ -88,7 +88,7 @@
}
public String getCompatibilityVersion() {
-return 2.2;
+return 3.0;
}
public void setUp() {
1.5 +3 -3
jakarta-commons/collections/src/test/org/apache/commons/collections/comparators/TestBooleanComparator.java
Index: TestBooleanComparator.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/comparators/TestBooleanComparator.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- TestBooleanComparator.java1 Oct 2003 22:14:48 -1.4
+++ TestBooleanComparator.java5 Oct 2003 23:21:07 -1.5
@@ -103,7 +103,7 @@
}
public String getCompatibilityVersion() {
-return 2.2;
+return 3.0;
}
// tests
-
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: cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester/plugins InitializableRule.java
[EMAIL PROTECTED] wrote:
rdonkin 2003/10/04 05:27:37
Added: digester/src/java/org/apache/commons/digester/plugins
InitializableRule.java
I feel like the license police :-} but this is an Apache 1.0 license,
eventhough it says version 1.1
compare it to the one stored under commons.
http://jakarta.apache.org/commons/license
-Rob
Log:
Added plugins module. Submitted by Simon Kitching.
Revision ChangesPath
1.1 jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/InitializableRule.java
Index: InitializableRule.java
===
/*
*
*
* 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 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/.
*
*/
package org.apache.commons.digester.plugins;
/**
* Defines an interface that a Rule class can implement if it wishes to get an
* initialisation callback after the rule has been added to the set of Rules
* within a PluginRules instance.
*
* @author Simon Kitching
*/
public interface InitializableRule {
/**
* Called after this Rule object has been added to the list of all Rules.
* Note that if a single InitializableRule instance is associated with
* more than one pattern, then this method will be called more than once.
*
* @param pattern is the digester match pattern that will trigger this
*rule.
* @exception PluginConfigurationException is thrown if the InitializableRule determines that
*it cannot correctly initialise itself for any reason.
*/
public void postRegisterInit(String pattern)
throws PluginConfigurationException;
}
-
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: cvs commit: jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/web/servlet/config ChainServlet.java
This is a Apache 1.0 License, The give away is it mentions 'Apache Group' [EMAIL PROTECTED] wrote: husted 2003/09/29 08:34:45 Added: chain/src/java/org/apache/commons/chain/web/servlet/config ChainServlet.java Log: Generic ChainSerlvet to allow loading a Catalog in any servlet environment. Contributed by Matthew J. Sgarlata, Revision ChangesPath 1.1 jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/web/servlet/config/ChainServlet.java Index: ChainServlet.java === /* * $Header: /home/cvs/jakarta-commons-sandbox/chain/src/java/org/apache/commons/chain/web/servlet/config/ChainServlet.java,v 1.1 2003/09/29 15:34:45 husted Exp $ * $Revision: 1.1 $ * $Date: 2003/09/29 15:34:45 $ * * * * 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 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/. * */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Maven build and elements of style
Brent Worden wrote: There are a few FIXME comments. I've configured my Eclipse to mark FIXMEs, but the out-of-the-box config highlights only TODOs. Can we agree on a common style here? I've been placing @todo messages inside javadoc comments. PRO: Maven can generate a task list report based on those tags. CON: They show up as warnings in the javadoc report. (I haven't looked to see if I can disable this). Borland popularized the @todo, which I use. Maven, or one of the plug-ins, also recognized the 'TODO:' so there are no javadoc warnings.
Re: [HiveMind] releases
Howard M. Lewis Ship wrote: I'm going to add two more features and then call it beta. #1: Parameters for Interceptors. #2: resource translator (translators are used for conversions during XML to Java conversion). Since its in the sandbox, I don't believe I can or should put a release up on Apache. I think comcast gives me some personal web site space; for the meantime I see about setting up downloads there. Since the bandwidth would be small it would probably be ok to put it under http://jakarta.apache.org/~hship/hivemind We are doing that for commons-validator http://jakarta.apache.org/~rleland/ValidatorAlpha/ while it is at 1.1.0 state and is still declared an alpha. When it is voted to a Beta state we'll move it to the proper directories so it can be mirrored, and make an anouncement on the commons-user list as well. -Rob I also want to get HiveMind building under Gump soon; then I'll put together a proposal to graduate it into commons proper. It's mature enough now to form a real community around it. I'm beginning to open people's eyes at work as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Commons-Validator 1.1.0 Alpha released
Commons Validator 1.1.0 Alpha is now available for testing. Please refer to http://jakarta.apache.org/commons/validator/tasks.html that details some of the changes that have taken place since the 1.0.2 release. Downloads: http://jakarta.apache.org/~rleland/ValidatorAlpha/ Just a reminder : The release process is following the same general procedures established for the Apache HTTPD project http://httpd.apache.org/dev/release.html and Jakarta Commons products http://jakarta.apache.org/commons/releases/, and utilize the HTTPD numbering scheme. The release will initially be given an Alpha status and made available through the Release Manager's home directory. Pursuant to a Majority Vote on the /commons-dev/ Mailing List, the release may be moved to the public release directory. The vote may also serve to reclassify the release to be of *Beta* or *General Availability* (GA) quality, as defined by the Apache HTTPD project. Subsequent votes may reclassify the release, either to promote it or to demote it, as need be. Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Release of Commons Validator
Henri Yandell wrote: I never meant you didn't count ! I also see what you mean about other commons committers being more important, since they tend to be more objective when they do speak up. -Rob Heh. I always took it the other way. +1 votes from the project itself are non-binding and +1 votes from another commons committer are binding :) The point of the vote is to get commons community approval, before a vote is even called every member of the particular project should be in favour of it. However, the rules just say that you need 3 +1 votes from any commons committer, so when I fail to get +1 votes from non-project committers I include those from project committers and grumble about no one caring. Interesting difference in view :) Hen On Tue, 26 Aug 2003, Robert Leland wrote: I counted 2 +1 binding votes, and 1 +1 votes from another commons committer. I will cut the release tonight, test it, and upload it to the mirrors sometime this week. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Release of Commons Validator
robert burrell donkin wrote: hi rob could you remember to cc the pmc next time? Thanks, and I will do that next time. I just sent out an email to [EMAIL PROTECTED] Thanks again, Rob every release needs to be approved and this is the most convenient way to make sure any pmc folks who aren't subscribed to commons-dev get the chance to veto. BTW the usual convention in the commons is to prefix [RESULT] to emails of this kind. it makes it a bit easier for people to spot them. - robert On Tuesday, August 26, 2003, at 06:16 PM, Robert Leland wrote: I counted 2 +1 binding votes, and 1 +1 votes from another commons committer. I will cut the release tonight, test it, and upload it to the mirrors sometime this week. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[doc] release.html Feedback
I am going through the release process for Commons-Validator. After cutting the proposed release I took a look at the items marked 'LATER' There was some really good stuff/patches that were contributed that were rotting away. As a result I suggest adding a new Major Section Titled something like: 'Post Release' or 'Preparing for next development Phase' After the release several steps need to be performed to transition back to development phase. 0) Update the project pages with new documentation for the just release code. 1) Change all Bugzilla items marked 'LATER' to 'New' . Or review all 'LATER' items selectively changing these items to 'NEW'. 2) Change the version in the build.xml or project.xml to the next release number and add a development status. For example, 1.1.0 - 1.1.1-dev -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] release.html Feedback
Robert Leland wrote: How about RTFM. I see that these items are covered. :-} ! -Rob
Re: [Vote] Release of Commons Validator
Robert Leland wrote: robert burrell donkin wrote: hi rob could you remember to cc the pmc next time? Thanks, and I will do that next time. I just sent out an email to [EMAIL PROTECTED] I ment to say [EMAIL PROTECTED] Thanks again, Rob every release needs to be approved and this is the most convenient way to make sure any pmc folks who aren't subscribed to commons-dev get the chance to veto. BTW the usual convention in the commons is to prefix [RESULT] to emails of this kind. it makes it a bit easier for people to spot them. - robert On Tuesday, August 26, 2003, at 06:16 PM, Robert Leland wrote: I counted 2 +1 binding votes, and 1 +1 votes from another commons committer. I will cut the release tonight, test it, and upload it to the mirrors sometime this week. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Release of Commons Validator
I counted 2 +1 binding votes, and 1 +1 votes from another commons committer. I will cut the release tonight, test it, and upload it to the mirrors sometime this week. -Rob
[Vote] Release of Commons Validator
Commons Validator has recently undergone refactoring with a few bugs fixed and documentation updates. The following release plan is proposed for Validator 1.1.0: * /Tag Date/ - Tuesday, August 25, 2003, 23:59:59 * /Release Manager/ - Robert Leland * /Alpha Release Announcement/ - To the following mailing list: o [EMAIL PROTECTED] * /Beta/General Release Announcement/ - To the following mailing lists: o [EMAIL PROTECTED] o [EMAIL PROTECTED] o [EMAIL PROTECTED] The release process shall follow the same general procedures established for the Apache HTTPD project http://httpd.apache.org/dev/release.html and Jakarta Commons products http://jakarta.apache.org/commons/releases/, and utilize the HTTPD numbering scheme. The release will initially be given an Alpha status and made available through the Release Manager's home directory. Pursuant to a Majority Vote on the /commons-dev/ Mailing List, the release may be moved to the public release directory. The vote may also serve to reclassify the release to be of *Beta* or *General Availability* (GA) quality, as defined by the Apache HTTPD project. Subsequent votes may reclassify the release, either to promote it or to demote it, as need be. Issues There are currently 3 outstanding Bugs reports http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20432 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20579 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22124 Bug 20432 - The original bug was fixed, and another user reported a similar problem, but at a line number that looked unlikely. Bug 20579 22124 Both deal with the Email validation. Unit tests have been added to cover these items so tests fail. I propose that these bugs be marked LATER and addressed in a follow up release 1.1.1. (NOTE Voting +1 for this release is also Voting for a 1.1.1, which maintains the compatability code) Known existing Struts validator applications work correctly, in both english and in French. Using Mozilla 1.4 IE 6. For this Release I also propose we update the jar dependencies to be on the latest Commons release namely: commons-beanutils 1.6.1 commons-collections 2.1 commons-digester 1.5 commons-logging 1.0.3 oro 2.0.7 xml-apis 2.0.2 junit 3.8.1 Finally I propose that we release the tip of the main trunk in CVS as Commons Validator 1.1.0. A preliminary set of release notes has been uploaded to the validator web site. http://jakarta.apache.org/commons/validator/tasks.html --- Vote: Commons Validator 1.1.0 Release [ ] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). --- -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201
Re: [validator] Release 1.1.0
Arun Thomas wrote: I noticed that a vote is ongoing for release of validator. FYI, http://jakarta.apache.org/commons/dtds/validator_1_1.dtd should be updated to the version of the dtd currently in CVS. I don't know if this is a manual process, or something that happens automatically with the release? done. Thanks, this would have slipped by at release time. For now it's manual I am sure there must be an easier way then e-mailing myself and saving away. The site talks about using CVS for the Apache sites, but I don't see it. Hopefully as we Mavenize the site more we will be able to have this performed automatically. -AMT - 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: Release Process for Sandbox Projects
Leo Sutic wrote: From: Stephen Colebourne [mailto:[EMAIL PROTECTED] As a warning, my concerns would be the speed of passage through the sandbox. You need to think if you have a community to maintain this in commons proper, and whether people have had enough time to review it. My understanding was that I needed to go to commons proper before even sending out an alpha release. This put me in If you use the Major.Minor.Maintenance numbering scheme you can avoid -initially- calling your software alpha/beta etc ... It would be 0.4.0 developer release, limited release, general release, ie Alpha, Beta, Gamma/Production quality. It avoids the stigma that comes with the label Alpha. Also I believe it also avoids the version inflation that happens, version 1.0 - 3.0 in 6 months or less. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [resources] plans...?
Stephen Colebourne wrote: I have my own code at work that does resource management. From the quick look I took at [resources] it was more flexible, so in my dream world of infinite time to work on commons, I was going to add stuff to [resources]. Ideas include: - Main interface supports direct access to multiple types of resource: - String - List of Strings - Map (ordered) of String to Strings - XML structure There is an XML implementation of this already and a DB version at www.sf.net/projects/struts - perhaps others, such as Integer, Boolean, and any other bean - Resource chaining - To allow multiple files to be merged into one (an 'extends' keyword for resources) - for a large product where the product has a fixed base configuration, and users should override the base configuration rather than change it Anyone know where I can buy an infinite time machine;-) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator - Draft Release Proposal] Release of Commons Validator
David Graham wrote: --- Robert Leland [EMAIL PROTECTED] wrote: Validator Commons Committers I need your feedback. Commons Validator has recently undergone refactoring with a few bugs fixed and documentation updates. As of today the unit tests pass, and known existing applications work correctly. There are currently 3 outstanding Bugs reports http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20432 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20579 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22124 Bug 20432 - The original bug was fixed, and another user reported a similar problem, but at a line number that looked unlikely. Bug 20579 22124 Both deal with the Email validation. After checking the RFC to verify that these Bug reports are valid. I will add unit tests to cover these items so tests fail. I propose that these bugs be addressed before the next release. They must be marked either FIXED or INVALID. They can also be marked as LATER which I think is more appropriate. The tests fail now which means the email bugs are valid so they should be marked LATER and fixed for 1.1.1. I would like to address them before the release. Also now that the javascript validation functions are in Validator I would like to unit test them also. -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201
Re: [docs] Crappy build system
Henri Yandell wrote: Jakarta Commons build system for the website is very very crappy. Regardless of whether things move to Maven or some other look and feel, I'd like to check in the jars needed so that people don't have to go around hunting in jakarta-velocity, jakarta-site2 and who knows where else. Contributions are always welcome, then maybe the Commons build system for the web site will go from being very very crappy, to just crappy. ;-) ! Could you elaborate on this ? When you say jars what are you referring to ? Is anyone against this? Is there some reason for the current confusing setup? We didn't have you to help us out before :-) ! Hen -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] moving commons-sql, commons-dbcp and commons-dbutils todb.apache.org
Costin Manolache wrote: Martin Poeschl wrote: as the name indicates db.apache.org is for db related projects. the db project is new but people will look for db related stuff there and not at jakarta-commons .. so it makes sense to move the projects to db.apache.com And people who are already use it will look for it in jakarta-commons. I know tomcat uses ( and bundles ) commons-dbcp.jar, and I would preffer it remains in jakarta-commons. For the others - I don't care. It seems keeping the package name org.apache.commond.dbcp is the most important, for now. Automatically redirecting the page http://jakarta.apache.org/commons/dbcp.html to db.apache.org/dbcp should be trasparent. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] moving commons-sql, commons-dbcp and commons-dbutils todb.apache.org
Costin Manolache wrote: Robert Leland wrote: Costin Manolache wrote: Martin Poeschl wrote: as the name indicates db.apache.org is for db related projects. the db project is new but people will look for db related stuff there and not at jakarta-commons .. so it makes sense to move the projects to db.apache.com Again - why should we do this ? I assume this was proposed to conform to the Apache wide reorginization, that has been happening over the last few months. Organizing by functionality not by language. Probably approved by a vote of PMC. +1, I see it as opening our windows to let some fresh air, and ideas in. Also look at: http://commons.apache.org/ It look like there will be a reorganization of all commons components. At this moment I'm -1 for commons-dbcp.jar, and -0 on the others. Moving code for the sake of moving code is wrong - you won't increase the community or the quality of the code by moving it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jelly] move codebase to commons proper
Rodney Waldhoff wrote: Assuming you want the same directory structure under jakarta-commons you have under jakarta-commons-sandbox, simply executing: cp -r jakarta-commons-sandbox/jelly jakarta-commons/. should suffice to move the files and yet preserve the history. Later we can do a CVS remove on the sandbox version. You may want to tar up jakarta-commons-sandbox/jelly first, just in case. What if someone is in the middle of a CVS commit ? You may want to broadcast a 'do not COMMIT' message. Also you may want to do a mv jakarta-commons-sandbox/jelly jakarta-commons-sandbox/jelly-hide First to stop any CVS operations from happening during the copy. This also runs the risk of corruption, but it is smaller. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESOURCES] Units tests rely on JDK 1.4
Craig R. McClanahan wrote: On Thu, 9 Jan 2003, Robert Leland wrote: Date: Thu, 09 Jan 2003 17:09:48 -0500 From: Robert Leland [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: Jakarta Commons Users List [EMAIL PROTECTED] Subject: [RESOURCES] Units tests rely on JDK 1.4 Same as before but for Units tests. Locale(language), doesn't exist under JDK 1.3, only under 1.4. As with the cases in the mainline code, this was fixed in the 20030109 nightly build (i.e. last night's). I just did a CVS update ~4:45 P.M. EST, so it was fixed after that time ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [RESOURCES] Units tests rely on JDK 1.4
Robert Leland wrote: As with the cases in the mainline code, this was fixed in the 20030109 nightly build (i.e. last night's). I just did a CVS update ~4:45 P.M. EST, so it was fixed after that time ? Nope, not there. I just did another CVS update and ResourceBundleTestCase.java still uses JDK 1.4 constructors. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[RESOURCES] Units tests rely on JDK 1.4
Same as before but for Units tests. Locale(language), doesn't exist under JDK 1.3, only under 1.4. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[resources] depends on Java 1.4
Doesn't compile under Java 1.3. The constructor Locale(String language) Was introduced in JDK 1.4 Locale(String language, String country) Exists in 1.3 In impl/CollectionResourcesBase() -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[resources]new dependant [discovery] build problems.
In trying to build resources, I was unable to build it because the discovery junit tests failed on the jelly-plugin. I tried building discovery using both the commons-discovery maven build, and the commons maven build. It appears my top level build.properties for commons is current, but then again that is only used for direct ant builds ?!? If others can build discovery then I'll continue to root around in my build environment until I find the problem. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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
