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