ally, 1.0 vote should go out
in September!
Thanks!
Bruno
From: Bruno P. Kinoshita
To: Commons Developers List
Sent: Thursday, 16 August 2018 12:26 AM
Subject: Re: [imaging] IMAGING-154 remove Debug class
Hi,
Remko's suggestion sounded good, and
iles
Backed up the old branch with a different name (just in case).
Thanks you!
Bruno
From: Matt Sicker
To: Commons Developers List
Sent: Wednesday, 15 August 2018 9:20 AM
Subject: Re: [imaging] IMAGING-154 remove Debug class
Depends on how complicat
D> wrote:
> >> > >
> >> > > I was thinking more about using that as an argument for using a
> logging
> >> > framework, but I think you are right. Probably slf4j/commons-logging +
> >> some
> >> > default binding, then allowing users to change th
implementation.
>> > >
>> > > Perhaps slf4j + log4j?
>> > >
>> > >
>> > > Bruno
>> > >
>> > >
>> > > From: Remko Popma
>> > > To: Commons Developers List
>
4j/commons-logging +
> some
> > default binding, then allowing users to change the implementation.
> > >
> > > Perhaps slf4j + log4j?
> > >
> > >
> > > Bruno
> > >
> > >
> > > From: Remko Popma
> > > To: Commons D
en allowing users to change the implementation.
> >
> > Perhaps slf4j + log4j?
> >
> >
> > Bruno
> >
> > ____
> > From: Remko Popma
> > To: Commons Developers List
> > Sent: Monday, 13 August 2018 11:55 PM
> >
t;
>>
>> Bruno
>>
>> ____
>> From: Remko Popma
>> To: Commons Developers List
>> Sent: Monday, 13 August 2018 11:55 PM
>> Subject: Re: [imaging] IMAGING-154 remove Debug class
>>
>>
>>
>> For
ependency, with disabling the logging by
>> default **could** work?
>
>
>
>> Cheers
>
>> Bruno
>
>
>
>>
>
>> From: Remko Popma
>
>> To: Commons Developers List
>
>> Sent: Monday, 13 Au
Popma
To: Commons Developers List
Sent: Monday, 13 August 2018 11:55 PM
Subject: Re: [imaging] IMAGING-154 remove Debug class
For new projects I would really avoid using Commons Logging. Ceki had a point
when he created SLF4J.
The projects you mentioned that have a dependency on Commons
rocessing, OpenJPEG, and Commons
>>>>>> Imaging are located at a higher level, some times even using it for
>>>>>> basic image handling/parsing/reading.
>>>>>
>>>>> As with many discussions on this list, conflicting arguments
ile examples for the most popular logging
frameworks showing how to disable output.
Regards,
Gilles
Cheers
Bruno
From: Remko Popma
To: Commons Developers List
Sent: Monday, 13 August 2018 9:50 AM
Subject: Re: [imaging] IMAGING-154 remove Debug class
If you wan
ault
**could** work?
Cheers
Bruno
From: Remko Popma
To: Commons Developers List
Sent: Monday, 13 August 2018 9:50 AM
Subject: Re: [imaging] IMAGING-154 remove Debug class
If you want to avoid a dependency I would not create a custom logging
abstraction bu
uld probably do the trick. Perhaps we could copy just
this class in the project... good food for thought Matt, thanks!
Cheers
Bruno
From: Matt Sicker
To: Commons Developers List
Sent: Monday, 13 August 2018 3:17 AM
Subject: Re: [imaging] IMAGING-154 remove D
o: Commons Developers List
Sent: Monday, 13 August 2018 2:12 AM
Subject: Re: [imaging] IMAGING-154 remove Debug class
You could also log to a pluggable print stream which could be sys err by
default. Kind of like what JDBC allows. My bias is to Log4j 2 as well :-)
Gary
On Sun, Aug 12, 2
java-logging-framework-has-the-best-performance/
From: Remko Popma
To: Commons Developers List
Sent: Monday, 13 August 2018 2:00 AM
Subject: Re: [imaging] IMAGING-154 remove Debug class
There’s a couple of considerations about doing logging in a library
d115c12642ecabb3b4ab73df83b1e5982076
From: Gilles
To: dev@commons.apache.org
Sent: Monday, 13 August 2018 12:21 AM
Subject: Re: [imaging] IMAGING-154 remove Debug class
Hello Bruno.
On Sun, 12 Aug 2018 08:56:37 + (UTC), Bruno P. Kinoshita wrote:
> Hi all,
omponent"
>>>> but does not define "low-level"...
>>>>
>>>>> * Feel free to cast a counter-argument for it, but please think
>>>>> whether you'd still be -0, +0 for this change. We have delayed 1.0 for
>>>>> a while, so if you have a strong opini
0 release yet again, and then somebody else may have to
> > >> work on it in a few months/years...
> > >
> > > We are there because the project is too rigid about itself as
> > > a whole (cf. for example the [RNG] thread about BC).
> > > IMHO, it's not the always least common den
the code (at a given time) probably know
> > best... :-/
> >
> > My opinion is that we can take the risk to introduce logging, and
> > if people complain somehow, take it back later.
> >
> >> one possible compromise for this,
> >> might be i) make De
,
>> might be i) make Debug internal,
>
> +1
>
> [Hmm... Does "internal" mean that minor release can break BC
> on such a class?]
>
>> ii) remove all System.out calls,
>
> +1 or
> -1
>
> [Depends on what "low-level" means here. &q
.out in there.
It would be a loss of potentially useful information (e.g. for
debugging).
Regards,
Gilles
Thanks!
Bruno
________
From: Bruno P. Kinoshita
To: Commons Developers List
Sent: Tuesday, 6 February 2018 11:30 PM
Subject: Re: [imaging] IMAGING-154 remove Debug class
Hi sebb,
Another as
ose flags, the checks, and calls to
System.out in there.
Thanks!
Bruno
From: Bruno P. Kinoshita
To: Commons Developers List
Sent: Tuesday, 6 February 2018 11:30 PM
Subject: Re: [imaging] IMAGING-154 remove Debug class
Hi sebb,
>Another aspect of debu
ily 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
ntly.
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
>
hat 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 no
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
be released, so that I can keep working on an experiment with the library +
IIIF.
Cheers
Bruno
____
From: Gilles
To: dev@commons.apache.org
Sent: Tuesday, 6 February 2018 2:47 AM
Subject: Re: [imaging] IMAGING-154 remove Debug class
On Mon, 5 Feb 2018 04:41:20 -0800, Otto Fowler wrote:
> Ma
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
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
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
30 matches
Mail list logo
