I don't like Maven - I prefer Ant. My co-developer for the Commons
Convert project said that the use of Maven is almost a deal breaker for him.
Please keep Ant build file support in Commons.
-Adrian
On 10/12/2010 8:39 AM, Phil Steitz wrote:
)
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
