I don't what would go in this new component though. The tests in the
components I looked at don't have anything to share AFAICT.

Gary

On Sat, Apr 20, 2024, 12:13 PM Gilles Sadowski <gillese...@gmail.com> wrote:

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

Reply via email to