[DISCUSS] new component for timing?

[Otto Fowler]

Hi,

In the course of working through my pull request for adding new LANG
functionality on top of the StopWatch class, the issue has been raise as to
if this functionality is ‘common’ or should
be placed in a more specialized commons-xxxx component.

We would like to take the discussion to the list for this, and see what
everyone thinks.

The StackWatch provides for tracking nested timings backed by StopWatch.
You can start the watch, and start and stop multiple timings through the
call stack. Each timing is named and tag and has it’s own time.
You can visit all the timings, perhaps using the tags to filter when you
are done.  Please see the PR/Jira for more details.  You should look at
both, since the review has been split between the two.

If not LANG, then where?  The commons-testing component has been
mentioned.  But this code is not ‘test’ code explicitly.  In my use case (
I wrote this for the Apache Metron project and thought it might be useful
here) it would not be test code, in the sense that it would be used in
‘test’ scope in mvn.  Rather it would be deployed in production, in a REPL,
and perhaps in other runtime components.  I would not want to pull in junit
or other dependencies with any component containing it.

If we put it in commons-testing ( which already has sub-modules which are
geared towards junit ) it may be confusing, even if the module is explicit
about purpose and keeping out junit dependent code ( or other testing code).
Also, besides the StackWatch, what else would go into the new target
component?  Would StopWatch move as well for example?


https://issues.apache.org/jira/browse/LANG-1373
<https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&focusedCommentId=16377279#comment-16377279>
https://github.com/apache/commons-lang/pull/311

[Gilles Sadowski]

Hello.

On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:

> Hi,
>
> In the course of working through my pull request for adding new LANG
> functionality on top of the StopWatch class, the issue has been raise
> as to
> if this functionality is ‘common’ or should
> be placed in a more specialized commons-xxxx component.
>
> We would like to take the discussion to the list for this, and see
> what
> everyone thinks.
>
> The StackWatch provides for tracking nested timings backed by
> StopWatch.
> You can start the watch, and start and stop multiple timings through
> the
> call stack. Each timing is named and tag and has it’s own time.
> You can visit all the timings, perhaps using the tags to filter when
> you
> are done.  Please see the PR/Jira for more details.  You should look
> at
> both, since the review has been split between the two.
>
> If not LANG, then where?  The commons-testing component has been
> mentioned.  But this code is not ‘test’ code explicitly.  In my use
> case (
> I wrote this for the Apache Metron project and thought it might be
> useful
> here) it would not be test code, in the sense that it would be used
> in
> ‘test’ scope in mvn.  Rather it would be deployed in production, in a
> REPL,
> and perhaps in other runtime components.

Part of what makes a good component is that it does not dictate
how and where applications should use it.
The name "Testing" does not imply that its contents must be used
within "test" scope.

A utility such as "StackWatch" could be another tool to integrate
in a unit test suite (e.g. to generate a more fine-grained timing
report than Junit does).  Hence the module in which "StackWatch"
will belong is to become a dependency of modules that target
specific test framework (and that is true whether the former is
defined within "Testing" or in another component).

> I would not want to pull in junit
> or other dependencies with any component containing it.

+1
Must be ensured by proper granularity of the modular design.

> If we put it in commons-testing ( which already has sub-modules which
> are
> geared towards junit ) it may be confusing, even if the module is
> explicit
> about purpose and keeping out junit dependent code ( or other testing
> code).

Why would it be confusing?  The module will stand out on its own
(artefact/description/doc/web site) and be more visible than yet
another class in the already too large "Commons Lang".

> Also, besides the StackWatch, what else would go into the new target
> component?  Would StopWatch move as well for example?

+1
But creating a new component for two small classes can reasonably
be argued as overkill.
FTR: I was asked to collect the sampling utilities within a
module of "Commons RNG" even though it could have warranted its
own component (being a plain "client" of the core functionality
of [RNG]).  In the present case, "StackWatch" would belong to
"core" utilities of "Testing" that are pulled (along with other
dependencies by the more specific modules.

Gilles

>
> https://issues.apache.org/jira/browse/LANG-1373
>
> <https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&focusedCommentId=16377279#comment-16377279>
> https://github.com/apache/commons-lang/pull/311


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[garydgregory]

On Wed, Feb 28, 2018 at 6:35 AM, Gilles <[hidden email]>
wrote:

> Hello.
>
> On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>
>> Hi,
>>
>> In the course of working through my pull request for adding new LANG
>> functionality on top of the StopWatch class, the issue has been raise as
>> to
>> if this functionality is ‘common’ or should
>> be placed in a more specialized commons-xxxx component.
>>
>> We would like to take the discussion to the list for this, and see what
>> everyone thinks.
>>
>> The StackWatch provides for tracking nested timings backed by StopWatch.
>> You can start the watch, and start and stop multiple timings through the
>> call stack. Each timing is named and tag and has it’s own time.
>> You can visit all the timings, perhaps using the tags to filter when you
>> are done.  Please see the PR/Jira for more details.  You should look at
>> both, since the review has been split between the two.
>>
>> If not LANG, then where?  The commons-testing component has been
>> mentioned.  But this code is not ‘test’ code explicitly.  In my use case (
>> I wrote this for the Apache Metron project and thought it might be useful
>> here) it would not be test code, in the sense that it would be used in
>> ‘test’ scope in mvn.  Rather it would be deployed in production, in a
>> REPL,
>> and perhaps in other runtime components.
>>
>
> Part of what makes a good component is that it does not dictate
> how and where applications should use it.
> The name "Testing" does not imply that its contents must be used
> within "test" scope.
>
> A utility such as "StackWatch" could be another tool to integrate
> in a unit test suite (e.g. to generate a more fine-grained timing
> report than Junit does).  Hence the module in which "StackWatch"
> will belong is to become a dependency of modules that target
> specific test framework (and that is true whether the former is
> defined within "Testing" or in another component).
>
> I would not want to pull in junit
>> or other dependencies with any component containing it.
>>
>
> +1
> Must be ensured by proper granularity of the modular design.
>
> If we put it in commons-testing ( which already has sub-modules which are
>> geared towards junit ) it may be confusing, even if the module is explicit
>> about purpose and keeping out junit dependent code ( or other testing
>> code).
>>
>
> Why would it be confusing?  The module will stand out on its own
> (artefact/description/doc/web site) and be more visible than yet
> another class in the already too large "Commons Lang".
>
> Also, besides the StackWatch, what else would go into the new target
>> component?  Would StopWatch move as well for example?
>>
>
> +1
> But creating a new component for two small classes can reasonably
> be argued as overkill.
> FTR: I was asked to collect the sampling utilities within a
> module of "Commons RNG" even though it could have warranted its
> own component (being a plain "client" of the core functionality
> of [RNG]).  In the present case, "StackWatch" would belong to
> "core" utilities of "Testing" that are pulled (along with other
> dependencies by the more specific modules.
>

I would ask all of us to step back for a moment and consider the big
picture.

Specifically, what do you consider the mandate or guidelines for Commons
Lang to be? For me, this is code that should or could have been in the JRE
in java.lang or java.util. Looking ahead to Java 9, Commons Lang should
likely only depend on java.base (it does today but this should be enforced
with the Maven JDeps Plugin IMO.)

If you look at StringUtils, you can then see how this class has grown into
a giant. You can also then see why other related code like a fancier
String.replace() could creep in as StrSubstitutor and friends. Should
variable interpolation have been in the JRE? Debatable, but it would be
useful on top of Properties and ResourceBundle, one might argue; also handy
for JAXB I would say. Nevertheless, WRT to Commons Lang, we -- rightly IMO
-- have deprecated StrSubstitutor in Commons Lang in favor or its new home
in Commons Text, where is has evolved further.

In my view, StopWatch and now StackWatch, do not belong in the JRE or
Commons Lang. It should sit slightly above that level. Where, is the
question.

Commons Testing for Stop/StackWatch does not seen quite right to me. I
could see a new Commons Timing or a more general Commons Measurement; with
a mandate NOT to overlap with Joda-Time and java.time.

Gary

> Gilles
>
>
>> https://issues.apache.org/jira/browse/LANG-1373
>>
>> <https://issues.apache.org/jira/browse/LANG-1373?page=com.
>> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
>> tabpanel&focusedCommentId=16377279#comment-16377279>
>> https://github.com/apache/commons-lang/pull/311
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

[Romain Manni-Bucau]

Hi guys,

On that topic we can keep in mind we retired not a lot time ago Apache
Sirona which was a perf framework industrializing a stopwatch to summarize
it.
We can make it live again and would probably be a better fir than commons
cause you quickly need more than just some time measurement when you start
to work on these topics.

Just my 2 cts


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-02-28 16:56 GMT+01:00 Gary Gregory <[hidden email]>:

> On Wed, Feb 28, 2018 at 6:35 AM, Gilles <[hidden email]>
> wrote:
>
> > Hello.
> >
> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
> >
> >> Hi,
> >>
> >> In the course of working through my pull request for adding new LANG
> >> functionality on top of the StopWatch class, the issue has been raise as
> >> to
> >> if this functionality is ‘common’ or should
> >> be placed in a more specialized commons-xxxx component.
> >>
> >> We would like to take the discussion to the list for this, and see what
> >> everyone thinks.
> >>
> >> The StackWatch provides for tracking nested timings backed by StopWatch.
> >> You can start the watch, and start and stop multiple timings through the
> >> call stack. Each timing is named and tag and has it’s own time.
> >> You can visit all the timings, perhaps using the tags to filter when you
> >> are done.  Please see the PR/Jira for more details.  You should look at
> >> both, since the review has been split between the two.
> >>
> >> If not LANG, then where?  The commons-testing component has been
> >> mentioned.  But this code is not ‘test’ code explicitly.  In my use
> case (
> >> I wrote this for the Apache Metron project and thought it might be
> useful
> >> here) it would not be test code, in the sense that it would be used in
> >> ‘test’ scope in mvn.  Rather it would be deployed in production, in a
> >> REPL,
> >> and perhaps in other runtime components.
> >>
> >
> > Part of what makes a good component is that it does not dictate
> > how and where applications should use it.
> > The name "Testing" does not imply that its contents must be used
> > within "test" scope.
> >
> > A utility such as "StackWatch" could be another tool to integrate
> > in a unit test suite (e.g. to generate a more fine-grained timing
> > report than Junit does).  Hence the module in which "StackWatch"
> > will belong is to become a dependency of modules that target
> > specific test framework (and that is true whether the former is
> > defined within "Testing" or in another component).
> >
> > I would not want to pull in junit
> >> or other dependencies with any component containing it.
> >>
> >
> > +1
> > Must be ensured by proper granularity of the modular design.
> >
> > If we put it in commons-testing ( which already has sub-modules which are
> >> geared towards junit ) it may be confusing, even if the module is
> explicit
> >> about purpose and keeping out junit dependent code ( or other testing
> >> code).
> >>
> >
> > Why would it be confusing?  The module will stand out on its own
> > (artefact/description/doc/web site) and be more visible than yet
> > another class in the already too large "Commons Lang".
> >
> > Also, besides the StackWatch, what else would go into the new target
> >> component?  Would StopWatch move as well for example?
> >>
> >
> > +1
> > But creating a new component for two small classes can reasonably
> > be argued as overkill.
> > FTR: I was asked to collect the sampling utilities within a
> > module of "Commons RNG" even though it could have warranted its
> > own component (being a plain "client" of the core functionality
> > of [RNG]).  In the present case, "StackWatch" would belong to
> > "core" utilities of "Testing" that are pulled (along with other
> > dependencies by the more specific modules.
> >
>
> I would ask all of us to step back for a moment and consider the big
> picture.
>
> Specifically, what do you consider the mandate or guidelines for Commons
> Lang to be? For me, this is code that should or could have been in the JRE
> in java.lang or java.util. Looking ahead to Java 9, Commons Lang should
> likely only depend on java.base (it does today but this should be enforced
> with the Maven JDeps Plugin IMO.)
>
> If you look at StringUtils, you can then see how this class has grown into
> a giant. You can also then see why other related code like a fancier
> String.replace() could creep in as StrSubstitutor and friends. Should
> variable interpolation have been in the JRE? Debatable, but it would be
> useful on top of Properties and ResourceBundle, one might argue; also handy
> for JAXB I would say. Nevertheless, WRT to Commons Lang, we -- rightly IMO
> -- have deprecated StrSubstitutor in Commons Lang in favor or its new home
> in Commons Text, where is has evolved further.
>
> In my view, StopWatch and now StackWatch, do not belong in the JRE or
> Commons Lang. It should sit slightly above that level. Where, is the
> question.
>
> Commons Testing for Stop/StackWatch does not seen quite right to me. I
> could see a new Commons Timing or a more general Commons Measurement; with
> a mandate NOT to overlap with Joda-Time and java.time.
>
> Gary
>
>
>
>
> > Gilles
> >
> >
> >> https://issues.apache.org/jira/browse/LANG-1373
> >>
> >> <https://issues.apache.org/jira/browse/LANG-1373?page=com.
> >> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
> >> tabpanel&focusedCommentId=16377279#comment-16377279>
> >> https://github.com/apache/commons-lang/pull/311
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>

[Gilles Sadowski]

On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:

> Hi guys,
>
> On that topic we can keep in mind we retired not a lot time ago
> Apache
> Sirona which was a perf framework industrializing a stopwatch to
> summarize
> it.
> We can make it live again and would probably be a better fir than
> commons
> cause you quickly need more than just some time measurement when you
> start
> to work on these topics.

Why was the project terminated?

Gilles

>
> Just my 2 cts
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
> 2018-02-28 16:56 GMT+01:00 Gary Gregory <[hidden email]>:
>
>> On Wed, Feb 28, 2018 at 6:35 AM, Gilles
>> <[hidden email]>
>> wrote:
>>
>> > Hello.
>> >
>> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>> >
>> >> Hi,
>> >>
>> >> In the course of working through my pull request for adding new
>> LANG
>> >> functionality on top of the StopWatch class, the issue has been
>> raise as
>> >> to
>> >> if this functionality is ‘common’ or should
>> >> be placed in a more specialized commons-xxxx component.
>> >>
>> >> We would like to take the discussion to the list for this, and
>> see what
>> >> everyone thinks.
>> >>
>> >> The StackWatch provides for tracking nested timings backed by
>> StopWatch.
>> >> You can start the watch, and start and stop multiple timings
>> through the
>> >> call stack. Each timing is named and tag and has it’s own time.
>> >> You can visit all the timings, perhaps using the tags to filter
>> when you
>> >> are done.  Please see the PR/Jira for more details.  You should
>> look at
>> >> both, since the review has been split between the two.
>> >>
>> >> If not LANG, then where?  The commons-testing component has been
>> >> mentioned.  But this code is not ‘test’ code explicitly.  In my
>> use
>> case (
>> >> I wrote this for the Apache Metron project and thought it might
>> be
>> useful
>> >> here) it would not be test code, in the sense that it would be
>> used in
>> >> ‘test’ scope in mvn.  Rather it would be deployed in production,
>> in a
>> >> REPL,
>> >> and perhaps in other runtime components.
>> >>
>> >
>> > Part of what makes a good component is that it does not dictate
>> > how and where applications should use it.
>> > The name "Testing" does not imply that its contents must be used
>> > within "test" scope.
>> >
>> > A utility such as "StackWatch" could be another tool to integrate
>> > in a unit test suite (e.g. to generate a more fine-grained timing
>> > report than Junit does).  Hence the module in which "StackWatch"
>> > will belong is to become a dependency of modules that target
>> > specific test framework (and that is true whether the former is
>> > defined within "Testing" or in another component).
>> >
>> > I would not want to pull in junit
>> >> or other dependencies with any component containing it.
>> >>
>> >
>> > +1
>> > Must be ensured by proper granularity of the modular design.
>> >
>> > If we put it in commons-testing ( which already has sub-modules
>> which are
>> >> geared towards junit ) it may be confusing, even if the module is
>> explicit
>> >> about purpose and keeping out junit dependent code ( or other
>> testing
>> >> code).
>> >>
>> >
>> > Why would it be confusing?  The module will stand out on its own
>> > (artefact/description/doc/web site) and be more visible than yet
>> > another class in the already too large "Commons Lang".
>> >
>> > Also, besides the StackWatch, what else would go into the new
>> target
>> >> component?  Would StopWatch move as well for example?
>> >>
>> >
>> > +1
>> > But creating a new component for two small classes can reasonably
>> > be argued as overkill.
>> > FTR: I was asked to collect the sampling utilities within a
>> > module of "Commons RNG" even though it could have warranted its
>> > own component (being a plain "client" of the core functionality
>> > of [RNG]).  In the present case, "StackWatch" would belong to
>> > "core" utilities of "Testing" that are pulled (along with other
>> > dependencies by the more specific modules.
>> >
>>
>> I would ask all of us to step back for a moment and consider the big
>> picture.
>>
>> Specifically, what do you consider the mandate or guidelines for
>> Commons
>> Lang to be? For me, this is code that should or could have been in
>> the JRE
>> in java.lang or java.util. Looking ahead to Java 9, Commons Lang
>> should
>> likely only depend on java.base (it does today but this should be
>> enforced
>> with the Maven JDeps Plugin IMO.)
>>
>> If you look at StringUtils, you can then see how this class has
>> grown into
>> a giant. You can also then see why other related code like a fancier
>> String.replace() could creep in as StrSubstitutor and friends.
>> Should
>> variable interpolation have been in the JRE? Debatable, but it would
>> be
>> useful on top of Properties and ResourceBundle, one might argue;
>> also handy
>> for JAXB I would say. Nevertheless, WRT to Commons Lang, we --
>> rightly IMO
>> -- have deprecated StrSubstitutor in Commons Lang in favor or its
>> new home
>> in Commons Text, where is has evolved further.
>>
>> In my view, StopWatch and now StackWatch, do not belong in the JRE
>> or
>> Commons Lang. It should sit slightly above that level. Where, is the
>> question.
>>
>> Commons Testing for Stop/StackWatch does not seen quite right to me.
>> I
>> could see a new Commons Timing or a more general Commons
>> Measurement; with
>> a mandate NOT to overlap with Joda-Time and java.time.
>>
>> Gary
>>
>>
>>
>>
>> > Gilles
>> >
>> >
>> >> https://issues.apache.org/jira/browse/LANG-1373
>> >>
>> >> <https://issues.apache.org/jira/browse/LANG-1373?page=com.
>> >> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
>> >> tabpanel&focusedCommentId=16377279#comment-16377279>
>> >> https://github.com/apache/commons-lang/pull/311
>> >>
>> >
>> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Romain Manni-Bucau]

2018-02-28 17:11 GMT+01:00 Gilles <[hidden email]>:

> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
>
>> Hi guys,
>>
>> On that topic we can keep in mind we retired not a lot time ago Apache
>> Sirona which was a perf framework industrializing a stopwatch to summarize
>> it.
>> We can make it live again and would probably be a better fir than commons
>> cause you quickly need more than just some time measurement when you start
>> to work on these topics.
>>
>
> Why was the project terminated?
>

Community didn't grow enough and activity was not that high - the project
went stable pretty quickly. I forked it on github for now
https://github.com/rmannibucau/sirona

>
> Gilles
>
>
>> Just my 2 cts
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>
>> <https://www.packtpub.com/application-development/java-ee-8-
>> high-performance>
>>
>>
>> 2018-02-28 16:56 GMT+01:00 Gary Gregory <[hidden email]>:
>>
>> On Wed, Feb 28, 2018 at 6:35 AM, Gilles <[hidden email]>
>>> wrote:
>>>
>>> > Hello.
>>> >
>>> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> In the course of working through my pull request for adding new LANG
>>> >> functionality on top of the StopWatch class, the issue has been raise
>>> as
>>> >> to
>>> >> if this functionality is ‘common’ or should
>>> >> be placed in a more specialized commons-xxxx component.
>>> >>
>>> >> We would like to take the discussion to the list for this, and see
>>> what
>>> >> everyone thinks.
>>> >>
>>> >> The StackWatch provides for tracking nested timings backed by
>>> StopWatch.
>>> >> You can start the watch, and start and stop multiple timings through
>>> the
>>> >> call stack. Each timing is named and tag and has it’s own time.
>>> >> You can visit all the timings, perhaps using the tags to filter when
>>> you
>>> >> are done.  Please see the PR/Jira for more details.  You should look
>>> at
>>> >> both, since the review has been split between the two.
>>> >>
>>> >> If not LANG, then where?  The commons-testing component has been
>>> >> mentioned.  But this code is not ‘test’ code explicitly.  In my use
>>> case (
>>> >> I wrote this for the Apache Metron project and thought it might be
>>> useful
>>> >> here) it would not be test code, in the sense that it would be used in
>>> >> ‘test’ scope in mvn.  Rather it would be deployed in production, in a
>>> >> REPL,
>>> >> and perhaps in other runtime components.
>>> >>
>>> >
>>> > Part of what makes a good component is that it does not dictate
>>> > how and where applications should use it.
>>> > The name "Testing" does not imply that its contents must be used
>>> > within "test" scope.
>>> >
>>> > A utility such as "StackWatch" could be another tool to integrate
>>> > in a unit test suite (e.g. to generate a more fine-grained timing
>>> > report than Junit does).  Hence the module in which "StackWatch"
>>> > will belong is to become a dependency of modules that target
>>> > specific test framework (and that is true whether the former is
>>> > defined within "Testing" or in another component).
>>> >
>>> > I would not want to pull in junit
>>> >> or other dependencies with any component containing it.
>>> >>
>>> >
>>> > +1
>>> > Must be ensured by proper granularity of the modular design.
>>> >
>>> > If we put it in commons-testing ( which already has sub-modules which
>>> are
>>> >> geared towards junit ) it may be confusing, even if the module is
>>> explicit
>>> >> about purpose and keeping out junit dependent code ( or other testing
>>> >> code).
>>> >>
>>> >
>>> > Why would it be confusing?  The module will stand out on its own
>>> > (artefact/description/doc/web site) and be more visible than yet
>>> > another class in the already too large "Commons Lang".
>>> >
>>> > Also, besides the StackWatch, what else would go into the new target
>>> >> component?  Would StopWatch move as well for example?
>>> >>
>>> >
>>> > +1
>>> > But creating a new component for two small classes can reasonably
>>> > be argued as overkill.
>>> > FTR: I was asked to collect the sampling utilities within a
>>> > module of "Commons RNG" even though it could have warranted its
>>> > own component (being a plain "client" of the core functionality
>>> > of [RNG]).  In the present case, "StackWatch" would belong to
>>> > "core" utilities of "Testing" that are pulled (along with other
>>> > dependencies by the more specific modules.
>>> >
>>>
>>> I would ask all of us to step back for a moment and consider the big
>>> picture.
>>>
>>> Specifically, what do you consider the mandate or guidelines for Commons
>>> Lang to be? For me, this is code that should or could have been in the
>>> JRE
>>> in java.lang or java.util. Looking ahead to Java 9, Commons Lang should
>>> likely only depend on java.base (it does today but this should be
>>> enforced
>>> with the Maven JDeps Plugin IMO.)
>>>
>>> If you look at StringUtils, you can then see how this class has grown
>>> into
>>> a giant. You can also then see why other related code like a fancier
>>> String.replace() could creep in as StrSubstitutor and friends. Should
>>> variable interpolation have been in the JRE? Debatable, but it would be
>>> useful on top of Properties and ResourceBundle, one might argue; also
>>> handy
>>> for JAXB I would say. Nevertheless, WRT to Commons Lang, we -- rightly
>>> IMO
>>> -- have deprecated StrSubstitutor in Commons Lang in favor or its new
>>> home
>>> in Commons Text, where is has evolved further.
>>>
>>> In my view, StopWatch and now StackWatch, do not belong in the JRE or
>>> Commons Lang. It should sit slightly above that level. Where, is the
>>> question.
>>>
>>> Commons Testing for Stop/StackWatch does not seen quite right to me. I
>>> could see a new Commons Timing or a more general Commons Measurement;
>>> with
>>> a mandate NOT to overlap with Joda-Time and java.time.
>>>
>>> Gary
>>>
>>>
>>>
>>>
>>> > Gilles
>>> >
>>> >
>>> >> https://issues.apache.org/jira/browse/LANG-1373
>>> >>
>>> >> <https://issues.apache.org/jira/browse/LANG-1373?page=com.
>>> >> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
>>> >> tabpanel&focusedCommentId=16377279#comment-16377279>
>>> >> https://github.com/apache/commons-lang/pull/311
>>> >>
>>> >
>>> >
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

[Gilles Sadowski]

On Wed, 28 Feb 2018 08:56:07 -0700, Gary Gregory wrote:

> On Wed, Feb 28, 2018 at 6:35 AM, Gilles
> <[hidden email]>
> wrote:
>
>> Hello.
>>
>> On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>>
>>> Hi,
>>>
>>> In the course of working through my pull request for adding new
>>> LANG
>>> functionality on top of the StopWatch class, the issue has been
>>> raise as
>>> to
>>> if this functionality is ‘common’ or should
>>> be placed in a more specialized commons-xxxx component.
>>>
>>> We would like to take the discussion to the list for this, and see
>>> what
>>> everyone thinks.
>>>
>>> The StackWatch provides for tracking nested timings backed by
>>> StopWatch.
>>> You can start the watch, and start and stop multiple timings
>>> through the
>>> call stack. Each timing is named and tag and has it’s own time.
>>> You can visit all the timings, perhaps using the tags to filter
>>> when you
>>> are done.  Please see the PR/Jira for more details.  You should
>>> look at
>>> both, since the review has been split between the two.
>>>
>>> If not LANG, then where?  The commons-testing component has been
>>> mentioned.  But this code is not ‘test’ code explicitly.  In my use
>>> case (
>>> I wrote this for the Apache Metron project and thought it might be
>>> useful
>>> here) it would not be test code, in the sense that it would be used
>>> in
>>> ‘test’ scope in mvn.  Rather it would be deployed in production, in
>>> a
>>> REPL,
>>> and perhaps in other runtime components.
>>>
>>
>> Part of what makes a good component is that it does not dictate
>> how and where applications should use it.
>> The name "Testing" does not imply that its contents must be used
>> within "test" scope.
>>
>> A utility such as "StackWatch" could be another tool to integrate
>> in a unit test suite (e.g. to generate a more fine-grained timing
>> report than Junit does).  Hence the module in which "StackWatch"
>> will belong is to become a dependency of modules that target
>> specific test framework (and that is true whether the former is
>> defined within "Testing" or in another component).
>>
>> I would not want to pull in junit
>>> or other dependencies with any component containing it.
>>>
>>
>> +1
>> Must be ensured by proper granularity of the modular design.
>>
>> If we put it in commons-testing ( which already has sub-modules
>> which are
>>> geared towards junit ) it may be confusing, even if the module is
>>> explicit
>>> about purpose and keeping out junit dependent code ( or other
>>> testing
>>> code).
>>>
>>
>> Why would it be confusing?  The module will stand out on its own
>> (artefact/description/doc/web site) and be more visible than yet
>> another class in the already too large "Commons Lang".
>>
>> Also, besides the StackWatch, what else would go into the new target
>>> component?  Would StopWatch move as well for example?
>>>
>>
>> +1
>> But creating a new component for two small classes can reasonably
>> be argued as overkill.
>> FTR: I was asked to collect the sampling utilities within a
>> module of "Commons RNG" even though it could have warranted its
>> own component (being a plain "client" of the core functionality
>> of [RNG]).  In the present case, "StackWatch" would belong to
>> "core" utilities of "Testing" that are pulled (along with other
>> dependencies by the more specific modules.
>>
>
> I would ask all of us to step back for a moment and consider the big
> picture.

+1

> Specifically, what do you consider the mandate or guidelines for
> Commons
> Lang to be? For me, this is code that should or could have been in
> the JRE
> in java.lang or java.util. Looking ahead to Java 9, Commons Lang
> should
> likely only depend on java.base (it does today but this should be
> enforced
> with the Maven JDeps Plugin IMO.)

+1

> If you look at StringUtils, you can then see how this class has grown
> into
> a giant. You can also then see why other related code like a fancier
> String.replace() could creep in as StrSubstitutor and friends. Should
> variable interpolation have been in the JRE? Debatable, but it would
> be
> useful on top of Properties and ResourceBundle, one might argue; also
> handy
> for JAXB I would say. Nevertheless, WRT to Commons Lang, we --
> rightly IMO
> -- have deprecated StrSubstitutor in Commons Lang in favor or its new
> home
> in Commons Text, where is has evolved further.

Package "java.text" is in module "java.base".
Revise the naming? ;-)

> In my view, StopWatch and now StackWatch, do not belong in the JRE or
> Commons Lang. It should sit slightly above that level.

I agree, but to be consistent, many things should be deprecated
before the next release of [Lang].

> Where, is the
> question.

It depends on the intended use-cases. Currently, I lack imagination
and see it fitting in [Testing].

> Commons Testing for Stop/StackWatch does not seen quite right to me.
> I
> could see a new Commons Timing

Tentative description/scope?

> or a more general Commons Measurement;

Too vague and/or too broad:
   https://en.wikipedia.org/wiki/Measurement

> with
> a mandate NOT to overlap with Joda-Time and java.time.

Feature at hand is more about timer[1] than about date and
time manipulation.

The discussion should avoid implicit meanings. [We've been
there with opinions about "math" or "random" purely based
on a "name".]

Regards,
Gilles

[1] https://docs.oracle.com/javase/9/docs/api/java/util/Timer.html

>
> Gary
>
>
>
>
>> Gilles
>>
>>
>>> https://issues.apache.org/jira/browse/LANG-1373
>>>
>>> <https://issues.apache.org/jira/browse/LANG-1373?page=com.
>>> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
>>> tabpanel&focusedCommentId=16377279#comment-16377279>
>>> https://github.com/apache/commons-lang/pull/311
>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Gilles Sadowski]

On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:

> 2018-02-28 17:11 GMT+01:00 Gilles <[hidden email]>:
>
>> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
>>
>>> Hi guys,
>>>
>>> On that topic we can keep in mind we retired not a lot time ago
>>> Apache
>>> Sirona which was a perf framework industrializing a stopwatch to
>>> summarize
>>> it.
>>> We can make it live again and would probably be a better fir than
>>> commons
>>> cause you quickly need more than just some time measurement when
>>> you start
>>> to work on these topics.
>>>
>>
>> Why was the project terminated?
>>
>
> Community didn't grow enough and activity was not that high - the
> project
> went stable pretty quickly. I forked it on github for now
> https://github.com/rmannibucau/sirona

Does it contain a feature similar to the "StackWatch"
proposed in
   https://issues.apache.org/jira/browse/LANG-1373
?

If so, do you suggest that Otto's project should depend
on Sirona?

If not, do you suggest that Otto should submit the PR
to Sirona (and then depend on it)?

Gilles

>>
>>
>>> Just my 2 cts
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github
>>> <https://github.com/rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>
>>> <https://www.packtpub.com/application-development/java-ee-8-
>>> high-performance>
>>>
>>>
>>> 2018-02-28 16:56 GMT+01:00 Gary Gregory <[hidden email]>:
>>>
>>> On Wed, Feb 28, 2018 at 6:35 AM, Gilles
>>> <[hidden email]>
>>>> wrote:
>>>>
>>>> > Hello.
>>>> >
>>>> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>>>> >
>>>> >> Hi,
>>>> >>
>>>> >> In the course of working through my pull request for adding new
>>>> LANG
>>>> >> functionality on top of the StopWatch class, the issue has been
>>>> raise
>>>> as
>>>> >> to
>>>> >> if this functionality is ‘common’ or should
>>>> >> be placed in a more specialized commons-xxxx component.
>>>> >>
>>>> >> We would like to take the discussion to the list for this, and
>>>> see
>>>> what
>>>> >> everyone thinks.
>>>> >>
>>>> >> The StackWatch provides for tracking nested timings backed by
>>>> StopWatch.
>>>> >> You can start the watch, and start and stop multiple timings
>>>> through
>>>> the
>>>> >> call stack. Each timing is named and tag and has it’s own time.
>>>> >> You can visit all the timings, perhaps using the tags to filter
>>>> when
>>>> you
>>>> >> are done.  Please see the PR/Jira for more details.  You should
>>>> look
>>>> at
>>>> >> both, since the review has been split between the two.
>>>> >>
>>>> >> If not LANG, then where?  The commons-testing component has
>>>> been
>>>> >> mentioned.  But this code is not ‘test’ code explicitly.  In my
>>>> use
>>>> case (
>>>> >> I wrote this for the Apache Metron project and thought it might
>>>> be
>>>> useful
>>>> >> here) it would not be test code, in the sense that it would be
>>>> used in
>>>> >> ‘test’ scope in mvn.  Rather it would be deployed in
>>>> production, in a
>>>> >> REPL,
>>>> >> and perhaps in other runtime components.
>>>> >>
>>>> >
>>>> > Part of what makes a good component is that it does not dictate
>>>> > how and where applications should use it.
>>>> > The name "Testing" does not imply that its contents must be used
>>>> > within "test" scope.
>>>> >
>>>> > A utility such as "StackWatch" could be another tool to
>>>> integrate
>>>> > in a unit test suite (e.g. to generate a more fine-grained
>>>> timing
>>>> > report than Junit does).  Hence the module in which "StackWatch"
>>>> > will belong is to become a dependency of modules that target
>>>> > specific test framework (and that is true whether the former is
>>>> > defined within "Testing" or in another component).
>>>> >
>>>> > I would not want to pull in junit
>>>> >> or other dependencies with any component containing it.
>>>> >>
>>>> >
>>>> > +1
>>>> > Must be ensured by proper granularity of the modular design.
>>>> >
>>>> > If we put it in commons-testing ( which already has sub-modules
>>>> which
>>>> are
>>>> >> geared towards junit ) it may be confusing, even if the module
>>>> is
>>>> explicit
>>>> >> about purpose and keeping out junit dependent code ( or other
>>>> testing
>>>> >> code).
>>>> >>
>>>> >
>>>> > Why would it be confusing?  The module will stand out on its own
>>>> > (artefact/description/doc/web site) and be more visible than yet
>>>> > another class in the already too large "Commons Lang".
>>>> >
>>>> > Also, besides the StackWatch, what else would go into the new
>>>> target
>>>> >> component?  Would StopWatch move as well for example?
>>>> >>
>>>> >
>>>> > +1
>>>> > But creating a new component for two small classes can
>>>> reasonably
>>>> > be argued as overkill.
>>>> > FTR: I was asked to collect the sampling utilities within a
>>>> > module of "Commons RNG" even though it could have warranted its
>>>> > own component (being a plain "client" of the core functionality
>>>> > of [RNG]).  In the present case, "StackWatch" would belong to
>>>> > "core" utilities of "Testing" that are pulled (along with other
>>>> > dependencies by the more specific modules.
>>>> >
>>>>
>>>> I would ask all of us to step back for a moment and consider the
>>>> big
>>>> picture.
>>>>
>>>> Specifically, what do you consider the mandate or guidelines for
>>>> Commons
>>>> Lang to be? For me, this is code that should or could have been in
>>>> the
>>>> JRE
>>>> in java.lang or java.util. Looking ahead to Java 9, Commons Lang
>>>> should
>>>> likely only depend on java.base (it does today but this should be
>>>> enforced
>>>> with the Maven JDeps Plugin IMO.)
>>>>
>>>> If you look at StringUtils, you can then see how this class has
>>>> grown
>>>> into
>>>> a giant. You can also then see why other related code like a
>>>> fancier
>>>> String.replace() could creep in as StrSubstitutor and friends.
>>>> Should
>>>> variable interpolation have been in the JRE? Debatable, but it
>>>> would be
>>>> useful on top of Properties and ResourceBundle, one might argue;
>>>> also
>>>> handy
>>>> for JAXB I would say. Nevertheless, WRT to Commons Lang, we --
>>>> rightly
>>>> IMO
>>>> -- have deprecated StrSubstitutor in Commons Lang in favor or its
>>>> new
>>>> home
>>>> in Commons Text, where is has evolved further.
>>>>
>>>> In my view, StopWatch and now StackWatch, do not belong in the JRE
>>>> or
>>>> Commons Lang. It should sit slightly above that level. Where, is
>>>> the
>>>> question.
>>>>
>>>> Commons Testing for Stop/StackWatch does not seen quite right to
>>>> me. I
>>>> could see a new Commons Timing or a more general Commons
>>>> Measurement;
>>>> with
>>>> a mandate NOT to overlap with Joda-Time and java.time.
>>>>
>>>> Gary
>>>>
>>>>
>>>>
>>>>
>>>> > Gilles
>>>> >
>>>> >
>>>> >> https://issues.apache.org/jira/browse/LANG-1373
>>>> >>
>>>> >> <https://issues.apache.org/jira/browse/LANG-1373?page=com.
>>>> >> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
>>>> >> tabpanel&focusedCommentId=16377279#comment-16377279>
>>>> >> https://github.com/apache/commons-lang/pull/311
>>>> >>
>>>> >
>>>> >
>>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Matt Sicker]

This sounds almost like a sort of Commons Metrics type project. See <
http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
project called Commons Monitoring which may be similar.

On 28 February 2018 at 10:56, Gilles <[hidden email]> wrote:

> On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
>
>> 2018-02-28 17:11 GMT+01:00 Gilles <[hidden email]>:
>>
>> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
>>>
>>> Hi guys,
>>>>
>>>> On that topic we can keep in mind we retired not a lot time ago Apache
>>>> Sirona which was a perf framework industrializing a stopwatch to
>>>> summarize
>>>> it.
>>>> We can make it live again and would probably be a better fir than
>>>> commons
>>>> cause you quickly need more than just some time measurement when you
>>>> start
>>>> to work on these topics.
>>>>
>>>>
>>> Why was the project terminated?
>>>
>>>
>> Community didn't grow enough and activity was not that high - the project
>> went stable pretty quickly. I forked it on github for now
>> https://github.com/rmannibucau/sirona
>>
>
> Does it contain a feature similar to the "StackWatch"
> proposed in
>   https://issues.apache.org/jira/browse/LANG-1373
> ?
>
> If so, do you suggest that Otto's project should depend
> on Sirona?
>
> If not, do you suggest that Otto should submit the PR
> to Sirona (and then depend on it)?
>
>
> Gilles
>
>
>>>
>>> Just my 2 cts
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>> <http://rmannibucau.wordpress.com> | Github
>>>> <https://github.com/rmannibucau> |
>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>
>>>> <https://www.packtpub.com/application-development/java-ee-8-
>>>> high-performance>
>>>>
>>>>
>>>> 2018-02-28 16:56 GMT+01:00 Gary Gregory <[hidden email]>:
>>>>
>>>> On Wed, Feb 28, 2018 at 6:35 AM, Gilles <[hidden email]>
>>>>
>>>>> wrote:
>>>>>
>>>>> > Hello.
>>>>> >
>>>>> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>>>>> >
>>>>> >> Hi,
>>>>> >>
>>>>> >> In the course of working through my pull request for adding new LANG
>>>>> >> functionality on top of the StopWatch class, the issue has been
>>>>> raise
>>>>> as
>>>>> >> to
>>>>> >> if this functionality is ‘common’ or should
>>>>> >> be placed in a more specialized commons-xxxx component.
>>>>> >>
>>>>> >> We would like to take the discussion to the list for this, and see
>>>>> what
>>>>> >> everyone thinks.
>>>>> >>
>>>>> >> The StackWatch provides for tracking nested timings backed by
>>>>> StopWatch.
>>>>> >> You can start the watch, and start and stop multiple timings through
>>>>> the
>>>>> >> call stack. Each timing is named and tag and has it’s own time.
>>>>> >> You can visit all the timings, perhaps using the tags to filter when
>>>>> you
>>>>> >> are done.  Please see the PR/Jira for more details.  You should look
>>>>> at
>>>>> >> both, since the review has been split between the two.
>>>>> >>
>>>>> >> If not LANG, then where?  The commons-testing component has been
>>>>> >> mentioned.  But this code is not ‘test’ code explicitly.  In my use
>>>>> case (
>>>>> >> I wrote this for the Apache Metron project and thought it might be
>>>>> useful
>>>>> >> here) it would not be test code, in the sense that it would be used
>>>>> in
>>>>> >> ‘test’ scope in mvn.  Rather it would be deployed in production, in
>>>>> a
>>>>> >> REPL,
>>>>> >> and perhaps in other runtime components.
>>>>> >>
>>>>> >
>>>>> > Part of what makes a good component is that it does not dictate
>>>>> > how and where applications should use it.
>>>>> > The name "Testing" does not imply that its contents must be used
>>>>> > within "test" scope.
>>>>> >
>>>>> > A utility such as "StackWatch" could be another tool to integrate
>>>>> > in a unit test suite (e.g. to generate a more fine-grained timing
>>>>> > report than Junit does).  Hence the module in which "StackWatch"
>>>>> > will belong is to become a dependency of modules that target
>>>>> > specific test framework (and that is true whether the former is
>>>>> > defined within "Testing" or in another component).
>>>>> >
>>>>> > I would not want to pull in junit
>>>>> >> or other dependencies with any component containing it.
>>>>> >>
>>>>> >
>>>>> > +1
>>>>> > Must be ensured by proper granularity of the modular design.
>>>>> >
>>>>> > If we put it in commons-testing ( which already has sub-modules which
>>>>> are
>>>>> >> geared towards junit ) it may be confusing, even if the module is
>>>>> explicit
>>>>> >> about purpose and keeping out junit dependent code ( or other
>>>>> testing
>>>>> >> code).
>>>>> >>
>>>>> >
>>>>> > Why would it be confusing?  The module will stand out on its own
>>>>> > (artefact/description/doc/web site) and be more visible than yet
>>>>> > another class in the already too large "Commons Lang".
>>>>> >
>>>>> > Also, besides the StackWatch, what else would go into the new target
>>>>> >> component?  Would StopWatch move as well for example?
>>>>> >>
>>>>> >
>>>>> > +1
>>>>> > But creating a new component for two small classes can reasonably
>>>>> > be argued as overkill.
>>>>> > FTR: I was asked to collect the sampling utilities within a
>>>>> > module of "Commons RNG" even though it could have warranted its
>>>>> > own component (being a plain "client" of the core functionality
>>>>> > of [RNG]).  In the present case, "StackWatch" would belong to
>>>>> > "core" utilities of "Testing" that are pulled (along with other
>>>>> > dependencies by the more specific modules.
>>>>> >
>>>>>
>>>>> I would ask all of us to step back for a moment and consider the big
>>>>> picture.
>>>>>
>>>>> Specifically, what do you consider the mandate or guidelines for
>>>>> Commons
>>>>> Lang to be? For me, this is code that should or could have been in the
>>>>> JRE
>>>>> in java.lang or java.util. Looking ahead to Java 9, Commons Lang should
>>>>> likely only depend on java.base (it does today but this should be
>>>>> enforced
>>>>> with the Maven JDeps Plugin IMO.)
>>>>>
>>>>> If you look at StringUtils, you can then see how this class has grown
>>>>> into
>>>>> a giant. You can also then see why other related code like a fancier
>>>>> String.replace() could creep in as StrSubstitutor and friends. Should
>>>>> variable interpolation have been in the JRE? Debatable, but it would be
>>>>> useful on top of Properties and ResourceBundle, one might argue; also
>>>>> handy
>>>>> for JAXB I would say. Nevertheless, WRT to Commons Lang, we -- rightly
>>>>> IMO
>>>>> -- have deprecated StrSubstitutor in Commons Lang in favor or its new
>>>>> home
>>>>> in Commons Text, where is has evolved further.
>>>>>
>>>>> In my view, StopWatch and now StackWatch, do not belong in the JRE or
>>>>> Commons Lang. It should sit slightly above that level. Where, is the
>>>>> question.
>>>>>
>>>>> Commons Testing for Stop/StackWatch does not seen quite right to me. I
>>>>> could see a new Commons Timing or a more general Commons Measurement;
>>>>> with
>>>>> a mandate NOT to overlap with Joda-Time and java.time.
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> > Gilles
>>>>> >
>>>>> >
>>>>> >> https://issues.apache.org/jira/browse/LANG-1373
>>>>> >>
>>>>> >> <https://issues.apache.org/jira/browse/LANG-1373?page=com.
>>>>> >> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
>>>>> >> tabpanel&focusedCommentId=16377279#comment-16377279>
>>>>> >> https://github.com/apache/commons-lang/pull/311
>>>>> >>
>>>>> >
>>>>> >
>>>>>
>>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Matt Sicker <[hidden email]>

[Romain Manni-Bucau]

Le 28 févr. 2018 19:27, "Matt Sicker" <[hidden email]> a écrit :

This sounds almost like a sort of Commons Metrics type project. See <
http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
project called Commons Monitoring which may be similar.


Sirona started from commons-monitoring ;)



On 28 February 2018 at 10:56, Gilles <[hidden email]> wrote:

> On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
>
>> 2018-02-28 17:11 GMT+01:00 Gilles <[hidden email]>:
>>
>> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
>>>
>>> Hi guys,
>>>>
>>>> On that topic we can keep in mind we retired not a lot time ago Apache
>>>> Sirona which was a perf framework industrializing a stopwatch to
>>>> summarize
>>>> it.
>>>> We can make it live again and would probably be a better fir than
>>>> commons
>>>> cause you quickly need more than just some time measurement when you
>>>> start
>>>> to work on these topics.
>>>>
>>>>
>>> Why was the project terminated?
>>>
>>>
>> Community didn't grow enough and activity was not that high - the project
>> went stable pretty quickly. I forked it on github for now
>> https://github.com/rmannibucau/sirona
>>
>
> Does it contain a feature similar to the "StackWatch"
> proposed in
>   https://issues.apache.org/jira/browse/LANG-1373
> ?
>
> If so, do you suggest that Otto's project should depend
> on Sirona?
>
> If not, do you suggest that Otto should submit the PR
> to Sirona (and then depend on it)?
>
>
> Gilles
>
>
>>>
>>> Just my 2 cts
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>> <http://rmannibucau.wordpress.com> | Github
>>>> <https://github.com/rmannibucau> |
>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>
>>>> <https://www.packtpub.com/application-development/java-ee-8-
>>>> high-performance>
>>>>
>>>>
>>>> 2018-02-28 16:56 GMT+01:00 Gary Gregory <[hidden email]>:
>>>>
>>>> On Wed, Feb 28, 2018 at 6:35 AM, Gilles <[hidden email]>
>>>>
>>>>> wrote:
>>>>>
>>>>> > Hello.
>>>>> >
>>>>> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>>>>> >
>>>>> >> Hi,
>>>>> >>
>>>>> >> In the course of working through my pull request for adding new

LANG

>>>>> >> functionality on top of the StopWatch class, the issue has been
>>>>> raise
>>>>> as
>>>>> >> to
>>>>> >> if this functionality is ‘common’ or should
>>>>> >> be placed in a more specialized commons-xxxx component.
>>>>> >>
>>>>> >> We would like to take the discussion to the list for this, and see
>>>>> what
>>>>> >> everyone thinks.
>>>>> >>
>>>>> >> The StackWatch provides for tracking nested timings backed by
>>>>> StopWatch.
>>>>> >> You can start the watch, and start and stop multiple timings

through
>>>>> the
>>>>> >> call stack. Each timing is named and tag and has it’s own time.
>>>>> >> You can visit all the timings, perhaps using the tags to filter
when
>>>>> you
>>>>> >> are done.  Please see the PR/Jira for more details.  You should
look

>>>>> at
>>>>> >> both, since the review has been split between the two.
>>>>> >>
>>>>> >> If not LANG, then where?  The commons-testing component has been
>>>>> >> mentioned.  But this code is not ‘test’ code explicitly.  In my use
>>>>> case (
>>>>> >> I wrote this for the Apache Metron project and thought it might be
>>>>> useful
>>>>> >> here) it would not be test code, in the sense that it would be used
>>>>> in
>>>>> >> ‘test’ scope in mvn.  Rather it would be deployed in production, in
>>>>> a
>>>>> >> REPL,
>>>>> >> and perhaps in other runtime components.
>>>>> >>
>>>>> >
>>>>> > Part of what makes a good component is that it does not dictate
>>>>> > how and where applications should use it.
>>>>> > The name "Testing" does not imply that its contents must be used
>>>>> > within "test" scope.
>>>>> >
>>>>> > A utility such as "StackWatch" could be another tool to integrate
>>>>> > in a unit test suite (e.g. to generate a more fine-grained timing
>>>>> > report than Junit does).  Hence the module in which "StackWatch"
>>>>> > will belong is to become a dependency of modules that target
>>>>> > specific test framework (and that is true whether the former is
>>>>> > defined within "Testing" or in another component).
>>>>> >
>>>>> > I would not want to pull in junit
>>>>> >> or other dependencies with any component containing it.
>>>>> >>
>>>>> >
>>>>> > +1
>>>>> > Must be ensured by proper granularity of the modular design.
>>>>> >
>>>>> > If we put it in commons-testing ( which already has sub-modules

which

>>>>> are
>>>>> >> geared towards junit ) it may be confusing, even if the module is
>>>>> explicit
>>>>> >> about purpose and keeping out junit dependent code ( or other
>>>>> testing
>>>>> >> code).
>>>>> >>
>>>>> >
>>>>> > Why would it be confusing?  The module will stand out on its own
>>>>> > (artefact/description/doc/web site) and be more visible than yet
>>>>> > another class in the already too large "Commons Lang".
>>>>> >
>>>>> > Also, besides the StackWatch, what else would go into the new target
>>>>> >> component?  Would StopWatch move as well for example?
>>>>> >>
>>>>> >
>>>>> > +1
>>>>> > But creating a new component for two small classes can reasonably
>>>>> > be argued as overkill.
>>>>> > FTR: I was asked to collect the sampling utilities within a
>>>>> > module of "Commons RNG" even though it could have warranted its
>>>>> > own component (being a plain "client" of the core functionality
>>>>> > of [RNG]).  In the present case, "StackWatch" would belong to
>>>>> > "core" utilities of "Testing" that are pulled (along with other
>>>>> > dependencies by the more specific modules.
>>>>> >
>>>>>
>>>>> I would ask all of us to step back for a moment and consider the big
>>>>> picture.
>>>>>
>>>>> Specifically, what do you consider the mandate or guidelines for
>>>>> Commons
>>>>> Lang to be? For me, this is code that should or could have been in the
>>>>> JRE
>>>>> in java.lang or java.util. Looking ahead to Java 9, Commons Lang

should
>>>>> likely only depend on java.base (it does today but this should be
>>>>> enforced
>>>>> with the Maven JDeps Plugin IMO.)
>>>>>
>>>>> If you look at StringUtils, you can then see how this class has grown
>>>>> into
>>>>> a giant. You can also then see why other related code like a fancier
>>>>> String.replace() could creep in as StrSubstitutor and friends. Should
>>>>> variable interpolation have been in the JRE? Debatable, but it would
be

>>>>> useful on top of Properties and ResourceBundle, one might argue; also
>>>>> handy
>>>>> for JAXB I would say. Nevertheless, WRT to Commons Lang, we -- rightly
>>>>> IMO
>>>>> -- have deprecated StrSubstitutor in Commons Lang in favor or its new
>>>>> home
>>>>> in Commons Text, where is has evolved further.
>>>>>
>>>>> In my view, StopWatch and now StackWatch, do not belong in the JRE or
>>>>> Commons Lang. It should sit slightly above that level. Where, is the
>>>>> question.
>>>>>
>>>>> Commons Testing for Stop/StackWatch does not seen quite right to me. I
>>>>> could see a new Commons Timing or a more general Commons Measurement;
>>>>> with
>>>>> a mandate NOT to overlap with Joda-Time and java.time.
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> > Gilles
>>>>> >
>>>>> >
>>>>> >> https://issues.apache.org/jira/browse/LANG-1373
>>>>> >>
>>>>> >> <https://issues.apache.org/jira/browse/LANG-1373?page=com.
>>>>> >> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
>>>>> >> tabpanel&focusedCommentId=16377279#comment-16377279>
>>>>> >> https://github.com/apache/commons-lang/pull/311
>>>>> >>
>>>>> >
>>>>> >
>>>>>
>>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Matt Sicker <[hidden email]>

[Otto Fowler]

My understanding is that sirona was/is a complete system, as opposed to a
collection of utilities.
If StackWatch is too big for LANG it seems too small for sirona.  Along
with sirona being retired etc.



On February 28, 2018 at 15:06:52, Romain Manni-Bucau ([hidden email])
wrote:

Le 28 févr. 2018 19:27, "Matt Sicker" <[hidden email]> a écrit :

This sounds almost like a sort of Commons Metrics type project. See <
http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
project called Commons Monitoring which may be similar.


Sirona started from commons-monitoring ;)



On 28 February 2018 at 10:56, Gilles <[hidden email]> wrote:

> On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
>
>> 2018-02-28 17:11 GMT+01:00 Gilles <[hidden email]>:
>>
>> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
>>>
>>> Hi guys,
>>>>
>>>> On that topic we can keep in mind we retired not a lot time ago Apache
>>>> Sirona which was a perf framework industrializing a stopwatch to
>>>> summarize
>>>> it.
>>>> We can make it live again and would probably be a better fir than
>>>> commons
>>>> cause you quickly need more than just some time measurement when you
>>>> start
>>>> to work on these topics.
>>>>
>>>>
>>> Why was the project terminated?
>>>
>>>
>> Community didn't grow enough and activity was not that high - the

project

>> went stable pretty quickly. I forked it on github for now
>> https://github.com/rmannibucau/sirona
>>
>
> Does it contain a feature similar to the "StackWatch"
> proposed in
> https://issues.apache.org/jira/browse/LANG-1373
> ?
>
> If so, do you suggest that Otto's project should depend
> on Sirona?
>
> If not, do you suggest that Otto should submit the PR
> to Sirona (and then depend on it)?
>
>
> Gilles
>
>
>>>
>>> Just my 2 cts
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>> <http://rmannibucau.wordpress.com> | Github
>>>> <https://github.com/rmannibucau> |
>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>
>>>> <https://www.packtpub.com/application-development/java-ee-8-
>>>> high-performance>
>>>>
>>>>
>>>> 2018-02-28 16:56 GMT+01:00 Gary Gregory <[hidden email]>:
>>>>
>>>> On Wed, Feb 28, 2018 at 6:35 AM, Gilles <[hidden email]>
>>>>
>>>>> wrote:
>>>>>
>>>>> > Hello.
>>>>> >
>>>>> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>>>>> >
>>>>> >> Hi,
>>>>> >>
>>>>> >> In the course of working through my pull request for adding new

LANG

>>>>> >> functionality on top of the StopWatch class, the issue has been
>>>>> raise
>>>>> as
>>>>> >> to
>>>>> >> if this functionality is ‘common’ or should
>>>>> >> be placed in a more specialized commons-xxxx component.
>>>>> >>
>>>>> >> We would like to take the discussion to the list for this, and see
>>>>> what
>>>>> >> everyone thinks.
>>>>> >>
>>>>> >> The StackWatch provides for tracking nested timings backed by
>>>>> StopWatch.
>>>>> >> You can start the watch, and start and stop multiple timings

through
>>>>> the
>>>>> >> call stack. Each timing is named and tag and has it’s own time.
>>>>> >> You can visit all the timings, perhaps using the tags to filter
when
>>>>> you
>>>>> >> are done. Please see the PR/Jira for more details. You should
look
>>>>> at
>>>>> >> both, since the review has been split between the two.
>>>>> >>
>>>>> >> If not LANG, then where? The commons-testing component has been
>>>>> >> mentioned. But this code is not ‘test’ code explicitly. In my use
>>>>> case (
>>>>> >> I wrote this for the Apache Metron project and thought it might be
>>>>> useful
>>>>> >> here) it would not be test code, in the sense that it would be
used

>>>>> in
>>>>> >> ‘test’ scope in mvn. Rather it would be deployed in production, in
>>>>> a
>>>>> >> REPL,
>>>>> >> and perhaps in other runtime components.
>>>>> >>
>>>>> >
>>>>> > Part of what makes a good component is that it does not dictate
>>>>> > how and where applications should use it.
>>>>> > The name "Testing" does not imply that its contents must be used
>>>>> > within "test" scope.
>>>>> >
>>>>> > A utility such as "StackWatch" could be another tool to integrate
>>>>> > in a unit test suite (e.g. to generate a more fine-grained timing
>>>>> > report than Junit does). Hence the module in which "StackWatch"
>>>>> > will belong is to become a dependency of modules that target
>>>>> > specific test framework (and that is true whether the former is
>>>>> > defined within "Testing" or in another component).
>>>>> >
>>>>> > I would not want to pull in junit
>>>>> >> or other dependencies with any component containing it.
>>>>> >>
>>>>> >
>>>>> > +1
>>>>> > Must be ensured by proper granularity of the modular design.
>>>>> >
>>>>> > If we put it in commons-testing ( which already has sub-modules

which

>>>>> are
>>>>> >> geared towards junit ) it may be confusing, even if the module is
>>>>> explicit
>>>>> >> about purpose and keeping out junit dependent code ( or other
>>>>> testing
>>>>> >> code).
>>>>> >>
>>>>> >
>>>>> > Why would it be confusing? The module will stand out on its own
>>>>> > (artefact/description/doc/web site) and be more visible than yet
>>>>> > another class in the already too large "Commons Lang".
>>>>> >
>>>>> > Also, besides the StackWatch, what else would go into the new

target

>>>>> >> component? Would StopWatch move as well for example?
>>>>> >>
>>>>> >
>>>>> > +1
>>>>> > But creating a new component for two small classes can reasonably
>>>>> > be argued as overkill.
>>>>> > FTR: I was asked to collect the sampling utilities within a
>>>>> > module of "Commons RNG" even though it could have warranted its
>>>>> > own component (being a plain "client" of the core functionality
>>>>> > of [RNG]). In the present case, "StackWatch" would belong to
>>>>> > "core" utilities of "Testing" that are pulled (along with other
>>>>> > dependencies by the more specific modules.
>>>>> >
>>>>>
>>>>> I would ask all of us to step back for a moment and consider the big
>>>>> picture.
>>>>>
>>>>> Specifically, what do you consider the mandate or guidelines for
>>>>> Commons
>>>>> Lang to be? For me, this is code that should or could have been in

the
>>>>> JRE
>>>>> in java.lang or java.util. Looking ahead to Java 9, Commons Lang
should
>>>>> likely only depend on java.base (it does today but this should be
>>>>> enforced
>>>>> with the Maven JDeps Plugin IMO.)
>>>>>
>>>>> If you look at StringUtils, you can then see how this class has grown
>>>>> into
>>>>> a giant. You can also then see why other related code like a fancier
>>>>> String.replace() could creep in as StrSubstitutor and friends. Should
>>>>> variable interpolation have been in the JRE? Debatable, but it would
be
>>>>> useful on top of Properties and ResourceBundle, one might argue; also
>>>>> handy
>>>>> for JAXB I would say. Nevertheless, WRT to Commons Lang, we --
rightly

>>>>> IMO
>>>>> -- have deprecated StrSubstitutor in Commons Lang in favor or its new
>>>>> home
>>>>> in Commons Text, where is has evolved further.
>>>>>
>>>>> In my view, StopWatch and now StackWatch, do not belong in the JRE or
>>>>> Commons Lang. It should sit slightly above that level. Where, is the
>>>>> question.
>>>>>
>>>>> Commons Testing for Stop/StackWatch does not seen quite right to me.

I

>>>>> could see a new Commons Timing or a more general Commons Measurement;
>>>>> with
>>>>> a mandate NOT to overlap with Joda-Time and java.time.
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> > Gilles
>>>>> >
>>>>> >
>>>>> >> https://issues.apache.org/jira/browse/LANG-1373
>>>>> >>
>>>>> >> <https://issues.apache.org/jira/browse/LANG-1373?page=com.
>>>>> >> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
>>>>> >> tabpanel&focusedCommentId=16377279#comment-16377279>
>>>>> >> https://github.com/apache/commons-lang/pull/311
>>>>> >>
>>>>> >
>>>>> >
>>>>>
>>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Matt Sicker <[hidden email]>

[Romain Manni-Bucau]

This i right but it started as just a few utilities and interception
modules, then it grows as any performance related project. We also have
skywalking which is quite big but can host all that utility part @asf.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-02 14:45 GMT+01:00 Otto Fowler <[hidden email]>:

> My understanding is that sirona was/is a complete system, as opposed to a
> collection of utilities.
> If StackWatch is too big for LANG it seems too small for sirona.  Along
> with sirona being retired etc.
>
>
>
> On February 28, 2018 at 15:06:52, Romain Manni-Bucau (
> [hidden email]) wrote:
>
> Le 28 févr. 2018 19:27, "Matt Sicker" <[hidden email]> a écrit :
>
> This sounds almost like a sort of Commons Metrics type project. See <
> http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
> project called Commons Monitoring which may be similar.
>
>
> Sirona started from commons-monitoring ;)
>
>
>
> On 28 February 2018 at 10:56, Gilles <[hidden email]>
> wrote:
>
> > On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
> >
> >> 2018-02-28 17:11 GMT+01:00 Gilles <[hidden email]>:
> >>
> >> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
> >>>
> >>> Hi guys,
> >>>>
> >>>> On that topic we can keep in mind we retired not a lot time ago
> Apache
> >>>> Sirona which was a perf framework industrializing a stopwatch to
> >>>> summarize
> >>>> it.
> >>>> We can make it live again and would probably be a better fir than
> >>>> commons
> >>>> cause you quickly need more than just some time measurement when you
> >>>> start
> >>>> to work on these topics.
> >>>>
> >>>>
> >>> Why was the project terminated?
> >>>
> >>>
> >> Community didn't grow enough and activity was not that high - the
> project
> >> went stable pretty quickly. I forked it on github for now
> >> https://github.com/rmannibucau/sirona
> >>
> >
> > Does it contain a feature similar to the "StackWatch"
> > proposed in
> > https://issues.apache.org/jira/browse/LANG-1373
> > ?
> >
> > If so, do you suggest that Otto's project should depend
> > on Sirona?
> >
> > If not, do you suggest that Otto should submit the PR
> > to Sirona (and then depend on it)?
> >
> >
> > Gilles
> >
> >
> >>>
> >>> Just my 2 cts
> >>>>
> >>>>
> >>>> Romain Manni-Bucau
> >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> >>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>> <http://rmannibucau.wordpress.com> | Github
> >>>> <https://github.com/rmannibucau> |
> >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>>>
> >>>> <https://www.packtpub.com/application-development/java-ee-8-
> >>>> high-performance>
> >>>>
> >>>>
> >>>> 2018-02-28 16:56 GMT+01:00 Gary Gregory <[hidden email]>:
> >>>>
> >>>> On Wed, Feb 28, 2018 at 6:35 AM, Gilles <[hidden email]>
>
> >>>>
> >>>>> wrote:
> >>>>>
> >>>>> > Hello.
> >>>>> >
> >>>>> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
> >>>>> >
> >>>>> >> Hi,
> >>>>> >>
> >>>>> >> In the course of working through my pull request for adding new
> LANG
> >>>>> >> functionality on top of the StopWatch class, the issue has been
> >>>>> raise
> >>>>> as
> >>>>> >> to
> >>>>> >> if this functionality is ‘common’ or should
> >>>>> >> be placed in a more specialized commons-xxxx component.
> >>>>> >>
> >>>>> >> We would like to take the discussion to the list for this, and
> see
> >>>>> what
> >>>>> >> everyone thinks.
> >>>>> >>
> >>>>> >> The StackWatch provides for tracking nested timings backed by
> >>>>> StopWatch.
> >>>>> >> You can start the watch, and start and stop multiple timings
> through
> >>>>> the
> >>>>> >> call stack. Each timing is named and tag and has it’s own time.
> >>>>> >> You can visit all the timings, perhaps using the tags to filter
> when
> >>>>> you
> >>>>> >> are done. Please see the PR/Jira for more details. You should
> look
> >>>>> at
> >>>>> >> both, since the review has been split between the two.
> >>>>> >>
> >>>>> >> If not LANG, then where? The commons-testing component has been
> >>>>> >> mentioned. But this code is not ‘test’ code explicitly. In my use
> >>>>> case (
> >>>>> >> I wrote this for the Apache Metron project and thought it might
> be
> >>>>> useful
> >>>>> >> here) it would not be test code, in the sense that it would be
> used
> >>>>> in
> >>>>> >> ‘test’ scope in mvn. Rather it would be deployed in production,
> in
> >>>>> a
> >>>>> >> REPL,
> >>>>> >> and perhaps in other runtime components.
> >>>>> >>
> >>>>> >
> >>>>> > Part of what makes a good component is that it does not dictate
> >>>>> > how and where applications should use it.
> >>>>> > The name "Testing" does not imply that its contents must be used
> >>>>> > within "test" scope.
> >>>>> >
> >>>>> > A utility such as "StackWatch" could be another tool to integrate
> >>>>> > in a unit test suite (e.g. to generate a more fine-grained timing
> >>>>> > report than Junit does). Hence the module in which "StackWatch"
> >>>>> > will belong is to become a dependency of modules that target
> >>>>> > specific test framework (and that is true whether the former is
> >>>>> > defined within "Testing" or in another component).
> >>>>> >
> >>>>> > I would not want to pull in junit
> >>>>> >> or other dependencies with any component containing it.
> >>>>> >>
> >>>>> >
> >>>>> > +1
> >>>>> > Must be ensured by proper granularity of the modular design.
> >>>>> >
> >>>>> > If we put it in commons-testing ( which already has sub-modules
> which
> >>>>> are
> >>>>> >> geared towards junit ) it may be confusing, even if the module is
> >>>>> explicit
> >>>>> >> about purpose and keeping out junit dependent code ( or other
> >>>>> testing
> >>>>> >> code).
> >>>>> >>
> >>>>> >
> >>>>> > Why would it be confusing? The module will stand out on its own
> >>>>> > (artefact/description/doc/web site) and be more visible than yet
> >>>>> > another class in the already too large "Commons Lang".
> >>>>> >
> >>>>> > Also, besides the StackWatch, what else would go into the new
> target
> >>>>> >> component? Would StopWatch move as well for example?
> >>>>> >>
> >>>>> >
> >>>>> > +1
> >>>>> > But creating a new component for two small classes can reasonably
> >>>>> > be argued as overkill.
> >>>>> > FTR: I was asked to collect the sampling utilities within a
> >>>>> > module of "Commons RNG" even though it could have warranted its
> >>>>> > own component (being a plain "client" of the core functionality
> >>>>> > of [RNG]). In the present case, "StackWatch" would belong to
> >>>>> > "core" utilities of "Testing" that are pulled (along with other
> >>>>> > dependencies by the more specific modules.
> >>>>> >
> >>>>>
> >>>>> I would ask all of us to step back for a moment and consider the big
> >>>>> picture.
> >>>>>
> >>>>> Specifically, what do you consider the mandate or guidelines for
> >>>>> Commons
> >>>>> Lang to be? For me, this is code that should or could have been in
> the
> >>>>> JRE
> >>>>> in java.lang or java.util. Looking ahead to Java 9, Commons Lang
> should
> >>>>> likely only depend on java.base (it does today but this should be
> >>>>> enforced
> >>>>> with the Maven JDeps Plugin IMO.)
> >>>>>
> >>>>> If you look at StringUtils, you can then see how this class has
> grown
> >>>>> into
> >>>>> a giant. You can also then see why other related code like a fancier
> >>>>> String.replace() could creep in as StrSubstitutor and friends.
> Should
> >>>>> variable interpolation have been in the JRE? Debatable, but it would
> be
> >>>>> useful on top of Properties and ResourceBundle, one might argue;
> also
> >>>>> handy
> >>>>> for JAXB I would say. Nevertheless, WRT to Commons Lang, we --
> rightly
> >>>>> IMO
> >>>>> -- have deprecated StrSubstitutor in Commons Lang in favor or its
> new
> >>>>> home
> >>>>> in Commons Text, where is has evolved further.
> >>>>>
> >>>>> In my view, StopWatch and now StackWatch, do not belong in the JRE
> or
> >>>>> Commons Lang. It should sit slightly above that level. Where, is the
> >>>>> question.
> >>>>>
> >>>>> Commons Testing for Stop/StackWatch does not seen quite right to me.
> I
> >>>>> could see a new Commons Timing or a more general Commons
> Measurement;
> >>>>> with
> >>>>> a mandate NOT to overlap with Joda-Time and java.time.
> >>>>>
> >>>>> Gary
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> > Gilles
> >>>>> >
> >>>>> >
> >>>>> >> https://issues.apache.org/jira/browse/LANG-1373
> >>>>> >>
> >>>>> >> <https://issues.apache.org/jira/browse/LANG-1373?page=com.
> >>>>> >> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
> >>>>> >> tabpanel&focusedCommentId=16377279#comment-16377279>
> >>>>> >> https://github.com/apache/commons-lang/pull/311
> >>>>> >>
> >>>>> >
> >>>>> >
> >>>>>
> >>>>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Matt Sicker <[hidden email]>
>
>

[Otto Fowler]

I don’t understand the options that we are discussing here.  Can we clarify?

* create a new component from sirota, bringing it into commons ( resurrect
commons-monitoring ) and put StackWatch there?


On March 2, 2018 at 08:49:03, Romain Manni-Bucau ([hidden email])
wrote:

This i right but it started as just a few utilities and interception
modules, then it grows as any performance related project. We also have
skywalking which is quite big but can host all that utility part @asf.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-03-02 14:45 GMT+01:00 Otto Fowler <[hidden email]>:

> My understanding is that sirona was/is a complete system, as opposed to a
> collection of utilities.
> If StackWatch is too big for LANG it seems too small for sirona.  Along
> with sirona being retired etc.
>
>
>
> On February 28, 2018 at 15:06:52, Romain Manni-Bucau (
> [hidden email]) wrote:
>
> Le 28 févr. 2018 19:27, "Matt Sicker" <[hidden email]> a écrit :
>
> This sounds almost like a sort of Commons Metrics type project. See <
> http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
> project called Commons Monitoring which may be similar.
>
>
> Sirona started from commons-monitoring ;)
>
>
>
> On 28 February 2018 at 10:56, Gilles <[hidden email]> wrote:
>
> > On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
> >
> >> 2018-02-28 17:11 GMT+01:00 Gilles <[hidden email]>:
> >>
> >> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
> >>>
> >>> Hi guys,
> >>>>
> >>>> On that topic we can keep in mind we retired not a lot time ago Apache
> >>>> Sirona which was a perf framework industrializing a stopwatch to
> >>>> summarize
> >>>> it.
> >>>> We can make it live again and would probably be a better fir than
> >>>> commons
> >>>> cause you quickly need more than just some time measurement when you
> >>>> start
> >>>> to work on these topics.
> >>>>
> >>>>
> >>> Why was the project terminated?
> >>>
> >>>
> >> Community didn't grow enough and activity was not that high - the
> project
> >> went stable pretty quickly. I forked it on github for now
> >> https://github.com/rmannibucau/sirona
> >>
> >
> > Does it contain a feature similar to the "StackWatch"
> > proposed in
> > https://issues.apache.org/jira/browse/LANG-1373
> > ?
> >
> > If so, do you suggest that Otto's project should depend
> > on Sirona?
> >
> > If not, do you suggest that Otto should submit the PR
> > to Sirona (and then depend on it)?
> >
> >
> > Gilles
> >
> >
> >>>
> >>> Just my 2 cts
> >>>>
> >>>>
> >>>> Romain Manni-Bucau
> >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> >>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>> <http://rmannibucau.wordpress.com> | Github
> >>>> <https://github.com/rmannibucau> |
> >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>>>
> >>>> <https://www.packtpub.com/application-development/java-ee-8-
> >>>> high-performance>
> >>>>
> >>>>
> >>>> 2018-02-28 16:56 GMT+01:00 Gary Gregory <[hidden email]>:
> >>>>
> >>>> On Wed, Feb 28, 2018 at 6:35 AM, Gilles <[hidden email]
> >
> >>>>
> >>>>> wrote:
> >>>>>
> >>>>> > Hello.
> >>>>> >
> >>>>> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
> >>>>> >
> >>>>> >> Hi,
> >>>>> >>
> >>>>> >> In the course of working through my pull request for adding new
> LANG
> >>>>> >> functionality on top of the StopWatch class, the issue has been
> >>>>> raise
> >>>>> as
> >>>>> >> to
> >>>>> >> if this functionality is ‘common’ or should
> >>>>> >> be placed in a more specialized commons-xxxx component.
> >>>>> >>
> >>>>> >> We would like to take the discussion to the list for this, and see
> >>>>> what
> >>>>> >> everyone thinks.
> >>>>> >>
> >>>>> >> The StackWatch provides for tracking nested timings backed by
> >>>>> StopWatch.
> >>>>> >> You can start the watch, and start and stop multiple timings
> through
> >>>>> the
> >>>>> >> call stack. Each timing is named and tag and has it’s own time.
> >>>>> >> You can visit all the timings, perhaps using the tags to filter
> when
> >>>>> you
> >>>>> >> are done. Please see the PR/Jira for more details. You should
> look
> >>>>> at
> >>>>> >> both, since the review has been split between the two.
> >>>>> >>
> >>>>> >> If not LANG, then where? The commons-testing component has been
> >>>>> >> mentioned. But this code is not ‘test’ code explicitly. In my use
> >>>>> case (
> >>>>> >> I wrote this for the Apache Metron project and thought it might be
> >>>>> useful
> >>>>> >> here) it would not be test code, in the sense that it would be
> used
> >>>>> in
> >>>>> >> ‘test’ scope in mvn. Rather it would be deployed in production, in
> >>>>> a
> >>>>> >> REPL,
> >>>>> >> and perhaps in other runtime components.
> >>>>> >>
> >>>>> >
> >>>>> > Part of what makes a good component is that it does not dictate
> >>>>> > how and where applications should use it.
> >>>>> > The name "Testing" does not imply that its contents must be used
> >>>>> > within "test" scope.
> >>>>> >
> >>>>> > A utility such as "StackWatch" could be another tool to integrate
> >>>>> > in a unit test suite (e.g. to generate a more fine-grained timing
> >>>>> > report than Junit does). Hence the module in which "StackWatch"
> >>>>> > will belong is to become a dependency of modules that target
> >>>>> > specific test framework (and that is true whether the former is
> >>>>> > defined within "Testing" or in another component).
> >>>>> >
> >>>>> > I would not want to pull in junit
> >>>>> >> or other dependencies with any component containing it.
> >>>>> >>
> >>>>> >
> >>>>> > +1
> >>>>> > Must be ensured by proper granularity of the modular design.
> >>>>> >
> >>>>> > If we put it in commons-testing ( which already has sub-modules
> which
> >>>>> are
> >>>>> >> geared towards junit ) it may be confusing, even if the module is
> >>>>> explicit
> >>>>> >> about purpose and keeping out junit dependent code ( or other
> >>>>> testing
> >>>>> >> code).
> >>>>> >>
> >>>>> >
> >>>>> > Why would it be confusing? The module will stand out on its own
> >>>>> > (artefact/description/doc/web site) and be more visible than yet
> >>>>> > another class in the already too large "Commons Lang".
> >>>>> >
> >>>>> > Also, besides the StackWatch, what else would go into the new
> target
> >>>>> >> component? Would StopWatch move as well for example?
> >>>>> >>
> >>>>> >
> >>>>> > +1
> >>>>> > But creating a new component for two small classes can reasonably
> >>>>> > be argued as overkill.
> >>>>> > FTR: I was asked to collect the sampling utilities within a
> >>>>> > module of "Commons RNG" even though it could have warranted its
> >>>>> > own component (being a plain "client" of the core functionality
> >>>>> > of [RNG]). In the present case, "StackWatch" would belong to
> >>>>> > "core" utilities of "Testing" that are pulled (along with other
> >>>>> > dependencies by the more specific modules.
> >>>>> >
> >>>>>
> >>>>> I would ask all of us to step back for a moment and consider the big
> >>>>> picture.
> >>>>>
> >>>>> Specifically, what do you consider the mandate or guidelines for
> >>>>> Commons
> >>>>> Lang to be? For me, this is code that should or could have been in
> the
> >>>>> JRE
> >>>>> in java.lang or java.util. Looking ahead to Java 9, Commons Lang
> should
> >>>>> likely only depend on java.base (it does today but this should be
> >>>>> enforced
> >>>>> with the Maven JDeps Plugin IMO.)
> >>>>>
> >>>>> If you look at StringUtils, you can then see how this class has grown
> >>>>> into
> >>>>> a giant. You can also then see why other related code like a fancier
> >>>>> String.replace() could creep in as StrSubstitutor and friends. Should
> >>>>> variable interpolation have been in the JRE? Debatable, but it would
> be
> >>>>> useful on top of Properties and ResourceBundle, one might argue; also
> >>>>> handy
> >>>>> for JAXB I would say. Nevertheless, WRT to Commons Lang, we --
> rightly
> >>>>> IMO
> >>>>> -- have deprecated StrSubstitutor in Commons Lang in favor or its new
> >>>>> home
> >>>>> in Commons Text, where is has evolved further.
> >>>>>
> >>>>> In my view, StopWatch and now StackWatch, do not belong in the JRE or
> >>>>> Commons Lang. It should sit slightly above that level. Where, is the
> >>>>> question.
> >>>>>
> >>>>> Commons Testing for Stop/StackWatch does not seen quite right to me.
> I
> >>>>> could see a new Commons Timing or a more general Commons Measurement;
> >>>>> with
> >>>>> a mandate NOT to overlap with Joda-Time and java.time.
> >>>>>
> >>>>> Gary
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> > Gilles
> >>>>> >
> >>>>> >
> >>>>> >> https://issues.apache.org/jira/browse/LANG-1373
> >>>>> >>
> >>>>> >> <https://issues.apache.org/jira/browse/LANG-1373?page=com.
> >>>>> >> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
> >>>>> >> tabpanel&focusedCommentId=16377279#comment-16377279>
> >>>>> >> https://github.com/apache/commons-lang/pull/311
> >>>>> >>
> >>>>> >
> >>>>> >
> >>>>>
> >>>>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Matt Sicker <[hidden email]>
>
>

[Romain Manni-Bucau]

2018-03-02 15:31 GMT+01:00 Otto Fowler <[hidden email]>:

> I don’t understand the options that we are discussing here.  Can we
> clarify?
>
> * create a new component from sirota, bringing it into commons ( resurrect
> commons-monitoring ) and put StackWatch there?
>

I would more push to have a performance project, either we reuse one we
already have or we create back another one but commons will not fit very
well very long IMHO.

>
>
> On March 2, 2018 at 08:49:03, Romain Manni-Bucau ([hidden email])
> wrote:
>
> This i right but it started as just a few utilities and interception
> modules, then it grows as any performance related project. We also have
> skywalking which is quite big but can host all that utility part @asf.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
> 2018-03-02 14:45 GMT+01:00 Otto Fowler <[hidden email]>:
>
>> My understanding is that sirona was/is a complete system, as opposed to a
>> collection of utilities.
>> If StackWatch is too big for LANG it seems too small for sirona.  Along
>> with sirona being retired etc.
>>
>>
>>
>> On February 28, 2018 at 15:06:52, Romain Manni-Bucau (
>> [hidden email]) wrote:
>>
>> Le 28 févr. 2018 19:27, "Matt Sicker" <[hidden email]> a écrit :
>>
>> This sounds almost like a sort of Commons Metrics type project. See <
>> http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
>> project called Commons Monitoring which may be similar.
>>
>>
>> Sirona started from commons-monitoring ;)
>>
>>
>>
>> On 28 February 2018 at 10:56, Gilles <[hidden email]>
>> wrote:
>>
>> > On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
>> >
>> >> 2018-02-28 17:11 GMT+01:00 Gilles <[hidden email]>:
>> >>
>> >> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
>> >>>
>> >>> Hi guys,
>> >>>>
>> >>>> On that topic we can keep in mind we retired not a lot time ago
>> Apache
>> >>>> Sirona which was a perf framework industrializing a stopwatch to
>> >>>> summarize
>> >>>> it.
>> >>>> We can make it live again and would probably be a better fir than
>> >>>> commons
>> >>>> cause you quickly need more than just some time measurement when you
>> >>>> start
>> >>>> to work on these topics.
>> >>>>
>> >>>>
>> >>> Why was the project terminated?
>> >>>
>> >>>
>> >> Community didn't grow enough and activity was not that high - the
>> project
>> >> went stable pretty quickly. I forked it on github for now
>> >> https://github.com/rmannibucau/sirona
>> >>
>> >
>> > Does it contain a feature similar to the "StackWatch"
>> > proposed in
>> > https://issues.apache.org/jira/browse/LANG-1373
>> > ?
>> >
>> > If so, do you suggest that Otto's project should depend
>> > on Sirona?
>> >
>> > If not, do you suggest that Otto should submit the PR
>> > to Sirona (and then depend on it)?
>> >
>> >
>> > Gilles
>> >
>> >
>> >>>
>> >>> Just my 2 cts
>> >>>>
>> >>>>
>> >>>> Romain Manni-Bucau
>> >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> >>>> <https://rmannibucau.metawerx.net/> | Old Blog
>> >>>> <http://rmannibucau.wordpress.com> | Github
>> >>>> <https://github.com/rmannibucau> |
>> >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> >>>>
>> >>>> <https://www.packtpub.com/application-development/java-ee-8-
>> >>>> high-performance>
>> >>>>
>> >>>>
>> >>>> 2018-02-28 16:56 GMT+01:00 Gary Gregory <[hidden email]>:
>> >>>>
>> >>>> On Wed, Feb 28, 2018 at 6:35 AM, Gilles <
>> [hidden email]>
>> >>>>
>> >>>>> wrote:
>> >>>>>
>> >>>>> > Hello.
>> >>>>> >
>> >>>>> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>> >>>>> >
>> >>>>> >> Hi,
>> >>>>> >>
>> >>>>> >> In the course of working through my pull request for adding new
>> LANG
>> >>>>> >> functionality on top of the StopWatch class, the issue has been
>> >>>>> raise
>> >>>>> as
>> >>>>> >> to
>> >>>>> >> if this functionality is ‘common’ or should
>> >>>>> >> be placed in a more specialized commons-xxxx component.
>> >>>>> >>
>> >>>>> >> We would like to take the discussion to the list for this, and
>> see
>> >>>>> what
>> >>>>> >> everyone thinks.
>> >>>>> >>
>> >>>>> >> The StackWatch provides for tracking nested timings backed by
>> >>>>> StopWatch.
>> >>>>> >> You can start the watch, and start and stop multiple timings
>> through
>> >>>>> the
>> >>>>> >> call stack. Each timing is named and tag and has it’s own time.
>> >>>>> >> You can visit all the timings, perhaps using the tags to filter
>> when
>> >>>>> you
>> >>>>> >> are done. Please see the PR/Jira for more details. You should
>> look
>> >>>>> at
>> >>>>> >> both, since the review has been split between the two.
>> >>>>> >>
>> >>>>> >> If not LANG, then where? The commons-testing component has been
>> >>>>> >> mentioned. But this code is not ‘test’ code explicitly. In my use
>> >>>>> case (
>> >>>>> >> I wrote this for the Apache Metron project and thought it might
>> be
>> >>>>> useful
>> >>>>> >> here) it would not be test code, in the sense that it would be
>> used
>> >>>>> in
>> >>>>> >> ‘test’ scope in mvn. Rather it would be deployed in production,
>> in
>> >>>>> a
>> >>>>> >> REPL,
>> >>>>> >> and perhaps in other runtime components.
>> >>>>> >>
>> >>>>> >
>> >>>>> > Part of what makes a good component is that it does not dictate
>> >>>>> > how and where applications should use it.
>> >>>>> > The name "Testing" does not imply that its contents must be used
>> >>>>> > within "test" scope.
>> >>>>> >
>> >>>>> > A utility such as "StackWatch" could be another tool to integrate
>> >>>>> > in a unit test suite (e.g. to generate a more fine-grained timing
>> >>>>> > report than Junit does). Hence the module in which "StackWatch"
>> >>>>> > will belong is to become a dependency of modules that target
>> >>>>> > specific test framework (and that is true whether the former is
>> >>>>> > defined within "Testing" or in another component).
>> >>>>> >
>> >>>>> > I would not want to pull in junit
>> >>>>> >> or other dependencies with any component containing it.
>> >>>>> >>
>> >>>>> >
>> >>>>> > +1
>> >>>>> > Must be ensured by proper granularity of the modular design.
>> >>>>> >
>> >>>>> > If we put it in commons-testing ( which already has sub-modules
>> which
>> >>>>> are
>> >>>>> >> geared towards junit ) it may be confusing, even if the module is
>> >>>>> explicit
>> >>>>> >> about purpose and keeping out junit dependent code ( or other
>> >>>>> testing
>> >>>>> >> code).
>> >>>>> >>
>> >>>>> >
>> >>>>> > Why would it be confusing? The module will stand out on its own
>> >>>>> > (artefact/description/doc/web site) and be more visible than yet
>> >>>>> > another class in the already too large "Commons Lang".
>> >>>>> >
>> >>>>> > Also, besides the StackWatch, what else would go into the new
>> target
>> >>>>> >> component? Would StopWatch move as well for example?
>> >>>>> >>
>> >>>>> >
>> >>>>> > +1
>> >>>>> > But creating a new component for two small classes can reasonably
>> >>>>> > be argued as overkill.
>> >>>>> > FTR: I was asked to collect the sampling utilities within a
>> >>>>> > module of "Commons RNG" even though it could have warranted its
>> >>>>> > own component (being a plain "client" of the core functionality
>> >>>>> > of [RNG]). In the present case, "StackWatch" would belong to
>> >>>>> > "core" utilities of "Testing" that are pulled (along with other
>> >>>>> > dependencies by the more specific modules.
>> >>>>> >
>> >>>>>
>> >>>>> I would ask all of us to step back for a moment and consider the big
>> >>>>> picture.
>> >>>>>
>> >>>>> Specifically, what do you consider the mandate or guidelines for
>> >>>>> Commons
>> >>>>> Lang to be? For me, this is code that should or could have been in
>> the
>> >>>>> JRE
>> >>>>> in java.lang or java.util. Looking ahead to Java 9, Commons Lang
>> should
>> >>>>> likely only depend on java.base (it does today but this should be
>> >>>>> enforced
>> >>>>> with the Maven JDeps Plugin IMO.)
>> >>>>>
>> >>>>> If you look at StringUtils, you can then see how this class has
>> grown
>> >>>>> into
>> >>>>> a giant. You can also then see why other related code like a fancier
>> >>>>> String.replace() could creep in as StrSubstitutor and friends.
>> Should
>> >>>>> variable interpolation have been in the JRE? Debatable, but it would
>> be
>> >>>>> useful on top of Properties and ResourceBundle, one might argue;
>> also
>> >>>>> handy
>> >>>>> for JAXB I would say. Nevertheless, WRT to Commons Lang, we --
>> rightly
>> >>>>> IMO
>> >>>>> -- have deprecated StrSubstitutor in Commons Lang in favor or its
>> new
>> >>>>> home
>> >>>>> in Commons Text, where is has evolved further.
>> >>>>>
>> >>>>> In my view, StopWatch and now StackWatch, do not belong in the JRE
>> or
>> >>>>> Commons Lang. It should sit slightly above that level. Where, is the
>> >>>>> question.
>> >>>>>
>> >>>>> Commons Testing for Stop/StackWatch does not seen quite right to
>> me. I
>> >>>>> could see a new Commons Timing or a more general Commons
>> Measurement;
>> >>>>> with
>> >>>>> a mandate NOT to overlap with Joda-Time and java.time.
>> >>>>>
>> >>>>> Gary
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> > Gilles
>> >>>>> >
>> >>>>> >
>> >>>>> >> https://issues.apache.org/jira/browse/LANG-1373
>> >>>>> >>
>> >>>>> >> <https://issues.apache.org/jira/browse/LANG-1373?page=com.
>> >>>>> >> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
>> >>>>> >> tabpanel&focusedCommentId=16377279#comment-16377279>
>> >>>>> >> https://github.com/apache/commons-lang/pull/311
>> >>>>> >>
>> >>>>> >
>> >>>>> >
>> >>>>>
>> >>>>>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>
>>
>> --
>> Matt Sicker <[hidden email]>
>>
>>
>

[garydgregory]

On Fri, Mar 2, 2018 at 7:31 AM, Otto Fowler <[hidden email]> wrote:

> I don’t understand the options that we are discussing here.  Can we
> clarify?
>
> * create a new component from sirota, bringing it into commons ( resurrect
> commons-monitoring ) and put StackWatch there?
>

Something like that. For my money, I'd like this into a (probably new)
component that is not [lang] since it feels out of scope. StopWatch would
move to this new place (deprecate it in [lang] and copy it.)

Gary

>
> On March 2, 2018 at 08:49:03, Romain Manni-Bucau ([hidden email])
> wrote:
>
> This i right but it started as just a few utilities and interception
> modules, then it grows as any performance related project. We also have
> skywalking which is quite big but can host all that utility part @asf.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-
> ee-8-high-performance>
>
> 2018-03-02 14:45 GMT+01:00 Otto Fowler <[hidden email]>:
>
> > My understanding is that sirona was/is a complete system, as opposed to a
> > collection of utilities.
> > If StackWatch is too big for LANG it seems too small for sirona.  Along
> > with sirona being retired etc.
> >
> >
> >
> > On February 28, 2018 at 15:06:52, Romain Manni-Bucau (
> > [hidden email]) wrote:
> >
> > Le 28 févr. 2018 19:27, "Matt Sicker" <[hidden email]> a écrit :
> >
> > This sounds almost like a sort of Commons Metrics type project. See <
> > http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
> > project called Commons Monitoring which may be similar.
> >
> >
> > Sirona started from commons-monitoring ;)
> >
> >
> >
> > On 28 February 2018 at 10:56, Gilles <[hidden email]>
> wrote:
> >
> > > On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
> > >
> > >> 2018-02-28 17:11 GMT+01:00 Gilles <[hidden email]>:
> > >>
> > >> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
> > >>>
> > >>> Hi guys,
> > >>>>
> > >>>> On that topic we can keep in mind we retired not a lot time ago
> Apache
> > >>>> Sirona which was a perf framework industrializing a stopwatch to
> > >>>> summarize
> > >>>> it.
> > >>>> We can make it live again and would probably be a better fir than
> > >>>> commons
> > >>>> cause you quickly need more than just some time measurement when you
> > >>>> start
> > >>>> to work on these topics.
> > >>>>
> > >>>>
> > >>> Why was the project terminated?
> > >>>
> > >>>
> > >> Community didn't grow enough and activity was not that high - the
> > project
> > >> went stable pretty quickly. I forked it on github for now
> > >> https://github.com/rmannibucau/sirona
> > >>
> > >
> > > Does it contain a feature similar to the "StackWatch"
> > > proposed in
> > > https://issues.apache.org/jira/browse/LANG-1373
> > > ?
> > >
> > > If so, do you suggest that Otto's project should depend
> > > on Sirona?
> > >
> > > If not, do you suggest that Otto should submit the PR
> > > to Sirona (and then depend on it)?
> > >
> > >
> > > Gilles
> > >
> > >
> > >>>
> > >>> Just my 2 cts
> > >>>>
> > >>>>
> > >>>> Romain Manni-Bucau
> > >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > >>>> <https://rmannibucau.metawerx.net/> | Old Blog
> > >>>> <http://rmannibucau.wordpress.com> | Github
> > >>>> <https://github.com/rmannibucau> |
> > >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > >>>>
> > >>>> <https://www.packtpub.com/application-development/java-ee-8-
> > >>>> high-performance>
> > >>>>
> > >>>>
> > >>>> 2018-02-28 16:56 GMT+01:00 Gary Gregory <[hidden email]>:
> > >>>>
> > >>>> On Wed, Feb 28, 2018 at 6:35 AM, Gilles <
> [hidden email]
> > >
> > >>>>
> > >>>>> wrote:
> > >>>>>
> > >>>>> > Hello.
> > >>>>> >
> > >>>>> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
> > >>>>> >
> > >>>>> >> Hi,
> > >>>>> >>
> > >>>>> >> In the course of working through my pull request for adding new
> > LANG
> > >>>>> >> functionality on top of the StopWatch class, the issue has been
> > >>>>> raise
> > >>>>> as
> > >>>>> >> to
> > >>>>> >> if this functionality is ‘common’ or should
> > >>>>> >> be placed in a more specialized commons-xxxx component.
> > >>>>> >>
> > >>>>> >> We would like to take the discussion to the list for this, and
> see
> > >>>>> what
> > >>>>> >> everyone thinks.
> > >>>>> >>
> > >>>>> >> The StackWatch provides for tracking nested timings backed by
> > >>>>> StopWatch.
> > >>>>> >> You can start the watch, and start and stop multiple timings
> > through
> > >>>>> the
> > >>>>> >> call stack. Each timing is named and tag and has it’s own time.
> > >>>>> >> You can visit all the timings, perhaps using the tags to filter
> > when
> > >>>>> you
> > >>>>> >> are done. Please see the PR/Jira for more details. You should
> > look
> > >>>>> at
> > >>>>> >> both, since the review has been split between the two.
> > >>>>> >>
> > >>>>> >> If not LANG, then where? The commons-testing component has been
> > >>>>> >> mentioned. But this code is not ‘test’ code explicitly. In my
> use
> > >>>>> case (
> > >>>>> >> I wrote this for the Apache Metron project and thought it might
> be
> > >>>>> useful
> > >>>>> >> here) it would not be test code, in the sense that it would be
> > used
> > >>>>> in
> > >>>>> >> ‘test’ scope in mvn. Rather it would be deployed in production,
> in
> > >>>>> a
> > >>>>> >> REPL,
> > >>>>> >> and perhaps in other runtime components.
> > >>>>> >>
> > >>>>> >
> > >>>>> > Part of what makes a good component is that it does not dictate
> > >>>>> > how and where applications should use it.
> > >>>>> > The name "Testing" does not imply that its contents must be used
> > >>>>> > within "test" scope.
> > >>>>> >
> > >>>>> > A utility such as "StackWatch" could be another tool to integrate
> > >>>>> > in a unit test suite (e.g. to generate a more fine-grained timing
> > >>>>> > report than Junit does). Hence the module in which "StackWatch"
> > >>>>> > will belong is to become a dependency of modules that target
> > >>>>> > specific test framework (and that is true whether the former is
> > >>>>> > defined within "Testing" or in another component).
> > >>>>> >
> > >>>>> > I would not want to pull in junit
> > >>>>> >> or other dependencies with any component containing it.
> > >>>>> >>
> > >>>>> >
> > >>>>> > +1
> > >>>>> > Must be ensured by proper granularity of the modular design.
> > >>>>> >
> > >>>>> > If we put it in commons-testing ( which already has sub-modules
> > which
> > >>>>> are
> > >>>>> >> geared towards junit ) it may be confusing, even if the module
> is
> > >>>>> explicit
> > >>>>> >> about purpose and keeping out junit dependent code ( or other
> > >>>>> testing
> > >>>>> >> code).
> > >>>>> >>
> > >>>>> >
> > >>>>> > Why would it be confusing? The module will stand out on its own
> > >>>>> > (artefact/description/doc/web site) and be more visible than yet
> > >>>>> > another class in the already too large "Commons Lang".
> > >>>>> >
> > >>>>> > Also, besides the StackWatch, what else would go into the new
> > target
> > >>>>> >> component? Would StopWatch move as well for example?
> > >>>>> >>
> > >>>>> >
> > >>>>> > +1
> > >>>>> > But creating a new component for two small classes can reasonably
> > >>>>> > be argued as overkill.
> > >>>>> > FTR: I was asked to collect the sampling utilities within a
> > >>>>> > module of "Commons RNG" even though it could have warranted its
> > >>>>> > own component (being a plain "client" of the core functionality
> > >>>>> > of [RNG]). In the present case, "StackWatch" would belong to
> > >>>>> > "core" utilities of "Testing" that are pulled (along with other
> > >>>>> > dependencies by the more specific modules.
> > >>>>> >
> > >>>>>
> > >>>>> I would ask all of us to step back for a moment and consider the
> big
> > >>>>> picture.
> > >>>>>
> > >>>>> Specifically, what do you consider the mandate or guidelines for
> > >>>>> Commons
> > >>>>> Lang to be? For me, this is code that should or could have been in
> > the
> > >>>>> JRE
> > >>>>> in java.lang or java.util. Looking ahead to Java 9, Commons Lang
> > should
> > >>>>> likely only depend on java.base (it does today but this should be
> > >>>>> enforced
> > >>>>> with the Maven JDeps Plugin IMO.)
> > >>>>>
> > >>>>> If you look at StringUtils, you can then see how this class has
> grown
> > >>>>> into
> > >>>>> a giant. You can also then see why other related code like a
> fancier
> > >>>>> String.replace() could creep in as StrSubstitutor and friends.
> Should
> > >>>>> variable interpolation have been in the JRE? Debatable, but it
> would
> > be
> > >>>>> useful on top of Properties and ResourceBundle, one might argue;
> also
> > >>>>> handy
> > >>>>> for JAXB I would say. Nevertheless, WRT to Commons Lang, we --
> > rightly
> > >>>>> IMO
> > >>>>> -- have deprecated StrSubstitutor in Commons Lang in favor or its
> new
> > >>>>> home
> > >>>>> in Commons Text, where is has evolved further.
> > >>>>>
> > >>>>> In my view, StopWatch and now StackWatch, do not belong in the JRE
> or
> > >>>>> Commons Lang. It should sit slightly above that level. Where, is
> the
> > >>>>> question.
> > >>>>>
> > >>>>> Commons Testing for Stop/StackWatch does not seen quite right to
> me.
> > I
> > >>>>> could see a new Commons Timing or a more general Commons
> Measurement;
> > >>>>> with
> > >>>>> a mandate NOT to overlap with Joda-Time and java.time.
> > >>>>>
> > >>>>> Gary
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> > Gilles
> > >>>>> >
> > >>>>> >
> > >>>>> >> https://issues.apache.org/jira/browse/LANG-1373
> > >>>>> >>
> > >>>>> >> <https://issues.apache.org/jira/browse/LANG-1373?page=com.
> > >>>>> >> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
> > >>>>> >> tabpanel&focusedCommentId=16377279#comment-16377279>
> > >>>>> >> https://github.com/apache/commons-lang/pull/311
> > >>>>> >>
> > >>>>> >
> > >>>>> >
> > >>>>>
> > >>>>>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
> > --
> > Matt Sicker <[hidden email]>
> >
> >
>

[Oliver Heger-3]

Am 02.03.2018 um 15:45 schrieb Gary Gregory:

> On Fri, Mar 2, 2018 at 7:31 AM, Otto Fowler <[hidden email]> wrote:
>
>> I don’t understand the options that we are discussing here.  Can we
>> clarify?
>>
>> * create a new component from sirota, bringing it into commons ( resurrect
>> commons-monitoring ) and put StackWatch there?
>>
>
> Something like that. For my money, I'd like this into a (probably new)
> component that is not [lang] since it feels out of scope. StopWatch would
> move to this new place (deprecate it in [lang] and copy it.)

IMHO StackWatch does not fit very well into [lang] and into the testing
project neither.

One other suggestion: It was stated in the past that the concurrent
classes are also a bit out of scope for [lang], especially the circuit
breaker implementations. Would it make sense to move those into a new
module, and could this be a home for the watch classes, too?

Oliver

>
> Gary
>
>
>>
>> On March 2, 2018 at 08:49:03, Romain Manni-Bucau ([hidden email])
>> wrote:
>>
>> This i right but it started as just a few utilities and interception
>> modules, then it grows as any performance related project. We also have
>> skywalking which is quite big but can host all that utility part @asf.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
>> rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-
>> ee-8-high-performance>
>>
>> 2018-03-02 14:45 GMT+01:00 Otto Fowler <[hidden email]>:
>>
>>> My understanding is that sirona was/is a complete system, as opposed to a
>>> collection of utilities.
>>> If StackWatch is too big for LANG it seems too small for sirona.  Along
>>> with sirona being retired etc.
>>>
>>>
>>>
>>> On February 28, 2018 at 15:06:52, Romain Manni-Bucau (
>>> [hidden email]) wrote:
>>>
>>> Le 28 févr. 2018 19:27, "Matt Sicker" <[hidden email]> a écrit :
>>>
>>> This sounds almost like a sort of Commons Metrics type project. See <
>>> http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
>>> project called Commons Monitoring which may be similar.
>>>
>>>
>>> Sirona started from commons-monitoring ;)
>>>
>>>
>>>
>>> On 28 February 2018 at 10:56, Gilles <[hidden email]>
>> wrote:
>>>
>>>> On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
>>>>
>>>>> 2018-02-28 17:11 GMT+01:00 Gilles <[hidden email]>:
>>>>>
>>>>> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
>>>>>>
>>>>>> Hi guys,
>>>>>>>
>>>>>>> On that topic we can keep in mind we retired not a lot time ago
>> Apache
>>>>>>> Sirona which was a perf framework industrializing a stopwatch to
>>>>>>> summarize
>>>>>>> it.
>>>>>>> We can make it live again and would probably be a better fir than
>>>>>>> commons
>>>>>>> cause you quickly need more than just some time measurement when you
>>>>>>> start
>>>>>>> to work on these topics.
>>>>>>>
>>>>>>>
>>>>>> Why was the project terminated?
>>>>>>
>>>>>>
>>>>> Community didn't grow enough and activity was not that high - the
>>> project
>>>>> went stable pretty quickly. I forked it on github for now
>>>>> https://github.com/rmannibucau/sirona
>>>>>
>>>>
>>>> Does it contain a feature similar to the "StackWatch"
>>>> proposed in
>>>> https://issues.apache.org/jira/browse/LANG-1373
>>>> ?
>>>>
>>>> If so, do you suggest that Otto's project should depend
>>>> on Sirona?
>>>>
>>>> If not, do you suggest that Otto should submit the PR
>>>> to Sirona (and then depend on it)?
>>>>
>>>>
>>>> Gilles
>>>>
>>>>
>>>>>>
>>>>>> Just my 2 cts
>>>>>>>
>>>>>>>
>>>>>>> Romain Manni-Bucau
>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>>> <http://rmannibucau.wordpress.com> | Github
>>>>>>> <https://github.com/rmannibucau> |
>>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>>>
>>>>>>> <https://www.packtpub.com/application-development/java-ee-8-
>>>>>>> high-performance>
>>>>>>>
>>>>>>>
>>>>>>> 2018-02-28 16:56 GMT+01:00 Gary Gregory <[hidden email]>:
>>>>>>>
>>>>>>> On Wed, Feb 28, 2018 at 6:35 AM, Gilles <
>> [hidden email]
>>>>
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hello.
>>>>>>>>>
>>>>>>>>> On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> In the course of working through my pull request for adding new
>>> LANG
>>>>>>>>>> functionality on top of the StopWatch class, the issue has been
>>>>>>>> raise
>>>>>>>> as
>>>>>>>>>> to
>>>>>>>>>> if this functionality is ‘common’ or should
>>>>>>>>>> be placed in a more specialized commons-xxxx component.
>>>>>>>>>>
>>>>>>>>>> We would like to take the discussion to the list for this, and
>> see
>>>>>>>> what
>>>>>>>>>> everyone thinks.
>>>>>>>>>>
>>>>>>>>>> The StackWatch provides for tracking nested timings backed by
>>>>>>>> StopWatch.
>>>>>>>>>> You can start the watch, and start and stop multiple timings
>>> through
>>>>>>>> the
>>>>>>>>>> call stack. Each timing is named and tag and has it’s own time.
>>>>>>>>>> You can visit all the timings, perhaps using the tags to filter
>>> when
>>>>>>>> you
>>>>>>>>>> are done. Please see the PR/Jira for more details. You should
>>> look
>>>>>>>> at
>>>>>>>>>> both, since the review has been split between the two.
>>>>>>>>>>
>>>>>>>>>> If not LANG, then where? The commons-testing component has been
>>>>>>>>>> mentioned. But this code is not ‘test’ code explicitly. In my
>> use
>>>>>>>> case (
>>>>>>>>>> I wrote this for the Apache Metron project and thought it might
>> be
>>>>>>>> useful
>>>>>>>>>> here) it would not be test code, in the sense that it would be
>>> used
>>>>>>>> in
>>>>>>>>>> ‘test’ scope in mvn. Rather it would be deployed in production,
>> in
>>>>>>>> a
>>>>>>>>>> REPL,
>>>>>>>>>> and perhaps in other runtime components.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Part of what makes a good component is that it does not dictate
>>>>>>>>> how and where applications should use it.
>>>>>>>>> The name "Testing" does not imply that its contents must be used
>>>>>>>>> within "test" scope.
>>>>>>>>>
>>>>>>>>> A utility such as "StackWatch" could be another tool to integrate
>>>>>>>>> in a unit test suite (e.g. to generate a more fine-grained timing
>>>>>>>>> report than Junit does). Hence the module in which "StackWatch"
>>>>>>>>> will belong is to become a dependency of modules that target
>>>>>>>>> specific test framework (and that is true whether the former is
>>>>>>>>> defined within "Testing" or in another component).
>>>>>>>>>
>>>>>>>>> I would not want to pull in junit
>>>>>>>>>> or other dependencies with any component containing it.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>> Must be ensured by proper granularity of the modular design.
>>>>>>>>>
>>>>>>>>> If we put it in commons-testing ( which already has sub-modules
>>> which
>>>>>>>> are
>>>>>>>>>> geared towards junit ) it may be confusing, even if the module
>> is
>>>>>>>> explicit
>>>>>>>>>> about purpose and keeping out junit dependent code ( or other
>>>>>>>> testing
>>>>>>>>>> code).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Why would it be confusing? The module will stand out on its own
>>>>>>>>> (artefact/description/doc/web site) and be more visible than yet
>>>>>>>>> another class in the already too large "Commons Lang".
>>>>>>>>>
>>>>>>>>> Also, besides the StackWatch, what else would go into the new
>>> target
>>>>>>>>>> component? Would StopWatch move as well for example?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>> But creating a new component for two small classes can reasonably
>>>>>>>>> be argued as overkill.
>>>>>>>>> FTR: I was asked to collect the sampling utilities within a
>>>>>>>>> module of "Commons RNG" even though it could have warranted its
>>>>>>>>> own component (being a plain "client" of the core functionality
>>>>>>>>> of [RNG]). In the present case, "StackWatch" would belong to
>>>>>>>>> "core" utilities of "Testing" that are pulled (along with other
>>>>>>>>> dependencies by the more specific modules.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I would ask all of us to step back for a moment and consider the
>> big
>>>>>>>> picture.
>>>>>>>>
>>>>>>>> Specifically, what do you consider the mandate or guidelines for
>>>>>>>> Commons
>>>>>>>> Lang to be? For me, this is code that should or could have been in
>>> the
>>>>>>>> JRE
>>>>>>>> in java.lang or java.util. Looking ahead to Java 9, Commons Lang
>>> should
>>>>>>>> likely only depend on java.base (it does today but this should be
>>>>>>>> enforced
>>>>>>>> with the Maven JDeps Plugin IMO.)
>>>>>>>>
>>>>>>>> If you look at StringUtils, you can then see how this class has
>> grown
>>>>>>>> into
>>>>>>>> a giant. You can also then see why other related code like a
>> fancier
>>>>>>>> String.replace() could creep in as StrSubstitutor and friends.
>> Should
>>>>>>>> variable interpolation have been in the JRE? Debatable, but it
>> would
>>> be
>>>>>>>> useful on top of Properties and ResourceBundle, one might argue;
>> also
>>>>>>>> handy
>>>>>>>> for JAXB I would say. Nevertheless, WRT to Commons Lang, we --
>>> rightly
>>>>>>>> IMO
>>>>>>>> -- have deprecated StrSubstitutor in Commons Lang in favor or its
>> new
>>>>>>>> home
>>>>>>>> in Commons Text, where is has evolved further.
>>>>>>>>
>>>>>>>> In my view, StopWatch and now StackWatch, do not belong in the JRE
>> or
>>>>>>>> Commons Lang. It should sit slightly above that level. Where, is
>> the
>>>>>>>> question.
>>>>>>>>
>>>>>>>> Commons Testing for Stop/StackWatch does not seen quite right to
>> me.
>>> I
>>>>>>>> could see a new Commons Timing or a more general Commons
>> Measurement;
>>>>>>>> with
>>>>>>>> a mandate NOT to overlap with Joda-Time and java.time.
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Gilles
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> https://issues.apache.org/jira/browse/LANG-1373
>>>>>>>>>>
>>>>>>>>>> <https://issues.apache.org/jira/browse/LANG-1373?page=com.
>>>>>>>>>> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
>>>>>>>>>> tabpanel&focusedCommentId=16377279#comment-16377279>
>>>>>>>>>> https://github.com/apache/commons-lang/pull/311
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <[hidden email]>
>>>
>>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Bruno P. Kinoshita-2]

We could perhaps move some classes from the concurrent package too I think. Like the circuit breakers. That'd solve our current issue with java.desktop dependency and java9

Sent from Yahoo Mail on Android
 
  On Sat, 3 Mar 2018 at 3:45, Gary Gregory<[hidden email]> wrote:   On Fri, Mar 2, 2018 at 7:31 AM, Otto Fowler <[hidden email]> wrote:

> I don’t understand the options that we are discussing here.  Can we
> clarify?
>
> * create a new component from sirota, bringing it into commons ( resurrect
> commons-monitoring ) and put StackWatch there?
>

Something like that. For my money, I'd like this into a (probably new)
component that is not [lang] since it feels out of scope. StopWatch would
move to this new place (deprecate it in [lang] and copy it.)

Gary

>
> On March 2, 2018 at 08:49:03, Romain Manni-Bucau ([hidden email])
> wrote:
>
> This i right but it started as just a few utilities and interception
> modules, then it grows as any performance related project. We also have
> skywalking which is quite big but can host all that utility part @asf.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-
> ee-8-high-performance>
>
> 2018-03-02 14:45 GMT+01:00 Otto Fowler <[hidden email]>:
>
> > My understanding is that sirona was/is a complete system, as opposed to a
> > collection of utilities.
> > If StackWatch is too big for LANG it seems too small for sirona.  Along
> > with sirona being retired etc.
> >
> >
> >
> > On February 28, 2018 at 15:06:52, Romain Manni-Bucau (
> > [hidden email]) wrote:
> >
> > Le 28 févr. 2018 19:27, "Matt Sicker" <[hidden email]> a écrit :
> >
> > This sounds almost like a sort of Commons Metrics type project. See <
> > http://metrics.dropwizard.io/4.0.0/> for an example. There's a sandbox
> > project called Commons Monitoring which may be similar.
> >
> >
> > Sirona started from commons-monitoring ;)
> >
> >
> >
> > On 28 February 2018 at 10:56, Gilles <[hidden email]>
> wrote:
> >
> > > On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote:
> > >
> > >> 2018-02-28 17:11 GMT+01:00 Gilles <[hidden email]>:
> > >>
> > >> On Wed, 28 Feb 2018 16:59:08 +0100, Romain Manni-Bucau wrote:
> > >>>
> > >>> Hi guys,
> > >>>>
> > >>>> On that topic we can keep in mind we retired not a lot time ago
> Apache
> > >>>> Sirona which was a perf framework industrializing a stopwatch to
> > >>>> summarize
> > >>>> it.
> > >>>> We can make it live again and would probably be a better fir than
> > >>>> commons
> > >>>> cause you quickly need more than just some time measurement when you
> > >>>> start
> > >>>> to work on these topics.
> > >>>>
> > >>>>
> > >>> Why was the project terminated?
> > >>>
> > >>>
> > >> Community didn't grow enough and activity was not that high - the
> > project
> > >> went stable pretty quickly. I forked it on github for now
> > >> https://github.com/rmannibucau/sirona
> > >>
> > >
> > > Does it contain a feature similar to the "StackWatch"
> > > proposed in
> > > https://issues.apache.org/jira/browse/LANG-1373
> > > ?
> > >
> > > If so, do you suggest that Otto's project should depend
> > > on Sirona?
> > >
> > > If not, do you suggest that Otto should submit the PR
> > > to Sirona (and then depend on it)?
> > >
> > >
> > > Gilles
> > >
> > >
> > >>>
> > >>> Just my 2 cts
> > >>>>
> > >>>>
> > >>>> Romain Manni-Bucau
> > >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > >>>> <https://rmannibucau.metawerx.net/> | Old Blog
> > >>>> <http://rmannibucau.wordpress.com> | Github
> > >>>> <https://github.com/rmannibucau> |
> > >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > >>>>
> > >>>> <https://www.packtpub.com/application-development/java-ee-8-
> > >>>> high-performance>
> > >>>>
> > >>>>
> > >>>> 2018-02-28 16:56 GMT+01:00 Gary Gregory <[hidden email]>:
> > >>>>
> > >>>> On Wed, Feb 28, 2018 at 6:35 AM, Gilles <
> [hidden email]
> > >
> > >>>>
> > >>>>> wrote:
> > >>>>>
> > >>>>> > Hello.
> > >>>>> >
> > >>>>> > On Wed, 28 Feb 2018 04:56:36 -0800, Otto Fowler wrote:
> > >>>>> >
> > >>>>> >> Hi,
> > >>>>> >>
> > >>>>> >> In the course of working through my pull request for adding new
> > LANG
> > >>>>> >> functionality on top of the StopWatch class, the issue has been
> > >>>>> raise
> > >>>>> as
> > >>>>> >> to
> > >>>>> >> if this functionality is ‘common’ or should
> > >>>>> >> be placed in a more specialized commons-xxxx component.
> > >>>>> >>
> > >>>>> >> We would like to take the discussion to the list for this, and
> see
> > >>>>> what
> > >>>>> >> everyone thinks.
> > >>>>> >>
> > >>>>> >> The StackWatch provides for tracking nested timings backed by
> > >>>>> StopWatch.
> > >>>>> >> You can start the watch, and start and stop multiple timings
> > through
> > >>>>> the
> > >>>>> >> call stack. Each timing is named and tag and has it’s own time.
> > >>>>> >> You can visit all the timings, perhaps using the tags to filter
> > when
> > >>>>> you
> > >>>>> >> are done. Please see the PR/Jira for more details. You should
> > look
> > >>>>> at
> > >>>>> >> both, since the review has been split between the two.
> > >>>>> >>
> > >>>>> >> If not LANG, then where? The commons-testing component has been
> > >>>>> >> mentioned. But this code is not ‘test’ code explicitly. In my
> use
> > >>>>> case (
> > >>>>> >> I wrote this for the Apache Metron project and thought it might
> be
> > >>>>> useful
> > >>>>> >> here) it would not be test code, in the sense that it would be
> > used
> > >>>>> in
> > >>>>> >> ‘test’ scope in mvn. Rather it would be deployed in production,
> in
> > >>>>> a
> > >>>>> >> REPL,
> > >>>>> >> and perhaps in other runtime components.
> > >>>>> >>
> > >>>>> >
> > >>>>> > Part of what makes a good component is that it does not dictate
> > >>>>> > how and where applications should use it.
> > >>>>> > The name "Testing" does not imply that its contents must be used
> > >>>>> > within "test" scope.
> > >>>>> >
> > >>>>> > A utility such as "StackWatch" could be another tool to integrate
> > >>>>> > in a unit test suite (e.g. to generate a more fine-grained timing
> > >>>>> > report than Junit does). Hence the module in which "StackWatch"
> > >>>>> > will belong is to become a dependency of modules that target
> > >>>>> > specific test framework (and that is true whether the former is
> > >>>>> > defined within "Testing" or in another component).
> > >>>>> >
> > >>>>> > I would not want to pull in junit
> > >>>>> >> or other dependencies with any component containing it.
> > >>>>> >>
> > >>>>> >
> > >>>>> > +1
> > >>>>> > Must be ensured by proper granularity of the modular design.
> > >>>>> >
> > >>>>> > If we put it in commons-testing ( which already has sub-modules
> > which
> > >>>>> are
> > >>>>> >> geared towards junit ) it may be confusing, even if the module
> is
> > >>>>> explicit
> > >>>>> >> about purpose and keeping out junit dependent code ( or other
> > >>>>> testing
> > >>>>> >> code).
> > >>>>> >>
> > >>>>> >
> > >>>>> > Why would it be confusing? The module will stand out on its own
> > >>>>> > (artefact/description/doc/web site) and be more visible than yet
> > >>>>> > another class in the already too large "Commons Lang".
> > >>>>> >
> > >>>>> > Also, besides the StackWatch, what else would go into the new
> > target
> > >>>>> >> component? Would StopWatch move as well for example?
> > >>>>> >>
> > >>>>> >
> > >>>>> > +1
> > >>>>> > But creating a new component for two small classes can reasonably
> > >>>>> > be argued as overkill.
> > >>>>> > FTR: I was asked to collect the sampling utilities within a
> > >>>>> > module of "Commons RNG" even though it could have warranted its
> > >>>>> > own component (being a plain "client" of the core functionality
> > >>>>> > of [RNG]). In the present case, "StackWatch" would belong to
> > >>>>> > "core" utilities of "Testing" that are pulled (along with other
> > >>>>> > dependencies by the more specific modules.
> > >>>>> >
> > >>>>>
> > >>>>> I would ask all of us to step back for a moment and consider the
> big
> > >>>>> picture.
> > >>>>>
> > >>>>> Specifically, what do you consider the mandate or guidelines for
> > >>>>> Commons
> > >>>>> Lang to be? For me, this is code that should or could have been in
> > the
> > >>>>> JRE
> > >>>>> in java.lang or java.util. Looking ahead to Java 9, Commons Lang
> > should
> > >>>>> likely only depend on java.base (it does today but this should be
> > >>>>> enforced
> > >>>>> with the Maven JDeps Plugin IMO.)
> > >>>>>
> > >>>>> If you look at StringUtils, you can then see how this class has
> grown
> > >>>>> into
> > >>>>> a giant. You can also then see why other related code like a
> fancier
> > >>>>> String.replace() could creep in as StrSubstitutor and friends.
> Should
> > >>>>> variable interpolation have been in the JRE? Debatable, but it
> would
> > be
> > >>>>> useful on top of Properties and ResourceBundle, one might argue;
> also
> > >>>>> handy
> > >>>>> for JAXB I would say. Nevertheless, WRT to Commons Lang, we --
> > rightly
> > >>>>> IMO
> > >>>>> -- have deprecated StrSubstitutor in Commons Lang in favor or its
> new
> > >>>>> home
> > >>>>> in Commons Text, where is has evolved further.
> > >>>>>
> > >>>>> In my view, StopWatch and now StackWatch, do not belong in the JRE
> or
> > >>>>> Commons Lang. It should sit slightly above that level. Where, is
> the
> > >>>>> question.
> > >>>>>
> > >>>>> Commons Testing for Stop/StackWatch does not seen quite right to
> me.
> > I
> > >>>>> could see a new Commons Timing or a more general Commons
> Measurement;
> > >>>>> with
> > >>>>> a mandate NOT to overlap with Joda-Time and java.time.
> > >>>>>
> > >>>>> Gary
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> > Gilles
> > >>>>> >
> > >>>>> >
> > >>>>> >> https://issues.apache.org/jira/browse/LANG-1373
> > >>>>> >>
> > >>>>> >> <https://issues.apache.org/jira/browse/LANG-1373?page=com.
> > >>>>> >> atlassian.jira.plugin.system.issuetabpanels%3Acomment-
> > >>>>> >> tabpanel&focusedCommentId=16377279#comment-16377279>
> > >>>>> >> https://github.com/apache/commons-lang/pull/311
> > >>>>> >>
> > >>>>> >
> > >>>>> >
> > >>>>>
> > >>>>>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
> > --
> > Matt Sicker <[hidden email]>
> >
> >
>  

[Matt Sicker]

On 2 March 2018 at 13:31, Oliver Heger <[hidden email]> wrote:
>
> One other suggestion: It was stated in the past that the concurrent
> classes are also a bit out of scope for [lang], especially the circuit
> breaker implementations. Would it make sense to move those into a new
> module, and could this be a home for the watch classes, too?
>

Considering the amount of retry libraries there are out there, I think it
makes perfect sense for circuit breaker libraries to be their own thing,
too. See Hysterix for example.

--
Matt Sicker <[hidden email]>

[Otto Fowler]

So, could think about commons-misc or something?
I don’t think we are going to come up with a perfect module for these
things.

Maybe the way it can work is:

commons-misc exists.

It is the landing place for things that seem to be outside the scope of
commons-xxxx, but don’t justify
a new module or sandbox effort.

Things in misc can be reevaluated for inclusion in new modules at things
go, and at that point @Depricated
out of misc.

?


On March 3, 2018 at 00:42:12, Matt Sicker ([hidden email]) wrote:

On 2 March 2018 at 13:31, Oliver Heger <[hidden email]>
wrote:
>
> One other suggestion: It was stated in the past that the concurrent
> classes are also a bit out of scope for [lang], especially the circuit
> breaker implementations. Would it make sense to move those into a new
> module, and could this be a home for the watch classes, too?
>

Considering the amount of retry libraries there are out there, I think it
makes perfect sense for circuit breaker libraries to be their own thing,
too. See Hysterix for example.

--
Matt Sicker <[hidden email]>

[garydgregory]

-1 to "commons-misc". It feels to me like a copout and unfocused like
SomethingUtils.

We need a proper home. How about the idea of commons-measure. Then there
still the idea of resurrecting other Apache projects. Kind of going in
circles...

Gary

On Mar 8, 2018 08:58, "Otto Fowler" <[hidden email]> wrote:

So, could think about commons-misc or something?
I don’t think we are going to come up with a perfect module for these
things.

Maybe the way it can work is:

commons-misc exists.

It is the landing place for things that seem to be outside the scope of
commons-xxxx, but don’t justify
a new module or sandbox effort.

Things in misc can be reevaluated for inclusion in new modules at things
go, and at that point @Depricated
out of misc.

?



On March 3, 2018 at 00:42:12, Matt Sicker ([hidden email]) wrote:

On 2 March 2018 at 13:31, Oliver Heger <[hidden email]>
wrote:
>
> One other suggestion: It was stated in the past that the concurrent
> classes are also a bit out of scope for [lang], especially the circuit
> breaker implementations. Would it make sense to move those into a new
> module, and could this be a home for the watch classes, too?
>

Considering the amount of retry libraries there are out there, I think it
makes perfect sense for circuit breaker libraries to be their own thing,
too. See Hysterix for example.

--
Matt Sicker <[hidden email]>