Can't we simply create a `log4j-[test-]junit` module containing the tooling
accepted for public consumption and stop deploying the rest of the `*-test`
modules?
On Sat, 12 Nov 2022, 16:51 Gary Gregory wrote:
> FWIW,
>
> I reply on some of the test framework like JUnit rules in work projects, it
FWIW, I think it is fair to say that we don’t have the same compatibility
requirements
for our test artifacts as we do for the stuff used at runtime. That said, we
can easily
say that classes used in multiple places throughout Log4j are less likely to
change in
an incompatible way simply due
The fact that the test fixture stuff has been moved into log4j-core-test
instead of log4j-core:tests makes it easier to support I think.
—
Matt Sicker
> On Nov 12, 2022, at 09:50, Gary Gregory wrote:
>
> FWIW,
>
> I reply on some of the test framework like JUnit rules in work projects, it
> wo
FWIW,
I reply on some of the test framework like JUnit rules in work projects, it
would be lame to have to reinvent the wheel.
Gary
On Sat, Nov 12, 2022, 08:41 Volkan Yazıcı wrote:
> I am concerned that users rely on test modules intended for internal usage.
> I would rather skip all `*-test`
I am concerned that users rely on test modules intended for internal usage.
I would rather skip all `*-test` modules during deployment. I am not
against shiping testing utilities for public consumption. But, AFAIC, these
modules were never intended for that purpose. This might bite us in the
long r
