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

Reply via email to