Am 02.03.2018 um 15:45 schrieb Gary Gregory: > On Fri, Mar 2, 2018 at 7:31 AM, Otto Fowler <ottobackwa...@gmail.com> 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 (rmannibu...@gmail.com) >> 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 <ottobackwa...@gmail.com>: >> >>> 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 ( >>> rmannibu...@gmail.com) wrote: >>> >>> Le 28 févr. 2018 19:27, "Matt Sicker" <boa...@gmail.com> 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 <gil...@harfang.homelinux.org> >> wrote: >>> >>>> On Wed, 28 Feb 2018 17:24:29 +0100, Romain Manni-Bucau wrote: >>>> >>>>> 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 >>>>> >>>> >>>> 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 <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 >>>> >>>> >>> >>> >>> -- >>> Matt Sicker <boa...@gmail.com> >>> >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
