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>
