[VOTE] Release Commons Compress 1.16.1 based on RC1

[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

[VOTE] Release Commons Compress 1.16 based on RC1

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.

Re: [configuration] Notifications from commons-configuration GitHub mirror

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

Re: [release-plugin] best multi-module project?

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,

Re: [compress] cut 1.16.1 very soon?

>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

Re: [compress] cut 1.16.1 very soon?

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

[compress] cut 1.16.1 very soon?

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

Re: ${scmBranch}@r${buildNumber}; ${maven.build.timestamp} but for git

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

Re: [imaging] IMAGING-154 remove Debug class

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

Re: [beanutils] release?

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

Re: [imaging] IMAGING-154 remove Debug class

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 >

Re: [imaging] IMAGING-154 remove Debug class

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

Re: [jexl] Migration to Git

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

Re: [imaging] IMAGING-154 remove Debug class

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