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
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 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
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
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
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.
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
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
--
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
>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 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
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
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
[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
14 matches
Mail list logo
