Re: [validator] Towards a release

2005-08-19 Thread Rob Leland
I believe I applied the form inheritance patch back in early 2004, and 
at the time we
were trying to get a stable version of Validator out for Struts 1.2.X 
series and creating the
Branch seemed the thing to do. 1.2 is also the version that David 
removed deprecated
methods so releasing  1.2 seemed like it could wait incase any more 
refactoring took place

that would further change the interface.

-Rob

David Graham wrote:


If I remember right, 1.2 (HEAD) includes form inheritance which wasn't
widely tested.  Niall might
remember more details.  I think releasing 1.2.0 from HEAD would be fine so
we don't have to go through the error prone process of maintaining two
branches.  Thanks for picking up the Validator torch!

David


--- Don Brown [EMAIL PROTECTED] wrote:

 


I'd like to get a release of commons-validator out the door, as Struts
1.3 would like to use some of its new bug fixes and features.

I'm pretty new to validator, so I'm not familar with its history.  Any
reason we haven't released 1.2?  In the past when I fixed bugs, folks
backported them to the 1.1.x branch; why not just roll 1.2 or at least
roll it in addition to a bug fix release for 1.1.x?

There are a couple more validator open bugs that I can sew up, if I
saw a release as a near-term possibility.

LMK, thanks,

Don

   



Get Firefox!
http://www.mozilla.org/firefox/




Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 



-
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: Migrate to SVN?

2004-11-26 Thread Rob Leland
Stephen Colebourne wrote:
I remain unenthused by SVN, probably because I don't have to manage a CVS
server. Effectively I'm -1, but I'm probably not going to fight.
My main reason is that SVN does not appear to be that widely adopted yet. A
sign that the time has come to migrate would be when Eclipse/Idea ships with
SVN support built in. At the moment, I fear we may just scare off some
potential users/contributers.
 

IntelliJ 5.0 will have subversion support and based on past history the 
EAP should have SVN within 2 months, I am hoping sooner.
JBuilder 11 has Subversion support also.


If we are moving though, I would want the pain all at once.
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [Resources] When is the next release?

2003-08-03 Thread Rob Leland
James Mitchell wrote:

Unless I did something wrong, my search for issues on bugzilla turns up
nothing, and I'm not sure what to make of issueTrackingUrl in project.xml.
Does it mean that we should be using
http://nagoya.apache.org/scarab/servlet/scarab/ or is it something that was
just carried over when someone was creating this file?
Using Maven to build and run the tests on this project fails.
* Running ant test (with appropriate build.properties) will compile and
test fine.
* Running maven will compile fine, but does not copy the required
.properties and
  .xml files needed by the tests.
I don't know enough about Maven to determine whether this is configuration
issue or a bug.
So, with that out of the way, what exactly is stopping us from releasing
commons-resources?
Do we need more tests?  Is there a checklist somewhere that I'm missing?
 

James:

Did anyone reply to this message, as to what needs to be done for a 
release ?



--
-
Rob Leland (703-525-3580)
Choose a job you love, and you will never have to work a day of your life.
 
-Confucius.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [DBCP] AbandonedTrace - Connection Recovery

2003-07-22 Thread Rob Leland
Danny Angus wrote:

Serge et al,

Further to my suggestion about using the Observer pattern for event
notification w.r.t. point 4 (below) I forgot to mention that it also has the
benefit of offering a compromise in the pro/anti recovery debate.
Existing contentious code designed to reclaim or test connections need not
be retired as it could still be made available re-factored into a listener,
and attached at runtime by the user. Users can use, extend or ignore DBCP's
own listeners at their discretion shifting the decision from the developers
to the users where, judging by the debate, it probably belongs.
I don't have a vote in DBCP... Using the Observer pattern seems a fine 
approach, especially since
the functionality was Voted on some time ago. Further, it sounds like 
you have tried to take others
concerns into account, and discussed the issue.

My 2 cents,

It also follows that DBCP need not then impose a single Jakarta-approved
strategy, but could easily be shipped with a number of implementations of
different strategies, chosen between and attached at runtime by the user or
by DBCP itself in response to configuration settings.
 

4. Provide some kind of extensible connection object that could allow
someone to add their own (possibly included but optional) way to recover
abandoned connections.
   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


 



--
Rob Leland


Re: [validator] regexp tests, patches for tests

2003-06-23 Thread Rob Leland
adam kramer wrote:

Hello all, never posted to the list, but I've been lurking for a bit.

Bug 17799
http://issues.apache.org/bugzilla/show_bug.cgi?id=17799
brought up that '/'s were not being escaped in regular expression patterns
(masks) so I decided to look into it. I found out that when I included
'/'s in the regexp value and did not escape them, a matching value for the
regexp passed regardless. I decided to formalize this with some unit tests
that cover one pattern with '/'s and another phone number pattern just to
verify that regexp pattern (masks) matching is working ok.
I've attached a RegexpTest.java file and another file of patches to get it
to run with 'ant test'. All tests are a go. If I should include patches
and new code in the body of the email just let me know. I figured it might
get passed up if I posted new code to bug database.
 

Some projects like it posted to the list like you have done, and other 
like a bugzilla report filed.
IN THIS CASE a Bugilla report is appropiate for Validator, I know it can 
be confusing, but please do
file a Bugilla report, an account , 
http://issues.apache.org/bugzilla/createaccount.cgi,
only takes 20 seconds and only required a valid email address from you.

-Rob


Thanks,
Adam Kramer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)

2003-06-19 Thread Rob Leland

Static methods are a necessary evil in OO languages and should be 
avoided when possible.  
I disagree. Static functions are similar to Aspect Oriented Programming, 
such as AspectJ which centrializes
code across many classes that is similar in functionality. This 
eliminates duplicate code, and increases maintainability.

http://www.eclipse.org/aspectj/

-Rob

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)

2003-06-19 Thread Rob Leland
David Graham wrote:

Static methods are a necessary evil in OO languages and should be 
avoided when possible.


I disagree. Static functions are similar to Aspect Oriented 
Programming, such as AspectJ which centrializes
code across many classes that is similar in functionality. This 
eliminates duplicate code, and increases maintainability.


I see no correlation between AOP and static methods, nor any 
correlation between static methods an increased code maintainability.  
There is nothing magic about static methods that make them more 
maintainable than non-statics.

David
Any time code is in --one-- place and not scattered across multiple 
classes this increases maintainability.
The fact that the methods are static is beside the point.

-Rob

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [RESOURCES] Units tests rely on JDK 1.4

2003-01-10 Thread Rob Leland
James Mitchell wrote:


I've been setting up a new email address today.  Has anyone looked at
this yet?


If you are subscribed to commons-dev you would see commits, I have not 
see commits on this item.
Also I had filed a bug report about 8pm EST last night and attached a patch,
put it on [digester] so be sure to update that bug report.

You have the power !

-Rob

 



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Commons fileupload build fails

2002-10-27 Thread Rob Leland
The commons fileupload nightly build for Oct 27, Sunday Morning
failed. The archive files are missing.
I also wasn't able to build from the CVS.

Luckly the sandbox version does build.

-Rob


--
To unsubscribe, e-mail:   mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org




Validator and Karma

2002-10-10 Thread Rob Leland

I am trying to fix a bug in the Validator code
for struts, and bring it up to date for logging.
It would help if I had karma to the commons.
Is that possible ?

-Rob


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]