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.) 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> > > > > >
