> ... this weird structure with two test source directories ... doesn't seem okay to me. Please, don't get me wrong. Not that I know of JPMS or anything, though this sttructure doesn't resemble anything I have ever seen. I don't want to believe that every major Java library with JPMS support needs to have such ugly workarounds. Are we sure about this solution? Can we ask for a review from some other Apache fellow? (@Gary, how does Commons deal with this?)
> 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 am really reluctant to make any internal goodie public without a tangible use case and (preferably) user request, given the backward compatibility burden we will need to carry for a decade afterwards. On Sat, Apr 3, 2021 at 12:04 AM Ralph Goers <ralph.go...@dslextreme.com> wrote: > 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 > >> > > >
