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 |
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] |
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] > > |
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] > > > > > |
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] |
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] > > |
In reply to this post by garydgregory
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] |
In reply to this post by Romain Manni-Bucau
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] |
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]> |
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 >>>>> >> 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 >>>>> 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 >>>>> 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 >>>>> 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]> |
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 >> 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 >>>>> >> 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 >>>>> 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 >>>>> 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 >>>>> >> 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 >>>>> 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. >>>>> 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]> |
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]> > > |
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]> > > |
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]> >> >> > |
In reply to this post by Otto Fowler
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]> > > > > > |
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] |
In reply to this post by garydgregory
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]> > > > > > |
In reply to this post by Oliver Heger-3
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]> |
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]> |
-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]> |
Free forum by Nabble | Edit this page |