Am 24.10.2016 um 22:35 schrieb Oliver Heger:
Minor nit: As the field is now a constant, it should - according to the
Sun coding conventions - be named in uppercase: NO_INIT.
I thought that only applied to public constants, but I was wrong. I have
changed the field name.
Thanks,
Pascal
Am 23.10.2016 um 22:18 schrieb pascalschumac...@apache.org:
> Repository: commons-lang
> Updated Branches:
> refs/heads/master 96c8ea2fb -> dc53e49b4
>
>
> LANG-1144: Multiple calls of
> org.apache.commons.lang3.concurrent.LazyInitializer.initialize() are possible
>
> minimal clean-up
>
>
2016-10-24 21:03 GMT+02:00 Thomas Vandahl :
> Hi Romain,
>
> On 24.10.16 12:44, Romain Manni-Bucau wrote:
> > +1, thanks Thomas
> >
> > Side note: the tck module has been deactivated cause of packaging=pom but
> > ran it manually and all tests passed so not an issue for the
Hi Romain,
On 24.10.16 12:44, Romain Manni-Bucau wrote:
> +1, thanks Thomas
>
> Side note: the tck module has been deactivated cause of packaging=pom but
> ran it manually and all tests passed so not an issue for the release since
> we don't care of this artifact distribution, just here as a
On 21.10.16 19:42, Thomas Vandahl wrote:
> [X] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
My own vote.
Bye, Thomas
-
To unsubscribe,
+1
LieGrue,
strub
> Am 24.10.2016 um 14:36 schrieb Johannes Weberhofer
> :
>
>
>
> Am 21.10.2016 um 19:42 schrieb Thomas Vandahl:
>> I would like to beta-release the [jcs] component.
>>
>> Apache Commons JCS 2.0-beta-2 RC1 is available for review at:
>>
On 24 October 2016 at 07:34, Benedikt Ritter wrote:
> Hello Thomas
>
> Thomas Vandahl schrieb am So., 23. Okt. 2016 um 12:16 Uhr:
>
>> Hi Benedikt,
>>
>> On 23.10.16 10:51, Benedikt Ritter wrote:
>> > Hello Thomas,
>> >
>> > The build works with Java 8 and
I don't think we need to keep arguing this, when we discussed this
last time we said we'll do an intermediate Java 7-version - if there
are too many screams (I suspect almost none) then we can be more
careful before moving to Java 8 afterwards, which would give the
biggest benefit (and need more
On 24/10/16 14:26, Gilles wrote:
Hi.
[...]
The next step, then (I think) is that as a committer, I can submit a
proposal to get this idea established in the Incubator as a podling
for a
commons sub-project.
I suggest to use the sandbox, within "Commons".
Stupid queston: where do I find
Keeping open a maintenance branch for 3.5 sounds like a good idea. If it
really does end up taking over a year before a 3.6 release needs to be
made, then Java 6 may be a moot point by then. Either way, it sounds like
migrating to Java 7 for a 3.6 release isn't a bad idea unless it turns out
there
Le 23/10/2016 à 09:30, Gary Gregory a écrit :
> Thoughts?
If this means doing only trivial internal code changes with no benefit
to the end users then I don't think it's worth it. I would either stick
to Java 6 or go to Java 8 and offer some real new stuff.
Emmanuel Bourg
Hi.
[...]
The next step, then (I think) is that as a committer, I can submit a
proposal to get this idea established in the Incubator as a podling
for a
commons sub-project.
I suggest to use the sandbox, within "Commons".
Thanks!
The one technical question I have is whether it is okay
Am 21.10.2016 um 19:42 schrieb Thomas Vandahl:
I would like to beta-release the [jcs] component.
Apache Commons JCS 2.0-beta-2 RC1 is available for review at:
https://dist.apache.org/repos/dist/dev/commons/jcs/ (r16621).
Maven artifacts are at:
+1, thanks Thomas
Side note: the tck module has been deactivated cause of packaging=pom but
ran it manually and all tests passed so not an issue for the release since
we don't care of this artifact distribution, just here as a runner.
Romain Manni-Bucau
@rmannibucau
On Mon, Oct 24, 2016 at 3:42 AM, sebb wrote:
> It seems that Java 6 is still supported until Dec 2018 if the user
> purchases Extended Support.
Given that
a) We don't enforce users to upgrade.
b) The decision to move to Java 7 doesn't prevent us from opening
a
P.S.: Just tested it with 3.0.0. There the Laguerre Root function is not
yet implemented. For 3.0.0 we needed to exclude the Bessel filter. That
works from 3.1.0.
On 24/10/16 10:25, Eric Barnhill wrote:
> Hi Bernd, sounds like we agree on basically everything there is to do.
>
>
>> I've spent
Hi Eric,
On 24/10/16 10:25, Eric Barnhill wrote:
> Hi Bernd, sounds like we agree on basically everything there is to do.
>
>
>> I've spent the weekend adding maven support to the IIRJ library. So now
>> a simple "mvn install" does the job. Also done the testing properly with
>> "mvn test" which
Opps. Link doesn't work.
Do you mean the OCTAVE/MATLAB "filter" command? If you limit that to FIR
coefficients then that's equivalent literally to a convolution operation
which we already have. (that FIR filtering is the convolution function I
have to de-bunk every year in my DSP class because in
Hi Bernd, sounds like we agree on basically everything there is to do.
> I've spent the weekend adding maven support to the IIRJ library. So now
> a simple "mvn install" does the job. Also done the testing properly with
> "mvn test" which generates all the different kinds of impulse responses
>
Am Samstag, den 22.10.2016, 23:25 +0100 schrieb Bernd Porr:
(...)
> I'm not too crazy about proper FIR filters in JAVA because even in
> C++
> they are just too slow and one would need to write them as JNI calls
> to
> C to make them run fast enough (for example a 50Hz notch for ECG at
> 1kHz
Hello Thomas
Thomas Vandahl schrieb am So., 23. Okt. 2016 um 12:16 Uhr:
> Hi Benedikt,
>
> On 23.10.16 10:51, Benedikt Ritter wrote:
> > Hello Thomas,
> >
> > The build works with Java 8 and Maven 3.3.9.
> >
> > But the md5 and SHA1 files are missing in the dist area.
> >
> >
21 matches
Mail list logo