Hi Volkan, On Mon, 6 Nov 2023 at 22:02, Volkan Yazıcı <vol...@yazi.ci> wrote: > OTOH, JPMS support in the `main` branch was first established by > hand-written `module-info.java` files and then later on reimplemented (work > in progress!) by Piotr via porting stuff from `2.x`. Nobody has tested it > yet, AFAIK. `jlink` is known to not work there.
As a disclaimer, `jlink` fails on `log4j-core` version 3.0.0-alpha1 as well as 3.0.0-SNAPSHOT. The problems are deps, which are automatic modules (with or without an `Automatic-Module-Name`). In the case of version 3.x, there are three runtime dependencies that are neither used nor declared as optional. This shows once again that integration tests are necessary. > Though `3.x` is good at two things regarding modularization: > > 1. It breaks down `log4j-core` into more fine-grained modules (e.g., > `log4j-csv`) > 2. It has slightly improved package encapsulation. That is, some > internal classes are indeed moved to internal packages. > > `2.x` can never implement #2, since it is a breaking change. Thought #1 can > very well be implemented for `2.x` – users will just need to add a new JAR > to their classpath. Removing any class from an artifact is a **breaking** change, even if we put it in another artifact without changing its name. Besides, most of the "additional" features are not in a package of their own and multiple modules can not share the same package. I agree with Ralph: we don't need to backport everything from `main` to `2.x` by bending the rules. If a single protected/public class or method must disappear, let's do the right thing and don't backport the change. The tools like BND Baseline plugin use the most strict interpretation of breaking change possible. We don't need to follow each alert literally, but if we don't need to break the rules, let's choose the safest path. Piotr
