> -----Original Message----- > From: Phil Steitz [mailto:phil.ste...@gmail.com] > Sent: Monday, October 11, 2010 16:42 > To: Commons Developers List > Subject: Re: [POOL] can the CheckedObjectPool be removed when introducing > Java5 generics? > > On 10/11/10 7:29 PM, Gary Gregory wrote: > >> -----Original Message----- > >> From: Phil Steitz [mailto:phil.ste...@gmail.com] > >> Sent: Monday, October 11, 2010 16:13 > >> To: Commons Developers List > >> Subject: Re: [POOL] can the CheckedObjectPool be removed when introducing > >> Java5 generics? > >> > >> On 10/11/10 6:40 PM, Gary Gregory wrote: > >>> This is odd, I get: > >>> > >>> [INFO] ------------------------------------------------------------------- > -- > >> --- > >>> [ERROR] BUILD FAILURE > >>> [INFO] ------------------------------------------------------------------- > -- > >> --- > >>> [INFO] Compilation failure > >>> > >>> > >> > \Users\ggregory\b\svn\apache.org\commons\pool\src\test\org\apache\commons\pool > >> \TestPoolUtils.java:[496,21] reference to prefill is ambiguous, both > >> method<K,V>prefill(org.apac > >>> he.commons.pool.KeyedObjectPool<K,V>,K,int) in > >> org.apache.commons.pool.PoolUtils and > >> > method<K,V>prefill(org.apache.commons.pool.KeyedObjectPool<K,V>,java.util.Coll > >> ection<K>,i > >>> nt) in org.apache.commons.pool.PoolUtils match > >>> > >>> > >> > \Users\ggregory\b\svn\apache.org\commons\pool\src\test\org\apache\commons\pool > >> \TestPoolUtils.java:[506,17] reference to prefill is ambiguous, both > >> method<K,V>prefill(org.apac > >>> he.commons.pool.KeyedObjectPool<K,V>,K,int) in > >> org.apache.commons.pool.PoolUtils and > >> > method<K,V>prefill(org.apache.commons.pool.KeyedObjectPool<K,V>,java.util.Coll > >> ection<K>,i > >>> nt) in org.apache.commons.pool.PoolUtils match > >>> > >>> > >> > \Users\ggregory\b\svn\apache.org\commons\pool\src\test\org\apache\commons\pool > >> \TestPoolUtils.java:[514,17] reference to prefill is ambiguous, both > >> method<K,V>prefill(org.apac > >>> he.commons.pool.KeyedObjectPool<K,V>,K,int) in > >> org.apache.commons.pool.PoolUtils and > >> > method<K,V>prefill(org.apache.commons.pool.KeyedObjectPool<K,V>,java.util.Coll > >> ection<K>,i > >>> nt) in org.apache.commons.pool.PoolUtils match > >>> > >>> I am using Maven 2.2.1 with Oracle Java 1.6.0_21 on Windows Vista 64 bit. > >>> > >>> Ant does not build because it expects a specific version of JUnit to be in > >> place, which makes me wish we either did: > >>> - Ant and JUnit to the same way [IO] does it. > >>> - Remove the ant build. > >> > >> Thanks for patching the Ant build, Gary and thanks in advance for > >> fixing this problem :) > >> > >> I would really like to keep the Ant build working. > > > > In SVN: I fixed up the Ant build to use Junit jar from M2 local repository, > the same way we do for IO. Which makes me wonder if we should use Ivy for Ant > builds? Ideally, we should pick Ant or Maven, maintaining both it a pain. > > > > A mild pain for us, but important for the many, many users who do > not use Maven :) > > Phil
[lang] has ditched Ant in favor of Maven. I do not care which way we go, I like consistency and I like to avoid wasting time in maintenance. I am wondering if we should nudge Commons projects in the same direction [lang] has chosen? Just food for thought. Gary > > Gary > > > >> > >> Phil > >>> > >>> Gary > >>> > >>> -----Original Message----- > >>> From: Simone Tripodi [mailto:simone.trip...@gmail.com] > >>> Sent: Monday, October 11, 2010 14:44 > >>> To: Commons Developers List > >>> Subject: Re: [POOL] can the CheckedObjectPool be removed when introducing > >> Java5 generics? > >>> > >>> Hi Phil, all interested, > >>> I just committed r1021517 that contains the Generics feature, all tests > >> pass: > >>> > >>> Tests run: 256, Failures: 0, Errors: 0, Skipped: 0 > >>> > >>> [INFO] ------------------------------------------------------------------- > -- > >> --- > >>> [INFO] BUILD SUCCESS > >>> [INFO] ------------------------------------------------------------------- > -- > >> --- > >>> [INFO] Total time: 2:04.065s > >>> [INFO] Finished at: Mon Oct 11 23:32:07 CEST 2010 > >>> [INFO] Final Memory: 8M/508M > >>> [INFO] ------------------------------------------------------------------- > -- > >> --- > >>> > >>> Please take a look/review if you have some spire time, after that, if > >>> you agree, I'd like to start working on fixing/removing deprecations, > >>> just let me know. > >>> Thanks in advance, have a nice day, > >>> Simo > >>> > >>> http://people.apache.org/~simonetripodi/ > >>> http://www.99soft.org/ > >>> > >>> > >>> > >>> On Mon, Oct 11, 2010 at 10:43 PM, Simone Tripodi > >>> <simone.trip...@gmail.com> wrote: > >>>> Thanks for the support Phil!!! I'm going to terminate the work on > >>>> generics - the attached patch on the issue provided a small subset of > >>>> the whole feature - after that I already planned working on > >>>> deprecation stuff, I'm sure we can make the pool much easier. > >>>> Have a nice day, I'll keep you updated! > >>>> Simo > >>>> > >>>> http://people.apache.org/~simonetripodi/ > >>>> http://www.99soft.org/ > >>>> > >>>> > >>>> > >>>> On Mon, Oct 11, 2010 at 5:31 PM, Phil Steitz<phil.ste...@gmail.com> > wrote: > >>>>> Yep. Good point, Matt. Thanks! Simo pls do continue to point out > >> candidates for deprecation / removal. I would personally like to see pool > >> skinnied down a little in 2.0, with some of the specialized pools > introduced > >> to workaround problems in earlier impls removed. > >>>>> > >>>>> > >>>>> > >>>>> On Oct 10, 2010, at 9:09 PM, Simone Tripodi<simone.trip...@gmail.com> > >> wrote: > >>>>> > >>>>>> Thanks for your feedback Matt, > >>>>>> maybe I got blind because of the generics strong typing, but it would > >>>>>> make sense in he scenario when an existing ObjectPool<?> instance > >>>>>> doesn't expose the raw type. > >>>>>> Thanks, > >>>>>> Simo > >>>>>> > >>>>>> http://people.apache.org/~simonetripodi/ > >>>>>> http://www.99soft.org/ > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Sun, Oct 10, 2010 at 5:00 PM, Matt Benson<gudnabr...@gmail.com> > >> wrote: > >>>>>>> > >>>>>>> On Oct 10, 2010, at 9:14 AM, Simone Tripodi wrote: > >>>>>>> > >>>>>>>> Hi all pool team, > >>>>>>>> I've been working on introducing generics in the pool on trunk, I > >>>>>>>> noticed the CheckedObjectPool could lose its power when the pool will > >>>>>>>> use the generics. > >>>>>>> > >>>>>>> I don't work on [pool], but I would think that there would be a high > >> likelihood of a pool's being configured e.g. by a dependency injection > >> container, so IMO a checked pool is still relevant. > >>>>>>> > >>>>>>> -Matt > >>>>>>> > >>>>>>>> So, can this class (and relative static methods) be removed from > >>>>>>>> PoolUtils[1], or do you have suggestions why/how to maintain it? > >>>>>>>> Many thanks in advance, have a nice day, > >>>>>>>> Simo > >>>>>>>> > >>>>>>>> [1] > >> > https://svn.apache.org/repos/asf/commons/proper/pool/trunk/src/java/org/apache > >> /commons/pool/PoolUtils.java > >>>>>>>> > >>>>>>>> http://people.apache.org/~simonetripodi/ > >>>>>>>> http://www.99soft.org/ > >>>>>>>> > >>>>>>>> --------------------------------------------------------------------- > >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> --------------------------------------------------------------------- > >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> --------------------------------------------------------------------- > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>>>> > >>>>> > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org
