I'm exasperated by our build on the master branch; JPMS feels like the iceberg that will sink Java.
I can build release-2.x nicely with 'mvn clean package' If I do that on master I get: ... [INFO] Reactor Summary for Apache Log4j 2 3.0.0-SNAPSHOT: [INFO] [INFO] Apache Log4j 2 ..................................... SUCCESS [ 1.100 s] [INFO] Apache Log4j API ................................... FAILURE [ 0.965 s] [INFO] Apache Log4j Plugins ............................... SKIPPED .. with NO error. WTF?! GitHub actions build master just fine. What am I missing? I have a toolchain XML fie with Java 8, 11, 15, 16. Gary On Wed, Jun 23, 2021 at 5:16 AM Volkan Yazıcı <volkan.yaz...@gmail.com> wrote: > That is really nice of you to investigate this further Ralph, really much > appreciated! I think your findings are aligned with my earlier proposal, > which in turn will hopefully significantly reduce the JPMS hazard we have > in "master". Please take your time and go ahead with this. I am looking > forward to the outcome. > > For the records, Ralph's post to Maven Developer List is available here: > > https://lists.apache.org/thread.html/r17d7e36616f6779019dea87abaf4823276adf93a2f9af14b70f443f5%40%3Cdev.maven.apache.org%3E > > On Tue, Jun 22, 2021 at 11:54 PM Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > > I have asked on the Maven dev list about the process of building modules > > that contain test jars. It seems the recommended > > approach for test jars in general has changed and it is now recommended > to > > build them in their own project. This means > > log4j-core would only contain the main source and that log4j-core-tests > > would have the test classes as its main source and > > the log4j-core unit tests in src/test/java. > > > > I have my doubts that this will work but I plan on giving this a try when > > I get some time. > > > > Ralph > > >
