Well, log4j-api, log4j-plugins and log4j-core each have unit tests and test classes that are used by other log4j-modules. Because log4j-api and log4j-plugins are JPMS modules the unit tests need to a) either be in a different package or b) have a module-info.java that essentially extends the real module. Because several of the unit tests access package private methods I had to go with option b. But that would mean the test classes that have to be passed downstream needed to be in a different package. So I moved all those classes to their own java-test directory and appended .test to the base package. Then it became a bit tricky to get those compiled and packaged into a test jar without including the unit tests. So you end up with this weird structure with two test source directories.
The test jars need to be installed in order for them to be used by the other log4j modules that follow. I see no reason they cannot be published. They contain some useful stuff that others could use for unit testing if they wanted. I will look into the mvn verify error. It might be related to what Tim reported. mvn install worked for me. I’m not sure why Ubuntu would be different than MacOS. Ralph > On Apr 2, 2021, at 12:50 PM, Volkan Yazıcı <volkan.yaz...@gmail.com> wrote: > > Great work Ralph! > Your change set marks an important milestone in Log4j development. > Thanks so much! > > `./mvnw verify` fails for me while compiling the 2nd module, log4j-api: > `error: module not found: org.osgi.core`. Any ideas? > This said `./mvnw package` succeeds for me, hence all(?) tests pass. > > $ java -version > openjdk version "11.0.10" 2021-01-19 > OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.10+9) > OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.10+9, mixed mode) > > $ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 20.10 > Release: 20.10 > Codename: groovy > > I have a remark/question regarding removed test-jars. If I am not mistaken > test-jars were only used for testing purposes, so these *-test modules you > have introduced. For one, I am happy to see that test-jars were replaced > with normal module artifacts, at least just for these. Test-jars were > difficult to get right, producing cryptic dependency failures, and not an > often-practiced part of the Maven rituals. This said, shall we prevent them > from getting published? That is, do we need to publish them to the Maven > Central, given they are only needed for internal testing? > > On Mon, Mar 29, 2021 at 1:24 AM Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >> I have created https://github.com/apache/logging-log4j2/pull/480 for you >> to review. It has many changes and merge conflicts will be painful to fix >> so please do not commit to master until this PR is merged. >> >> Although I could merge this now I would prefer if you could checkout the >> branch on your local machines, build, and test it. I haven’t tested it with >> anything real yet but all the unit tests - except for the osgi module - >> pass. >> >> If you open this in your IDE you might have some issues with some test >> classes being flagged as having compile issues. This is because of the >> weird extra directory I had to include in log4j-api and log4j-plugins to >> create test jars. >> >> Please provide feedback so I can make any changes and get this merged. >> >> Ralph >>
