Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=2&projectId=296
Build statistics:
State: Failed
Previous Build: No previous build.
Started at: Sun 12 Jan 2014 23:20:57 +
Finished at: Sun 12 Jan 2014 23:21:12 +
Total time: 15s
Build Trig
On 12 January 2014 15:49, Mark Thomas wrote:
> On 12/01/2014 03:06, sebb wrote:
>> I've been trying to add a Continuum build for the 1_5 branch, but it won't
>> take.
>
> Assuming 1.4.x and 1.3.x will be auto-generated from 1.5.x you should
> probably be replacing 1.4.x with 1.5.x
>
>> This may p
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=27776&projectId=296
Build statistics:
State: Failed
Previous Build: No previous build.
Started at: Sun 12 Jan 2014 23:00:04 +
Finished at: Sun 12 Jan 2014 23:00:21 +
Total time: 17s
Build Trig
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=27775&projectId=295
Build statistics:
State: Failed
Previous Build: No previous build.
Started at: Sun 12 Jan 2014 22:54:24 +
Finished at: Sun 12 Jan 2014 22:54:39 +
Total time: 14s
Build Trig
On 12 January 2014 17:33, Benedikt Ritter wrote:
> Hi,
>
> someone (I guess sebb) has cleaned up trunk. There is some commented out
> code in OpenVmsProcessingEnvironment and DefaultProcessingEnvironment? Any
> reason we keep it?
It has only been tested on Windows and Unix. It really ought to be
On 1/12/14, 6:10 AM, Luc Maisonobe wrote:
> Le 12/01/2014 14:57, Thomas Neidhart a écrit :
>> Hi,
>>
>> in MATH-1070 we have discovered that calling Precision.round(x, y)
>> behaves differently for float and double values when the value to be
>> rounded is negative zero:
>>
>> Precision.round(-0.0d
Go for it!
G
Original message
From: Benedikt Ritter
Date:01/12/2014 14:15 (GMT-05:00)
To: Commons Developers List
Subject: [dbcp] Adopt maven conventions?
Hi,
while looking through the commit mails, I saw that dbcp does not follow
maven conventions. Instead the code is
On 1/12/14, 9:46 AM, Mark Thomas wrote:
> On 12/01/2014 17:33, Phil Steitz wrote:
>> I am curious why we have a 1.5 branch. Are there new features (not
>> just bug fixes) relative to 1.3/1.4 in there?
> JDBC 4.1 support.
>
>> Also, do you guys think it might be time to officially drop 1.3?
> No ob
Hi,
while looking through the commit mails, I saw that dbcp does not follow
maven conventions. Instead the code is packaged like this:
src/java/org.apache.dbcp2
src/test/org.apache.dbcp2
>From what I know, you plan to roll out a new major release soon. Maybe this
is a good opportunity to change
On 1/12/14, 6:03 AM, Thomas Neidhart wrote:
> Hi,
>
> we had some preliminary discussion about changing the
> BinominalConfidenceInterval class in MATH-1086.
>
> Right now the class provides some non-static methods to create various
> ConfidenceIntervals, and I was proposing to change them to be st
On 12/01/2014 17:33, Phil Steitz wrote:
> I am curious why we have a 1.5 branch. Are there new features (not
> just bug fixes) relative to 1.3/1.4 in there?
JDBC 4.1 support.
> Also, do you guys think it might be time to officially drop 1.3?
No objection from me.
> Getting the the combined 1.3
I am curious why we have a 1.5 branch. Are there new features (not
just bug fixes) relative to 1.3/1.4 in there?
Also, do you guys think it might be time to officially drop 1.3?
Getting the the combined 1.3/1.4 release scripts to work in the new
regime is not something that I personally look for
Hi,
someone (I guess sebb) has cleaned up trunk. There is some commented out
code in OpenVmsProcessingEnvironment and DefaultProcessingEnvironment? Any
reason we keep it? I've checked Clirr, it seems to be happy with the
changes.
Benedikt
--
http://people.apache.org/~britter/
http://www.system
Am 12.01.2014 10:43, schrieb Stefan Bodewig:
> On 2014-01-11, Oliver Heger wrote:
>
>> There is a problem with the source distribution: It deflates in a
>> directory "commons-compress-1.6-src"; so here the version number is
>> wrong. Not sure whether this is blocking or not - in any case, it is
>>
The Apache Commons Team is pleased to announce the availability of
Apache Commons BeanUtils 1.9.1.
The Apache Commons BeanUtils library is a component that provides easy
to use wrappers around the Java Reflection and Introspection capabilities.
Release 1.9.1 is a bug fix release which solves a pr
On 12/01/2014 03:06, sebb wrote:
> I've been trying to add a Continuum build for the 1_5 branch, but it won't
> take.
Assuming 1.4.x and 1.3.x will be auto-generated from 1.5.x you should
probably be replacing 1.4.x with 1.5.x
> This may perhaps be due to the fact that the 1_4 branch also uses t
+1 for hiding. If the internal classes were shaded from another artifact
they wouldn't appear in the Javadoc, so let's be consistent and hide
anything not meant for public usage.
Emmanuel Bourg
Le 12/01/2014 14:34, sebb a écrit :
> On 12 January 2014 10:18, Stefan Bodewig wrote:
>
> I think it
Le 12/01/2014 14:57, Thomas Neidhart a écrit :
> Hi,
>
> in MATH-1070 we have discovered that calling Precision.round(x, y)
> behaves differently for float and double values when the value to be
> rounded is negative zero:
>
> Precision.round(-0.0d, 0) = 0.0
> Precision.round(-0.0f, 0) = -0.0
>
Hi,
we had some preliminary discussion about changing the
BinominalConfidenceInterval class in MATH-1086.
Right now the class provides some non-static methods to create various
ConfidenceIntervals, and I was proposing to change them to be static.
Another option would be to allow sub-classing by
Hi,
in MATH-1070 we have discovered that calling Precision.round(x, y)
behaves differently for float and double values when the value to be
rounded is negative zero:
Precision.round(-0.0d, 0) = 0.0
Precision.round(-0.0f, 0) = -0.0
The reason being that in the double case, the value is converted
I think I would leave it in.
Would it not be helpful to people trying to understand the code?
We could also generically hide or _color_ differently this kind of package from
the parent POM.
Gary
Original message
From: Stefan Bodewig
Date:01/12/2014 05:18 (GMT-05:00)
To:
On 12 January 2014 10:18, Stefan Bodewig wrote:
> Compress holds a package that is public as an implementation detail but
> whose API isn't meant for public consumption. The javadocs of said
> package state this in bold letters.[1]
>
> Current trunk will even go further and hide the package from
Compress holds a package that is public as an implementation detail but
whose API isn't meant for public consumption. The javadocs of said
package state this in bold letters.[1]
Current trunk will even go further and hide the package from javadoc,
but the only class inside is still refered to by
On 2014-01-11, Gary Gregory wrote:
> The reports look good BUT I think the NEW code should have better code
> coverage. There seems to be some non-trivial code that is not tested
> at all.
AFAICS this is mostly handling cases that are difficult to create test
data for.
* Snappy with literals lon
On 2014-01-11, Oliver Heger wrote:
> There is a problem with the source distribution: It deflates in a
> directory "commons-compress-1.6-src"; so here the version number is
> wrong. Not sure whether this is blocking or not - in any case, it is
> confusing.
Ouch. Emmanuel told me I forgot to upda
25 matches
Mail list logo
