Hi all,
sorry to join late the conversation but looks like living in a
different timezone *is* an issue :(
I am the person "physically" responsable of the pool2 "big
refactoring" and I would be very sorry to see all that work dropped or
be useless; if you follow the old pool2 discussion in this ML
On 23/03/2011 08:33, Simone Tripodi wrote:
> Hi all,
> sorry to join late the conversation but looks like living in a
> different timezone *is* an issue :(
No need to apologise. I wasn't going to go ahead until you had a chance
to give your feedback.
> I am the person "physically" responsable of
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-vfs2 has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-scxml-test has an issue affecting its community integration.
This
Thanks a lot Mark, much more than appreciated :)
I'm +1 to support your idea of moving the current pool2 code in a
branch, then continue the 1.5.5 work. The useful part that IMHO can be
backported are the use of generics, replacing primitive constants with
enumerations, removing some useless wrappe
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
Hi all guys,
looks like there's not enough activity/interest on new Digester, I
suggest to suspend this topic for a while and come speaking about it
until there will be interest from the users.
Thanks to all that took part of the discussion!
All the best, have a nice day,
Simo
http://people.apache
On 23/03/2011 11:00, Simone Tripodi wrote:
> Thanks a lot Mark, much more than appreciated :)
> I'm +1 to support your idea of moving the current pool2 code in a
> branch, then continue the 1.5.5 work. The useful part that IMHO can be
> backported are the use of generics, replacing primitive consta
On Wed, Mar 23, 2011 at 6:37 AM, Simone Tripodi
wrote:
> Hi all guys,
> looks like there's not enough activity/interest on new Digester, I
> suggest to suspend this topic for a while and come speaking about it
> until there will be interest from the users.
> Thanks to all that took part of the dis
Do we need to worry about leaking memory here due to things never
getting removed from _poolMap, _poolList?
Also, IIUC what is going on here, we need to make a similar change
the evict() where the last instance in a keyed pool is evicted.
Thanks for fixing this.
Phil
---
Phil,
I believe all the pool issues for 1.5.x have been resolved. Over to
you... :)
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On 3/23/11 12:36 PM, Mark Thomas wrote:
> Phil,
>
> I believe all the pool issues for 1.5.x have been resolved. Over to
> you... :)
>
Thanks! You are awesome, Mark!
I will finish reviewing your last set of commits and then roll an RC.
Did you see my (hopefully baseless) memory leak fear about th
On 23/03/2011 19:54, Phil Steitz wrote:
> On 3/23/11 12:36 PM, Mark Thomas wrote:
>> Phil,
>>
>> I believe all the pool issues for 1.5.x have been resolved. Over to
>> you... :)
>>
> Thanks! You are awesome, Mark!
>
> I will finish reviewing your last set of commits and then roll an RC.
>
> Did
On 23/03/2011 17:46, Phil Steitz wrote:
> Do we need to worry about leaking memory here due to things never
> getting removed from _poolMap, _poolList?
I don't think so. The entries should only exit in _poolMap and _poolList
while associated objects exist.
> Also, IIUC what is going on here, we n
On 3/23/11 2:01 PM, Mark Thomas wrote:
> On 23/03/2011 17:46, Phil Steitz wrote:
>> Do we need to worry about leaking memory here due to things never
>> getting removed from _poolMap, _poolList?
> I don't think so. The entries should only exit in _poolMap and _poolList
> while associated objects ex
On 23 March 2011 22:09, wrote:
> Author: simonetripodi
> Date: Wed Mar 23 22:09:07 2011
> New Revision: 1084776
>
> URL: http://svn.apache.org/viewvc?rev=1084776&view=rev
> Log:
> groupId inherited from parent pom
That is true, but I think it's best to be specific in this case.
The wrong groupId
On Fri, Mar 11, 2011 at 11:50 PM, Niall Pemberton
wrote:
> On Fri, Mar 11, 2011 at 11:38 PM, Niall Pemberton
> wrote:
>> On Fri, Mar 11, 2011 at 4:34 PM, sebb wrote:
>>> On 11 March 2011 09:42, Niall Pemberton wrote:
On Fri, Mar 11, 2011 at 3:37 AM, sebb wrote:
> On 11 March 2011 01:1
I think maven best practice would suggest to avoid groupId duplication
- for pool2 we agreed to switch to o.a.c groupId.
which problems are you speaking about? I'm asking because I would have
missed something I don't know yet.
BTW, the MavenIDE suggested me suppressing the groupId duplication:
De
On 23 March 2011 23:14, Simone Tripodi wrote:
> I think maven best practice would suggest to avoid groupId duplication
> - for pool2 we agreed to switch to o.a.c groupId.
> which problems are you speaking about? I'm asking because I would have
> missed something I don't know yet.
I just mean that
On Thu, Mar 24, 2011 at 12:28 AM, sebb wrote:
> On 23 March 2011 23:14, Simone Tripodi wrote:
>> I think maven best practice would suggest to avoid groupId duplication
>> - for pool2 we agreed to switch to o.a.c groupId.
>> which problems are you speaking about? I'm asking because I would have
>>
Hi Matt!!!
I noticed 2 important points I'd like to discuss:
1) generally speaking, the bigger part of the users are lazy: they
just want to grab latest released artifact of XXX component with Maven
and use it, so it is hard to obtain feedbacks from APIs not released
yet;
2) committers/PMCs intere
Hi all guys,
I just got an error in my OSGi environment because
commons-logging-1.1.1 doesn't have the required OSGi metadata in the
MANIFEST.
Would you agree on releasing a 1.1.2 just to add this metadata?
Many thanks in advance!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org
On Wed, Mar 23, 2011 at 11:55 PM, Simone Tripodi
wrote:
> Hi all guys,
> I just got an error in my OSGi environment because
> commons-logging-1.1.1 doesn't have the required OSGi metadata in the
> MANIFEST.
> Would you agree on releasing a 1.1.2 just to add this metadata?
Theres a note on Commons
On 23 March 2011 23:37, Simone Tripodi wrote:
> On Thu, Mar 24, 2011 at 12:28 AM, sebb wrote:
>> On 23 March 2011 23:14, Simone Tripodi wrote:
>>> I think maven best practice would suggest to avoid groupId duplication
>>> - for pool2 we agreed to switch to o.a.c groupId.
>>> which problems are y
On Thu, Mar 24, 2011 at 12:05 AM, sebb wrote:
> On 23 March 2011 23:37, Simone Tripodi wrote:
>> On Thu, Mar 24, 2011 at 12:28 AM, sebb wrote:
>>> On 23 March 2011 23:14, Simone Tripodi wrote:
I think maven best practice would suggest to avoid groupId duplication
- for pool2 we agreed
On 24 March 2011 00:09, Niall Pemberton wrote:
> On Thu, Mar 24, 2011 at 12:05 AM, sebb wrote:
>> On 23 March 2011 23:37, Simone Tripodi wrote:
>>> On Thu, Mar 24, 2011 at 12:28 AM, sebb wrote:
On 23 March 2011 23:14, Simone Tripodi wrote:
> I think maven best practice would suggest t
On Wed, Mar 23, 2011 at 6:50 PM, Simone Tripodi
wrote:
> Hi Matt!!!
> I noticed 2 important points I'd like to discuss:
>
> 1) generally speaking, the bigger part of the users are lazy: they
> just want to grab latest released artifact of XXX component with Maven
> and use it, so it is hard to obt
27 matches
Mail list logo
