Hi Boris,
Boris Unckel wrote on Tuesday, April 03, 2007 6:50 PM:
> Hello Simon,
>
> Simon Kitching wrote:
>> Would you both mind explaining what benefits you see in a new JCL
>> implementation that cannot be obtained via java.util.logging?
>>
> this is possible already today with x4juli, it doe
+1
Oliver Zeigermann wrote on Tuesday, April 03, 2007 9:18 AM:
> +1 to all said. I could even help.
>
> -0 to waiting until we have a clear idea about the rest of Jakarta as
> this is likely to never happen. Maybe a clearer idea will form after
> commons leaves Jakarta.
>
> Oliver
>
> 2007/4
Henri Yandell wrote on Tuesday, April 03, 2007 10:36 PM:
> On 4/3/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
>> I've got a question: If we have commons.apache.org, what will be the
>> difference to jakarta.apache.org, apart from the missing projects?
>> Why do we expect that c.a.p will work, a
[
https://issues.apache.org/jira/browse/IO-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486600
]
Henri Yandell commented on IO-77:
-
This proposed method wouldn't change if NIO was used, that would be a change in
the un
Change forceDelete API to return the boolean success
Key: IO-118
URL: https://issues.apache.org/jira/browse/IO-118
Project: Commons IO
Issue Type: Improvement
Affects Versions: 1.3.1
Author: oheger
Date: Wed Apr 4 01:56:08 2007
New Revision: 525463
URL: http://svn.apache.org/viewvc?view=rev&rev=525463
Log:
Updated dependency to commons-dbcp to avoid problems with jdbc-stdext in m2
build
Modified:
jakarta/commons/proper/configuration/trunk/build.xml
jakarta/commons/p
Author: oheger
Date: Wed Apr 4 03:46:33 2007
New Revision: 525488
URL: http://svn.apache.org/viewvc?view=rev&rev=525488
Log:
Added an additional test for HierarchicalConfiguration.clearTree() after a
report on the user list
Modified:
jakarta/commons/proper/configuration/trunk/src/test/org/
[
https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated LANG-326:
-
Fix Version/s: 3.0
Priority: Minor (was: Major)
> StringUtils: startsWith / endsWith / st
StringUtils: startsWith / endsWith / startsWithIgnoreCase / endsWithIgnoreCase
/ removeStartIgnoreCase / removeEndIgnoreCase methods
Key: LANG-326
[
https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated LANG-326:
-
Attachment: LANG-326-Start-End-With.patch
> StringUtils: startsWith / endsWith / startsWithIgnoreCa
On 4/3/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
Would you guys be open to a patch to implement a periodic cleanup of
abandoned connections
the following logic can cause abandoned connections to sit around
forever, just because you are not hitting the max in the pool.
Using a DB like
[
https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated LANG-326:
-
Attachment: LANG-326-Start-End-With-2.patch
Apologies - hadn't refreshed my local copy before creat
[
https://issues.apache.org/jira/browse/LANG-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated LANG-326:
-
Attachment: (was: LANG-326-Start-End-With.patch)
> StringUtils: startsWith / endsWith / startsW
As we ramp up to a 1.2 release, I think its a good idea to move to
Maven 2 as the standard build. That means "deprecating" the m1 build
(leaving in the 1.2 release, if possible), moving the site and
nightlies, etc.
Lets view this as lazy consensus - i.e., scream now or forever hold
your peace.
+0
Al
- Original Message
From: Phil Steitz <[EMAIL PROTECTED]>
To: Jakarta Commons Developers List
Sent: Wednesday, April 4, 2007 8:56:06 AM
Subject: [math] Proposal: move build to m2
As we ramp up to a 1.2 release, I think its a good idea to move to
Maven 2 as the standard build. Tha
"Henri Yandell" <[EMAIL PROTECTED]> writes:
>I think the end should be nigh for Jakarta (those on private@ will
>have seen a thread in which I side-topic'd with the feeling that the
>end should be nigh for Jakarta). Previously I've suggested that
>Commons should flatten into Jakarta and that Jakar
"Henri Yandell" <[EMAIL PROTECTED]> writes:
>On 4/2/07, Phil Steitz <[EMAIL PROTECTED]> wrote:
[...]
>> +1 for only Java components (flame away, this is just my HO)
>Yep - though in reality this means:
>"We'll do whatever the community wants to do. If someone proposes a
>Ruby library and we ha
On 4/4/07, Al Chou <[EMAIL PROTECTED]> wrote:
+0
Great to hear from you, Al!
As we start working toward 1.2, it would be great if you could "throw
some eyeballs" (to hack a French phrase ;-) on the Mantissa stuff that
has been moved into trunk. Thanks!
Phil
Author: oheger
Date: Wed Apr 4 10:02:45 2007
New Revision: 52
URL: http://svn.apache.org/viewvc?view=rev&rev=52
Log:
Set version numbers to 1.4 for rc2
Modified:
jakarta/commons/proper/configuration/trunk/default.properties
jakarta/commons/proper/configuration/trunk/pom.xml
j
Author: oheger
Date: Wed Apr 4 10:04:37 2007
New Revision: 525556
URL: http://svn.apache.org/viewvc?view=rev&rev=525556
Log:
Tagging 1.4rc2
Added:
jakarta/commons/proper/configuration/tags/CONFIGURATION_1_4RC2/
- copied from r52, jakarta/commons/proper/configuration/trunk/
--
The 2nd release candidate for Commons Configuration 1.4 is available for
inspection at
http://people.apache.org/~oheger/commons-configuration-1.4rc2/
The site can be found at
http://people.apache.org/~oheger/commons-configuration-1.4rc2/site/
The following has been changed since rc1:
- A license
Author: oheger
Date: Wed Apr 4 10:09:05 2007
New Revision: 525557
URL: http://svn.apache.org/viewvc?view=rev&rev=525557
Log:
Rolled back version numbers to 1.4-SNAPSHOT
Modified:
jakarta/commons/proper/configuration/trunk/default.properties
jakarta/commons/proper/configuration/trunk/pom.
Definite +1 for moving to m2. I moved [net] to m2 a while back, and it's been
all good so far.
Rory
"Jakarta Commons Developers List" wrote:
>
> As we ramp up to a 1.2 release, I think its a good idea to move to
> Maven 2 as the standard build. That means "deprecating" the m1 build
> (leavi
Definite +1 for moving to m2. I moved [net] to m2 a while back, and it's been
all good so far.
Rory
"Jakarta Commons Developers List" wrote:
>
> As we ramp up to a 1.2 release, I think its a good idea to move to
> Maven 2 as the standard build. That means "deprecating" the m1 build
> (leavi
Definite +1 for moving to m2. I moved [net] to m2 a while back, and it's been
all good so far.
Rory
"Jakarta Commons Developers List" wrote:
>
> As we ramp up to a 1.2 release, I think its a good idea to move to
> Maven 2 as the standard build. That means "deprecating" the m1 build
> (leavi
Definite +1 for moving to m2. I moved [net] to m2 a while back, and it's been
all good so far.
Rory
"Jakarta Commons Developers List" wrote:
>
> As we ramp up to a 1.2 release, I think its a good idea to move to
> Maven 2 as the standard build. That means "deprecating" the m1 build
> (leavi
[
https://issues.apache.org/jira/browse/DBCP-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486713
]
Markus Krogemann commented on DBCP-146:
---
This issue is currently rated 'minor' but is a very important issue for
[
https://issues.apache.org/jira/browse/IO-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486716
]
Holger Hoffstätte commented on IO-77:
-
NIO can potentially be optimized by the OS to be zero-copy, i.e. without
const
Phil Steitz wrote:
> As we ramp up to a 1.2 release, I think its a good idea to move to
> Maven 2 as the standard build. That means "deprecating" the m1 build
> (leaving in the 1.2 release, if possible), moving the site and
> nightlies, etc.
>
> Lets view this as lazy consensus - i.e., scream now
Test for idle time exceeded in borrowObject
Key: POOL-99
URL: https://issues.apache.org/jira/browse/POOL-99
Project: Commons Pool
Issue Type: Improvement
Affects Versions: 1.3
Rep
[
https://issues.apache.org/jira/browse/POOL-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486735
]
Rob Eamon commented on POOL-86:
---
With respect to all the constraints on what can be done to the code, the
resolution to t
Phil Steitz wrote:
As we ramp up to a 1.2 release, I think its a good idea to move to
Maven 2 as the standard build. That means "deprecating" the m1 build
(leaving in the 1.2 release, if possible), moving the site and
nightlies, etc.
Lets view this as lazy consensus - i.e., scream now or foreve
Phil Steitz wrote:
> I have also been looking at the *great* progress getting the
> Mantissa stuff in and will propose that we move to a 1.2 release.
> Looks about ready to bundle up in terms of contents previously
> discussed, other than the setter injection stuff that I will add. Do
> you feel
+1
Henri Yandell wrote:
I think the end should be nigh for Jakarta (those on private@ will
have seen a thread in which I side-topic'd with the feeling that the
end should be nigh for Jakarta). Previously I've suggested that
Commons should flatten into Jakarta and that Jakarta should become a
gen
I took a while to get the m2 multi project release build working but
I am glad to announce...
We got "a" first release candiate :)
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
commons/commons-jci/1.0-RC1/
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
On 4/4/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote:
"Henri Yandell" <[EMAIL PROTECTED]> writes:
>So with that said - I'd like to propose that we move to commons.apache.org.
+1 to that, -0 to the name.
"commons" is too generic. There is already an XML commons and I could
We alre
On 4/4/07, Luc Maisonobe <[EMAIL PROTECTED]> wrote:
Phil Steitz wrote:
> I have also been looking at the *great* progress getting the
> Mantissa stuff in and will propose that we move to a 1.2 release.
> Looks about ready to bundle up in terms of contents previously
> discussed, other than the s
Can anyone say what the usual practice is for assigning groups/roles
for people once they become a committer?
Theres a "Jakarta Developer" group - it gets you "committer" role for
Commons Lang and JCI but strangely nothing else.
Would be simpler if it was documented somewhere.
Niall
--
+1 on the TLP vote
In message <[EMAIL PROTECTED]>, =?iso-88
59-1?Q?J=F6rg_Schaible?= writes:
>I never got why things like ECS, ORO, regexp are not part of commons. =
>What makes them different to logging or digester? I can understand the =
>separation for something like POI, but not necessarily f
I wrote:
>+1 on the TLP vote
s/vote/idea/
will vote +1 when the actual vote is held.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+1 to everything in your email. There's lots of room for 'finished' or
'maintenance' as it seems to be called more often. We've already got
that in Commons in Discovery and Attributes at the very least.
Hen
On 4/4/07, Daniel F. Savarese <[EMAIL PROTECTED]> wrote:
For at least ORO, there has be
On 4/4/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
Can anyone say what the usual practice is for assigning groups/roles
for people once they become a committer?
Theres a "Jakarta Developer" group - it gets you "committer" role for
Commons Lang and JCI but strangely nothing else.
Would be sim
On 4/4/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
On 4/4/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> Can anyone say what the usual practice is for assigning groups/roles
> for people once they become a committer?
>
> Theres a "Jakarta Developer" group - it gets you "committer" role for
> C
On 4/4/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
On 4/4/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
> On 4/4/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> > Can anyone say what the usual practice is for assigning groups/roles
> > for people once they become a committer?
> >
> > Theres a "J
On 4/4/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On 4/4/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
> On 4/4/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > On 4/4/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> > > Can anyone say what the usual practice is for assigning groups/roles
> >
Niall Pemberton wrote:
On 4/4/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
On 4/4/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
> On 4/4/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> > Can anyone say what the usual practice is for assigning groups/roles
> > for people once they become a commit
On 4/4/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Niall Pemberton wrote:
> On 4/4/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
>> On 4/4/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
>> > On 4/4/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
>> > > Can anyone say what the usual practice is for
On 4/4/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Niall Pemberton wrote:
>
> "Commons Committer" group --> commiter role on all components
> "Jakarta PMC" --> pmc role on all jakarta sub-projects
This sound good to me. Then as Henri said, we should set up a new
Permission Scheme. We now h
Henri Yandell wrote:
On 4/4/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Niall Pemberton wrote:
>
> "Commons Committer" group --> commiter role on all components
> "Jakarta PMC" --> pmc role on all jakarta sub-projects
This sound good to me. Then as Henri said, we should set up a new
Permi
On 4/4/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Username:
[EMAIL PROTECTED]
ah, so not the dennislundberg one. :) I was a bit confused at that one
not being a jakarta developer.
While you're in there, you should delete your doppelganger and assign
its reported issue over to your real us
Phil Steitz wrote:
On 4/3/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
Would you guys be open to a patch to implement a periodic cleanup of
abandoned connections
the following logic can cause abandoned connections to sit around
forever, just because you are not hitting the max in the p
On 4/4/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
On 4/4/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
> Username:
> [EMAIL PROTECTED]
ah, so not the dennislundberg one. :) I was a bit confused at that one
not being a jakarta developer.
While you're in there, you should delete your doppelg
Possibiblity to define eviction policies
Key: POOL-100
URL: https://issues.apache.org/jira/browse/POOL-100
Project: Commons Pool
Issue Type: New Feature
Environment: N/A
Reporter:
"Henri Yandell" <[EMAIL PROTECTED]> writes:
[...]
>My long term thinking for how this would be handled is:
>Multiple PMCs, one website. So we'd have Java Commons, Ruby Commons,
>BobsYourUncle Commons PMCs, and they'd all share a commons.apache.org
>website.
>Does that make you less wary of our
On 4/4/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On 4/4/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
>
> On 4/4/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
>
> > Username:
> > [EMAIL PROTECTED]
>
> ah, so not the dennislundberg one. :) I was a bit confused at that one
> not being a jakart
On 4/5/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
On 4/4/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> On 4/4/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
> >
> > On 4/4/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
> >
> > > Username:
> > > [EMAIL PROTECTED]
> >
> > ah, so not the dennisl
Filip Hanik - Dev Lists wrote:
Phil Steitz wrote:
On 4/3/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
Would you guys be open to a patch to implement a periodic cleanup of
abandoned connections
the following logic can cause abandoned connections to sit around
forever, just because you
Refactor use of FileCleaner into plugable strategy to allow overriding.
---
Key: FILEUPLOAD-133
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-133
Project: Commons FileUpload
On 4/4/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On 4/4/07, Luc Maisonobe <[EMAIL PROTECTED]> wrote:
> Phil Steitz wrote:
>
You were only in the "Jira User" group - I've added a "committer role"
for Commons Math issues for you which should get you going for the
time being as I'm not sure wh
[
https://issues.apache.org/jira/browse/MATH-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brent Worden updated MATH-157:
--
Fix Version/s: 1.2
> Add support for SVD.
>
>
> Key: MATH-157
>
[
https://issues.apache.org/jira/browse/MATH-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brent Worden updated MATH-156:
--
Fix Version/s: 1.2
> Brent solver is non-optimal, because it doesn't use the user's guess.
>
[
https://issues.apache.org/jira/browse/MATH-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brent Worden updated MATH-120:
--
Fix Version/s: 1.2
> [math][patch] Pascal / Negative Binomial Distribution
>
On 4/4/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote:
"Henri Yandell" <[EMAIL PROTECTED]> writes:
>On 4/2/07, Phil Steitz <[EMAIL PROTECTED]> wrote:
[...]
>> +1 for only Java components (flame away, this is just my HO)
>Yep - though in reality this means:
>"We'll do whatever the co
On 4/4/07, Oliver Heger <[EMAIL PROTECTED]> wrote:
The 2nd release candidate for Commons Configuration 1.4 is available for
inspection at
http://people.apache.org/~oheger/commons-configuration-1.4rc2/
The site can be found at
http://people.apache.org/~oheger/commons-configuration-1.4rc2/site/
T
64 matches
Mail list logo
