commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Crum <adri...@hlmksw.com>
Subject Re: [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:57:51 GMT
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.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
>
>

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


Mime
View raw message