[dbcp] Javadoc "{*link Foo}"?

2014-07-19 Thread Gary Gregory
Is there something special being done with the funky format for Javadocs that look like "{*link Foo}" as opposed to "{@link Foo}"? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Seco

Re: [CSV] Naming pattern of getters and setters in CSVFormat (was: Re: [VOTE] Release Commons CSV 1.0 based on RC1)

2014-07-19 Thread Dipanjan Laha
Although i am not familiar with CSV's codebase, imho "get" is more straight forward, so +1 to Gary's suggestion. On Saturday, 19 July 2014, Gary Gregory wrote: > On Sat, Jul 19, 2014 at 12:14 PM, Emmanuel Bourg > wrote: > > > Le 19/07/2014 13:48, Gary Gregory a écrit : > > > > > Can we go back

[parent] publish version 35?

2014-07-19 Thread Gary Gregory
Any thoughts on publishing it? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action

Re: [pool] Usage of logging API in common-pool ?

2014-07-19 Thread Gary Gregory
I just had a case today actually, where I had to unroll PoolUtils.prefill and add logging before each call to addObject(). Quite a shame to be forced to do that because pool does not log. In the end, this helped me debug my problem but now, I'm leave the code unrolled of course. IMO, pool is a mid-

Re: [pool] Usage of logging API in common-pool ?

2014-07-19 Thread Phil Steitz
On 7/18/14, 2:18 PM, Anthony Communier wrote: > Hello, > > There are some parts of the code that use printStackTrace in order to show > errors. It means that it's difficult to have control on how log will be > produced. Those stacks will mainly go to application server logs and not > directly into

Re: [CSV] Naming pattern of getters and setters in CSVFormat (was: Re: [VOTE] Release Commons CSV 1.0 based on RC1)

2014-07-19 Thread Gary Gregory
On Sat, Jul 19, 2014 at 12:14 PM, Emmanuel Bourg wrote: > Le 19/07/2014 13:48, Gary Gregory a écrit : > > > Can we go back to use "get"? > > We are running in circles Gary, Benedikt and I, if others could weigh in > that would help. > Circles, back and forth, to and fro, call it what you will. I

Re: [VOTE] Release Commons DbUtils 1.6 based on RC2

2014-07-19 Thread Benedikt Ritter
My +1 FTR Benedikt > Am 16.07.2014 um 21:52 schrieb Benedikt Ritter : > > We have fixed quite a few bugs and added some significant enhancements > since DbUtils 1.5 was released in 2012, so I would like to release DbUtils > 1.6 based on RC2. > > Note on RC1: From the archives it looks lik

Re: [CSV] Naming pattern of getters and setters in CSVFormat (was: Re: [VOTE] Release Commons CSV 1.0 based on RC1)

2014-07-19 Thread Emmanuel Bourg
Le 19/07/2014 13:48, Gary Gregory a écrit : > Can we go back to use "get"? We are running in circles Gary, Benedikt and I, if others could weigh in that would help. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@com

Re: [CSV] Naming pattern of getters and setters in CSVFormat (was: Re: [VOTE] Release Commons CSV 1.0 based on RC1)

2014-07-19 Thread Gary Gregory
Using *ing and *ed versions are worse IMO. *ed like isHeaderRecordSkipped makes it sound like we are asking if something has happened in the past. *ing ( isSkippingHeaderRecord) makes is sounds like you are controlling something that is happening right now. I think it might make the getter methods

[CSV] Naming pattern of getters and setters in CSVFormat (was: Re: [VOTE] Release Commons CSV 1.0 based on RC1)

2014-07-19 Thread Benedikt Ritter
... moving this to a new thread. so how do we reach consensus here? :o) if(format.isSkippingHeaderRecord()) { ... } sounds better to me than if(format.isHeaderRecordSkipped) { ... } Gary made up a good argument about using active voice in method names. How ever there will be the asymmetry b

[CSV] Rename isIgnoreEmptyHeaders? (was: Re: [VOTE] Release Commons CSV 1.0 based on RC1)

2014-07-19 Thread Benedikt Ritter
... moving this to a new thread. The name isIgnoreEmptyHeaders seems to cause confusion, since in this case an entry in the header is meant and not the whole header (like in skipHeaderRecord) The JavaDoc of isIgnoreEmptyHeaders is: /** * Specifies whether empty headers are ignored when