> -----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. 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
