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

Reply via email to