commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject [OT-ish rant] Whither Ant and Maven? Was Re: [POOL] can the CheckedObjectPool be removed when introducing Java5 generics?
Date Tue, 12 Oct 2010 15:39:07 GMT
  )
>>
>
> 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.tripodi@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.tripodi@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.steitz@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.tripodi@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<gudnabrsam@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message