2018-03-02 15:31 GMT+01:00 Otto Fowler <ottobackwa...@gmail.com>: > 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 (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> >> >> >
