If you did that then it would require that instead of the Log4j-api module producing the log4j-api jar and log4j-api test jar you would end up with
* log4j-api - with no tests. * log4j-api-test - creates the test jar. * log4j-api-unittest - contains and runs the unit tests. I’d rather live with the single module weirdness than need 3 modules. Ralph > On Jun 19, 2021, at 9:53 AM, Matt Sicker <boa...@gmail.com> wrote: > > 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 >>
