I think the idea would be to separate the reusable test code into their own main modules which depend on JUnit and such which are only consumed by test modules. I think this approach could potentially work, but we’d end up with a few more published jars.
On Sat, Jun 19, 2021 at 11:28 Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > > On Jun 19, 2021, at 3:45 AM, Volkan Yazıcı <volkan.yaz...@gmail.com> > wrote: > > > > That README is such a gem Ralph! Thanks for documenting all that > suffering. > > (README says Log4j 2 supports JPMS, shouldn't it rather be Log4j 3?) > > No, I consider it Log4j 2 version 3.0. IOW, the 2 is just part of the > name. I can see > where you might prefer just Log4j 3.0 though. > > > > > There are actually pretty few modules whose test JARs are used by the > > downstream, mostly by log4j-perf. Could it be a viable option to move the > > benchmarks in log4j-perf to their associated modules (under src/perf?) > > and/or convert tests that produce test JARs into separate Maven modules, > > e.g., log4j-core-test, log4j-layout-template-json-test? With my pretty > > limited understanding of JPMS, I have the impression that this might ease > > the build pain to a certain extent. > > I don’t think that is quite true. The test classes included in the test > jars of > log4j-api, log4j-plugins, and log4j-core are all used by the unit tests in > the > other modules. Log4j-perf doesn’t even have any test classes and doesn’t > have any dependencies on test jars. > > Ralph >
