Hi.
Le sam. 20 avr. 2024 à 17:50, Gary Gregory <garydgreg...@gmail.com> a écrit :
>
> Hello,
>
> I looked at Commons Lang, Commons IO, Commons CSV, Commons BCEL, Commons
> Crypto, and Commons Text. All of the above do the same duplicate work.
For sure, it's an improvement to make duplicate configurations obsolete.
However, shouldn't we go a step further in harmonizing the repositories'
structure in terms of functionality?
For example, we could have a component ("internal" to Commons" dedicated
to benchmarking boiler-plate code (similar to, or within, the "Testing" project
which you had proposed some time ago).
As noted, IMHO a Maven module dedicated to benchmarking is preferable to
"mixing" with unit tests (e.g. only that module would then depend on the
benchmarking utilities).
Regards,
Gilles
>
> Gary
>
> On Sat, Apr 20, 2024, 11:01 AM Gilles Sadowski <gillese...@gmail.com> wrote:
>
> > Hi.
> >
> > This commit caught my attention but I've not looked in detail (sorry!).
> > I'm wondering whether this addition deserves a discussion here on "dev"
> > to reach consensus on how to handle benchmarking code in a uniform
> > way across all components.
> > For a long time, some components (namely and mainly "Commons
> > RNG") have been providing[1] extensive JMH codes (in dedicated
> > maven modules) in order to generate benchmark reports.
> > This addition seems (?) to duplicate the functionality, under different
> > assumptions on how to trigger it.
> > Did you look at how the benchmarking functionality is laid out in [RNG]?
> > Can't it be generalized to other components, with or without formal
> > support in the "main" POM file? [At first sight, it would seem tidier,
> > more
> > flexible and more maintainable, to *not* bundle benchmark codes within
> > "src/test" (where true unit tests reside)...]
> >
> > Gilles
> >
> > [1] Thanks to Alex.
> >
> > Le sam. 20 avr. 2024 à 16:30, <ggreg...@apache.org> a écrit :
> > >
> > > [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
