2018-02-28 17:11 GMT+01:00 Gilles <gil...@harfang.homelinux.org>: > 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 <garydgreg...@gmail.com>: >> >> On Wed, Feb 28, 2018 at 6:35 AM, Gilles <gil...@harfang.homelinux.org> >>> 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: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
