Re: [imaging] IMAGING-154 remove Debug class

2018-02-05 Thread Bruno P. Kinoshita
>They are not necessarily exclusive options. >I mean: (intending on) good design is necessary but, if achieved, >it doesn't imply that logging is never necessary. +1 agreed, regardless of the decision here. >I'd like to recall that logging is a tool primarily for _users_: >it helps them see ho

[ANN] Apache Commons Compress 1.16 Released

2018-02-05 Thread Stefan Bodewig
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Apache Commons Team is pleased to announce the release of Apache Commons Compress 1.16. Apache Commons Compress software defines an API for working with compression and archive formats. These include: bzip2, gzip, pack200, lzma, xz, Snappy, tradi

Re: [beanutils] release?

2018-02-05 Thread Gary Gregory
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 as 2.0 so we can >> get rid of the old commons-collections

Re: [beanutils] release?

2018-02-05 Thread Gary Gregory
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 as 2.0 so we can get rid of > the old commons-collections dependency, and then if folks would like, we > can think abou

[beanutils] release?

2018-02-05 Thread Dave Brosius
Given the lack of impetus around doing anything more grand with beanutils, can we put out the current state of beanutils as 2.0 so we can get rid of the old commons-collections dependency, and then if folks would like, we can think about moving on with what's on the alternative branch in the fu

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

2018-02-05 Thread Rob Tompkins
> 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-module project? They all have subtl

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

2018-02-05 Thread Gilles
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-module project? They all have subtle differences that lead to different nuances to the build. Which diff

[RESULT] Release Commons Compress 1.16 based on RC1

2018-02-05 Thread Stefan Bodewig
Hi all with +1s by Gary Gregory Oliver Heger Stefan Bodewig and no other votes the votes has passed. I'll proceed with publishing the artifacts and give the mirrors a few hours time before announcing the release. Many thanks to those who took the time to evaluate the release Stefan -

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

2018-02-05 Thread Rob Tompkins
> 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-module project? They all have >> subtle differences that lead to different nuances to the build. > > Which differences did you spot? Nothing of any par

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

2018-02-05 Thread Gilles
On Mon, 5 Feb 2018 14:17:18 -0500, Rob Tompkins wrote: Which should be the template multi-module project? They all have subtle differences that lead to different nuances to the build. Which differences did you spot? Gilles I figure we pick one and make that the standard multi-module build pa

[release-plugin] best multi-module project?

2018-02-05 Thread Rob Tompkins
Which should be the template multi-module project? They all have subtle differences that lead to different nuances to the build. I figure we pick one and make that the standard multi-module build paradigm and fit the others into it. -Rob

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

2018-02-05 Thread Basin Ilya
Hi. I noticed that commons-parent pom has this: ${scmBranch}@r${buildNumber}; ${maven.build.timestamp} and it is used as `Implementation-build:` jar manifest entry. Is it a standard or a tradition? Is it for svn only? What about git? -

Re: [imaging] IMAGING-154 remove Debug class

2018-02-05 Thread Gilles
On Mon, 5 Feb 2018 04:41:20 -0800, Otto Fowler wrote: Maybe Debug should be an interface ( perhaps with the current class as the default implementation ) and be passed in optionally? On February 5, 2018 at 07:21:11, Bruno P. Kinoshita ( brunodepau...@yahoo.com.br.invalid) wrote: Hello, If me

Re: [imaging] IMAGING-154 remove Debug class

2018-02-05 Thread Otto Fowler
Maybe Debug should be an interface ( perhaps with the current class as the default implementation ) and be passed in optionally? On February 5, 2018 at 07:21:11, Bruno P. Kinoshita ( brunodepau...@yahoo.com.br.invalid) wrote: Hello, If memory serves me well, some time ago we had a discussion ar

[imaging] IMAGING-154 remove Debug class

2018-02-05 Thread Bruno P. Kinoshita
Hello, If memory serves me well, some time ago we had a discussion around sanselan & commons-imaging 1.0. One of the issues with commons-imaging 1.0 was the Debug class. https://issues.apache.org/jira/browse/IMAGING-154 I finished the pull request, but Gilles raised an important point, about

[GitHub] commons-imaging issue #35: IMAGING-154 Removed Debug class

2018-02-05 Thread kinow
Github user kinow commented on the issue: https://github.com/apache/commons-imaging/pull/35 `changes.xml` updated. Last commit contains the word-trick to close the pull request. Once merged, everything should be correct, just need to update JIRA. --- ---

[GitHub] commons-imaging pull request #35: IMAGING-154 Removed Debug class

2018-02-05 Thread kinow
GitHub user kinow opened a pull request: https://github.com/apache/commons-imaging/pull/35 IMAGING-154 Removed Debug class Removed the `Debug` and `ImageDump` classes. Also removed methods with the `verbose` parameter, as well as any `System.out.println`'s. Tried to keep the change