)
Why would anyone not use maven!!! ;)
http://s.apache.org/m3blog
...joking aside though - if people are prepared to maintain the ant
builds (and I am for the components I work on) then no need to get rid
of them.
OK, I have now been baited ;) I was going to post the response
below to your "preparing for m3" note, but decided it might be, um,
taken the wrong way.
Most of you know me well enough to know that when I say stupid
things I usually actually mean them but it is not hard to get me to
see the error of my ways, so here goes...
------------------------------------------------------------------
First, thanks Niall for doing the analysis and prep work. As with
all things apache, at the end of the day them that does the work
determine the way, so if there is sufficient energy to move to m3, I
say go for it.
On the other hand, I think it is worth thinking about what we are
trying to accomplish with Maven, how much time we collectively want
to put into it and what it means to our users. I have to confess
that when I think about a) how much time we collectively spend
fussing with the build b) how hard it is for new RMs to create and
deploy RCs and c) how little we actually know about who in the user
community builds our code and how they do it, there are moments when
I think we would be better off going back to simple Ant builds. (I
generally get over this after a good "mvn clean site" experience, so
consider the last bit an emotional rant :) I cringe though each time
we dump an Ant build, thinking about users who may be relying on it.
More seriously, it seems we have four possibly conflicting goals
when it comes to our use of Maven:
0) We are part of the Maven community - have been since 1.x days and
as part of that community, we want to use the new stuff and help
improve it.
1) We want minimally sites and as much as possible other parts of
commons component builds to be standardized so it is easier to work
across components and for people to get involved. Here we need to
keep thinking KISS or as I sometimes say "keep it not mysterious."
Personally, I think the complex maven setup we have violates that
all over the place. I don't know what to do about it. I know POM
inheritance is beautiful, etc, but between the inherited bits, the
local setup files, profiles and incantations, its hard for even
experienced commons developers to keep it all straight. Maybe m3
will make it simpler??
2) We want to reduce manual work and associated errors.
3) We want our components to be correctly published in Maven repos.
What disturbs me a little is that only goal 3) really helps users
and I am not even sure how many of them it does. If our focus in 1)
is really breaking down barriers to entry for contributors, that
might lead to a simpler setup and even some kind of split between
build infrastructure that ships with our releases and just builds
jars (maybe just Ant) and more exotic stuff for RMs. Unfortunately,
that creates more work for us, which is exactly what we are trying
to avoid via build automation.
OK, rant over. Back to our regularly scheduled program. I guess I
can at least be thankful for the fact that due to so much fun with
POM changes, I seem to qualify as some sort of XML expert in the
all-seeing eyes of Ohloh - he he.
Phil
Niall
P.S. I only just found the Apache URL shortening service, which is cool:
http://blogs.apache.org/infra/entry/s_apache_org_uri_shortening
Phil
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
---------------------------------------------------------------------
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
