[now with fixed subject line, sorry]
I've again managed to mess up the OSGi manifest with Compress 1.16 so
this is a quick bug fix release that doesn't contain any code changes.
Apart from the manifest fix I've updated zstd-jni to the latest release
and added a note about the internal nature of t
I've again managed to mess up the OSGi manifest with Compress 1.16 so
this is a quick bug fix release that doesn't contain any code changes.
Apart from the manifest fix I've updated zstd-jni to the latest release
and added a note about the internal nature of the LZ77Compressor.Block
class.
Compre
On Sat, Jan 20, 2018 at 8:39 AM, Oliver Heger
wrote:
>
>
> Am 15.01.2018 um 18:04 schrieb Oliver Heger:
>> Hi,
>>
>> Am 14.01.2018 um 00:33 schrieb Bindul Bhowmik:
>>> Hello,
>>>
>>> It seems notifications from the commons-configuration GitHub mirror
>>> are not setup to go to any commons mailing
On Mon, 5 Feb 2018 21:49:52 -0500, Rob Tompkins wrote:
On Feb 5, 2018, at 3:05 PM, Gilles
wrote:
On Mon, 5 Feb 2018 14:27:53 -0500, Rob Tompkins wrote:
On Feb 5, 2018, at 2:22 PM, Gilles
wrote:
On Mon, 5 Feb 2018 14:17:18 -0500, Rob Tompkins wrote:
Which should be the template multi-modul
>If the fix is confirmed I'd like to cut a 1.16.1 release more or less
>immediately. Any objections?
+1, go for it. Took me a while to spot the difference between the two lines.
Tricky to remember to use := and not = there.
Cheers
B
From: Stefan Bodewig
To
On Tue, Feb 6, 2018 at 8:43 AM, Stefan Bodewig wrote:
> Hi
>
> it looks as if I again managed to break the OSGi manifest without
> anybody noticing (I'd be the last one to notice):
>
> https://issues.apache.org/jira/browse/COMPRESS-442
>
> If the fix is confirmed I'd like to cut a 1.16.1 release
Hi
it looks as if I again managed to break the OSGi manifest without
anybody noticing (I'd be the last one to notice):
https://issues.apache.org/jira/browse/COMPRESS-442
If the fix is confirmed I'd like to cut a 1.16.1 release more or less
immediately. Any objections?
Cheers
Stefan
--
The following snippet produces a nearest to the spec manifest I could make.
It makes Specification-Version contain only digits and dots and
Implementation-Version have something like `git describe`.
Implementation-Version: 1.0.0-SNAPSHOT-g9440aea
Specification-Version: 1.0.0
I think this
Hi sebb,
>Another aspect of debugging is ensuring that methods are small and
>easily tested independently.
>However this is difficult to do, and care must be taken to ensure that
>the public API is not unnecessarily extended..
A very good point.
The parsers in commons-imaging expose some #dump.
On 6 February 2018 at 05:04, Gary Gregory wrote:
> On Mon, Feb 5, 2018 at 10:04 PM, Gary Gregory
> wrote:
>
>> On Mon, Feb 5, 2018 at 10:00 PM, Dave Brosius wrote:
>>
>>> Given the lack of impetus around doing anything more grand with
>>> beanutils, can we put out the current state of beanutils
On 6 February 2018 at 09:52, Bruno P. Kinoshita
wrote:
> Hi Jorg,
>
> I'd be fine with that solution too. I think this one would cause the smaller
> change to the code as is.
>
> I believe my preference is still to remove the Debug class. But between
> logging and making Debug internal only, I'd
Hi Jorg,
I'd be fine with that solution too. I think this one would cause the smaller
change to the code as is.
I believe my preference is still to remove the Debug class. But between logging
and making Debug internal only, I'd choose making it internal.
Looking forward to hearing what others
No complaints nor remarks, just a simple "thank you" note.
(ps: rebelling against considering positive reinforcement as clutter :-D )
--
Sent from: http://apache-commons.680414.n4.nabble.com/Commons-Dev-f680415.html
-
To unsubs
Hi Bruno,
if it might also be helpful to our users, why not keep and provide it. As
I understand it, the Debug class is a tool helping in development to
analyze some behavior.
Nothing stops us from declaring this class internal (we might even put it
into a package "internal" or "debug") that m
14 matches
Mail list logo