[VOTE] Release Commons Compress 1.16.1 based on RC1

2018-02-06 Thread Stefan Bodewig 
[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 the LZ77Compressor.Block
class.

Compress 1.16.1 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 
24778)

The tag is here:

https://git1-us-west.apache.org/repos/asf?p=commons-compress.git;a=tag;h=463d3e7bdcd02d84e56559c617ee2307754946b4

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1304/org/apache/commons/commons-compress/1.16.1/

These are the Maven artifacts and their sha256 hashes

a20d8e45315abbe07faf952e095817b9925f38c4fc39e8a211c7d072702e97eb  
commons-compress-1.16.1.jar
9554efe9767772136113ea8912971706a384de50a60da01a20bbf6e917689d7b  
commons-compress-1.16.1-javadoc.jar
0d155b498471fd7744176ecd09599e79e3fca4e8e38ff6d91c2666de89e03f25  
commons-compress-1.16.1-sources.jar
1be01dfd51b17a359946647a5b1152748bc8ab4a9a975e287dbdac33123c0a54  
commons-compress-1.16.1-tests.jar
b3065f7512bd56b56872585cdcbe19dcc4f3691d8d4ed3dbdf5e881cbd40e91b  
commons-compress-1.16.1-test-sources.jar
5efe65bb54d680ae9c2b119228d45dcff6363804856d095f32c24ea531ca5d07  
commons-compress-1.16.1.pom

I have tested this with JDK 8 ... using Maven 3

Details of changes since 1.16 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt

https://stefan.samaflost.de/staging/commons-compress-1.16.1/changes-report.html

Site:
https://stefan.samaflost.de/staging/commons-compress-1.16.1/

As usual when I cut a release this is not the site I'm going to
publish. I'll publish a fresh site from master once the release date
is known.

The download link and the link to the 1.16.1 javadocs are not expected
to work.

If you want to build the site yourself, please note the japicmp plugin
and our parent pom force you to run the package goal first. The magical
incantation is

mvn clean package site -Pjacoco

japicmp Report (compared to 1.16):
https://stefan.samaflost.de/staging/commons-compress-1.16.1/japicmp.html

which is empty as there has been no code change at all.

RAT Report:
https://stefan.samaflost.de/staging/commons-compress-1.16.1/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now,
i.e. sometime after 07:00 UTC 10-Feb 2018

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thanks!

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release Commons Compress 1.16 based on RC1

2018-02-06 Thread Stefan Bodewig 
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.

Compress 1.16.1 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 
24778)

The tag is here:

https://git1-us-west.apache.org/repos/asf?p=commons-compress.git;a=tag;h=463d3e7bdcd02d84e56559c617ee2307754946b4

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1304/org/apache/commons/commons-compress/1.16.1/

These are the Maven artifacts and their sha256 hashes

a20d8e45315abbe07faf952e095817b9925f38c4fc39e8a211c7d072702e97eb  
commons-compress-1.16.1.jar
9554efe9767772136113ea8912971706a384de50a60da01a20bbf6e917689d7b  
commons-compress-1.16.1-javadoc.jar
0d155b498471fd7744176ecd09599e79e3fca4e8e38ff6d91c2666de89e03f25  
commons-compress-1.16.1-sources.jar
1be01dfd51b17a359946647a5b1152748bc8ab4a9a975e287dbdac33123c0a54  
commons-compress-1.16.1-tests.jar
b3065f7512bd56b56872585cdcbe19dcc4f3691d8d4ed3dbdf5e881cbd40e91b  
commons-compress-1.16.1-test-sources.jar
5efe65bb54d680ae9c2b119228d45dcff6363804856d095f32c24ea531ca5d07  
commons-compress-1.16.1.pom

I have tested this with JDK 8 ... using Maven 3

Details of changes since 1.16 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt

https://stefan.samaflost.de/staging/commons-compress-1.16.1/changes-report.html

Site:
https://stefan.samaflost.de/staging/commons-compress-1.16.1/

As usual when I cut a release this is not the site I'm going to
publish. I'll publish a fresh site from master once the release date
is known.

The download link and the link to the 1.16.1 javadocs are not expected
to work.

If you want to build the site yourself, please note the japicmp plugin
and our parent pom force you to run the package goal first. The magical
incantation is

mvn clean package site -Pjacoco

japicmp Report (compared to 1.16):
https://stefan.samaflost.de/staging/commons-compress-1.16.1/japicmp.html

which is empty as there has been no code change at all.

RAT Report:
https://stefan.samaflost.de/staging/commons-compress-1.16.1/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now,
i.e. sometime after 07:00 UTC 10-Feb 2018

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thanks!

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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

2018-02-06 Thread Bindul Bhowmik 
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 list.
>>>
>>> I opened a trivial pull request - #10 [1], but I don't see any emails
>>> on any commons lists for this pull request [2] (well this thread will
>>> show up on the search after it makes it to the archives :-))
>>>
>>> Similar searches for other commons components show emails, like [3] and [4].
>>
>> thank you for the pull request - I will have a look.
>>
>> Regarding missing mail notifications, I am not sure whether this could
>> be caused by the fact that [configuration] still uses SVN and is not yet
>> properly setup for a Github integration. Switching to Git is somewhere
>> on my Todo list, but I have not yet found the time to do this.
>>
>> Oliver
>
> The patch has been applied in revision r1821751. I also republished the
> web site, so that it shows now the correct version number.
>
> Thanks again for the patch.

Thank you for merging the patch, somehow I did not notice the patch. I
have closed the PR now.

Bindul

>
> Oliver
>
>>
>>>
>>> Bindul
>>>
>>> [1] https://github.com/apache/commons-configuration/pull/10
>>> [2] 
>>> https://lists.apache.org/list.html?*@commons.apache.org:dfr=2018-1-11|dto=2018-1-13:apache/commons-configuration/pull/
>>>
>>> [3] 
>>> https://lists.apache.org/list.html?*@commons.apache.org:dfr=2018-1-11|dto=2018-1-13:apache/commons-io/pull/
>>> [4] 
>>> https://lists.apache.org/list.html?*@commons.apache.org:dfr=2018-1-11|dto=2018-1-13:apache/commons-lang/pull/
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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

2018-02-06 Thread Gilles 

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-module project? They all have
subtle differences that lead to different nuances to the build.


Which differences did you spot?


Nothing of any particular consequence, just where the main 
assemblies

end up. Or which Pom they’re in.


What do you mean by "main assemblies"?  If it's the "full"
distribution, then is it a matter of naming the output directory?
It could be configurable.

For the config, the main POM looks the appropriate place if it can
be done without side-effects. [For RNG I created a separate 
directory

because I was not sure how to do it.]


Right….that’s why I was asking which project would be the best
standard to work from, and then I could go through and take all of 
the

other multi-module builds and mildly refactor the pom/directory
structure to align with which ever we decided was standard.

Is [jcs] the right choice as the standard?


Why this one rather than another?
It's not clear what you are looking for.
From what I see wrt the creation of "full dist" artefacts, the
difference with e.g. [RNG] is that in [jcs], there is a maven
module, with no code, while for [RNG], there is a directory
(not a maven module), but both contain a POM whose only purpose
is to provide an "assembly" config.

Having no idea on how to achieve it, I'd wish that creating
the "full dist" only requires a custom "goal" like (?)
 $ mvn package:dist
with no ad-hoc directory/module: all modules specified in the
top POM would have their artefacts (recursively) bundled into
  -dist-.tar.gz

Regards,
Gilles


Cheers,
-Rob



Gilles


I
figure we pick one and make that the standard multi-module build
paradigm and fit the others into it.

-Rob



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] cut 1.16.1 very soon?

2018-02-06 Thread Bruno P. Kinoshita 

>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: Commons Developers List  
Sent: Wednesday, 7 February 2018 4:43 AM
Subject: [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


-

To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org

For additional commands, e-mail: dev-h...@commons.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] cut 1.16.1 very soon?

2018-02-06 Thread Gary Gregory 
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 more or less
> immediately. Any objections?
>

Sure and you might as well update zstd-jni from 1.3.3-1 to 1.3.3-3.

Gary


> Cheers
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[compress] cut 1.16.1 very soon?

2018-02-06 Thread Stefan Bodewig 
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

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

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

2018-02-06 Thread Basin Ilya 
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 should be the ultimate configuration for maven plus git:




${project.version}-g${buildNumberShort}

...


maven-jar-plugin




true

true



${buildNumber}

${project.scm.connection}

${specification.version}

${implementation.version}






org.codehaus.mojo

buildnumber-maven-plugin


validate

create





unknown
false
false




org.codehaus.mojo

build-helper-maven-plugin


regex-properties


regex-properties







buildNumberShort

${buildNumber}

^(...).*$

$1

false






specification.version

${project.version}

([0-9.]*).*

$1

true












On 05.02.2018 20:47, Basin Ilya wrote:
> 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?
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [imaging] IMAGING-154 remove Debug class

2018-02-06 Thread Bruno P. Kinoshita 
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... methods 
(https://github.com/apache/commons-imaging/blob/7e7f96857df999175bb614732e13272a82f7962a/src/main/java/org/apache/commons/imaging/ImageParser.java#L794).

While I can see that parsers may need to dump the data they are holding in some 
structured way for inspecting, reporting, serializing, etc, it looks like some 
other classes were affected by it too. For example...


A JPEG Segment has a #dump() method 


https://github.com/apache/commons-imaging/blob/7e7f96857df999175bb614732e13272a82f7962a/src/main/java/org/apache/commons/imaging/formats/jpeg/segments/Segment.java#L34


which gets defined in each subclass of Segment. It can be confusing to have a 
method such as #dump() in a Segment, from the point of view of someone writing 
a photo editor for example. The user could use that to pass his/her own 
logger's PrintWriter, which would make removing or changing logging in the 
future in commons-imaging.


If we keep the Debug class, and make it internal, there would still be these 
methods to take care. And there are some methods where users can provide a 
PrintWriter, while others instead use System.out 
(e.g.https://github.com/apache/commons-imaging/blob/7e7f96857df999175bb614732e13272a82f7962a/src/main/java/org/apache/commons/imaging/FormatCompliance.java#L70).

Cheers
Bruno


From: sebb 
To: Commons Developers List ; Bruno P. Kinoshita 
 
Sent: Tuesday, 6 February 2018 11:06 PM
Subject: 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 
> logging and making Debug internal only, I'd choose making it internal.

+1

I think making it internal means it can still be dropped later.

> Looking forward to hearing what others think about these options.
>

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..

> Thanks
> Bruno
>
>
> 
> From: Jörg Schaible 
> To: dev@commons.apache.org
> Sent: Tuesday, 6 February 2018 9:24 PM
> Subject: 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 might be changed without
>
> further comment. Nobody may rely on it in production code, but during
>
> development it might be helpful. With such an approach we might not have
>
> a need to find a better interface to provide this functionality.
>
>
> Just my 2¢,
>
> Jörg
>
>
>
> Am Mon, 05 Feb 2018 12:20:58 + schrieb 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
>
>> discussing other alternatives first.
>
>>
>
>> Initially I am against logging in low level libraries, especially
>
>> commons components. But some time ago I had to debug TIFF issues in
>
>> commons-imaging, and having the dump methods was a tremendous help.
>
>>
>
>>
>
>> The issue is that some imaging algorithms/processing have a lot of
>
>> variables that can be altered. And keeping an eye on all of them in the
>
>> debugger can be quite hard - though not impossible.
>
>>
>
>> So all in all, now I am more confident to proceed without the Debug
>
>> class. But some users could have a hard time investigating possible
>
>> issues in the library without seeing what's going on within the library.
>
>>
>
>> IMO, that could be solved with the logging/dump features... or through a
>
>> better design, especially around exception handling/throwing. The latter
>
>> is my preferred approach. Instead of logging, I prefer - whenever
>
>> possible - that low level libraries throw exceptions and let me handle
>
>> the logging.
>
>>
>
>>
>
>> So, any thoughts? :) I'm +1 to remove the Debug class, and +0 to a
>
>> logging added to commons-imaging.
>
>>

Re: [beanutils] release?

2018-02-06 Thread sebb 
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 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 future?
>>>
>>
>> That's fine with me.
>>
>
> But we might as well release commons-collection4 4.2 first.

Surely the two are independent?

> Gary
>
>
>>
>> Gary
>>
>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [imaging] IMAGING-154 remove Debug class

2018-02-06 Thread sebb 
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 choose making it internal.

+1

I think making it internal means it can still be dropped later.

> Looking forward to hearing what others think about these options.
>

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..

> Thanks
> Bruno
>
>
> 
> From: Jörg Schaible 
> To: dev@commons.apache.org
> Sent: Tuesday, 6 February 2018 9:24 PM
> Subject: 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 might be changed without
>
> further comment. Nobody may rely on it in production code, but during
>
> development it might be helpful. With such an approach we might not have
>
> a need to find a better interface to provide this functionality.
>
>
> Just my 2¢,
>
> Jörg
>
>
>
> Am Mon, 05 Feb 2018 12:20:58 + schrieb 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
>
>> discussing other alternatives first.
>
>>
>
>> Initially I am against logging in low level libraries, especially
>
>> commons components. But some time ago I had to debug TIFF issues in
>
>> commons-imaging, and having the dump methods was a tremendous help.
>
>>
>
>>
>
>> The issue is that some imaging algorithms/processing have a lot of
>
>> variables that can be altered. And keeping an eye on all of them in the
>
>> debugger can be quite hard - though not impossible.
>
>>
>
>> So all in all, now I am more confident to proceed without the Debug
>
>> class. But some users could have a hard time investigating possible
>
>> issues in the library without seeing what's going on within the library.
>
>>
>
>> IMO, that could be solved with the logging/dump features... or through a
>
>> better design, especially around exception handling/throwing. The latter
>
>> is my preferred approach. Instead of logging, I prefer - whenever
>
>> possible - that low level libraries throw exceptions and let me handle
>
>> the logging.
>
>>
>
>>
>
>> So, any thoughts? :) I'm +1 to remove the Debug class, and +0 to a
>
>> logging added to commons-imaging.
>
>>
>
>> Bruno
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>
> For additional commands, e-mail: dev-h...@commons.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [imaging] IMAGING-154 remove Debug class

2018-02-06 Thread Bruno P. Kinoshita 
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 think about these options.


Thanks
Bruno



From: Jörg Schaible 
To: dev@commons.apache.org 
Sent: Tuesday, 6 February 2018 9:24 PM
Subject: 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 might be changed without 

further comment. Nobody may rely on it in production code, but during 

development it might be helpful. With such an approach we might not have 

a need to find a better interface to provide this functionality.


Just my 2¢,

Jörg



Am Mon, 05 Feb 2018 12:20:58 + schrieb 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

> discussing other alternatives first.

> 

> Initially I am against logging in low level libraries, especially

> commons components. But some time ago I had to debug TIFF issues in

> commons-imaging, and having the dump methods was a tremendous help.

> 

> 

> The issue is that some imaging algorithms/processing have a lot of

> variables that can be altered. And keeping an eye on all of them in the

> debugger can be quite hard - though not impossible.

> 

> So all in all, now I am more confident to proceed without the Debug

> class. But some users could have a hard time investigating possible

> issues in the library without seeing what's going on within the library.

> 

> IMO, that could be solved with the logging/dump features... or through a

> better design, especially around exception handling/throwing. The latter

> is my preferred approach. Instead of logging, I prefer - whenever

> possible - that low level libraries throw exceptions and let me handle

> the logging.

> 

> 

> So, any thoughts? :) I'm +1 to remove the Debug class, and +0 to a

> logging added to commons-imaging.

> 

> Bruno




-

To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org

For additional commands, e-mail: dev-h...@commons.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [jexl] Migration to Git

2018-02-06 Thread henrib 
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 unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [imaging] IMAGING-154 remove Debug class

2018-02-06 Thread Jörg Schaible 
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 might be changed without 
further comment. Nobody may rely on it in production code, but during 
development it might be helpful. With such an approach we might not have 
a need to find a better interface to provide this functionality.

Just my 2¢,
Jörg


Am Mon, 05 Feb 2018 12:20:58 + schrieb 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
> discussing other alternatives first.
> 
> Initially I am against logging in low level libraries, especially
> commons components. But some time ago I had to debug TIFF issues in
> commons-imaging, and having the dump methods was a tremendous help.
> 
> 
> The issue is that some imaging algorithms/processing have a lot of
> variables that can be altered. And keeping an eye on all of them in the
> debugger can be quite hard - though not impossible.
> 
> So all in all, now I am more confident to proceed without the Debug
> class. But some users could have a hard time investigating possible
> issues in the library without seeing what's going on within the library.
> 
> IMO, that could be solved with the logging/dump features... or through a
> better design, especially around exception handling/throwing. The latter
> is my preferred approach. Instead of logging, I prefer - whenever
> possible - that low level libraries throw exceptions and let me handle
> the logging.
> 
> 
> So, any thoughts? :) I'm +1 to remove the Debug class, and +0 to a
> logging added to commons-imaging.
> 
> Bruno



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org