[External] : Re: Are modifiers `static` and `transitive` incompatible?

[Alex Buckley]

On 2/7/2024 1:56 PM, Piotr P. Karwasz wrote:
> The POM of `log4j-core` has its dependencies properly declared: they
> are either in the `provided` scope or in the `compile` scope with the
> `optional` flag. These artifacts are required during the compilation
> `log4j-core`, but their presence at runtime is optional.

Got it.

> The scope problem appears, when another project (let's say `foo`) uses
> `log4j-core`. Since `log4j-core` is just an implementation of
> `log4j-api` and provides a ServiceLoader service that `log4j-api`
> consumes, 99% of the users could just declare `log4j-core` as
> runtime-only dependency of `foo`. This IMHO the correct usage and
> doesn't require any `requires` directives in the module descriptor of
> `foo`.

Got it. I suppose the log4j-core module descriptor says:

- `requires log4j-api` (to gain access to a service interface exported 
by the API module), and
- `provides <<the service interface>> with <<some log4j-core class>`

> Unfortunately the common practice is to add `log4j-core` in the
> default (compile) Maven scope of `foo`. Even Spring Boot Starter does
> it. If `foo` also declares `requires org.apache.logging.log4j.core;`
> in its module descriptor, users start having compilation errors,
> because Maven does not add the optional dependencies of `log4j-core`
> to the compiler module-path.

And the log4j-core module descriptor also says:

- `requires static transitive <<some other module>>`

(I have a feeling that <<some other module>> is log4j-api, which is 
improper since provider classes in log4j-core say `implements <<an 
interface exported from log4j-api>>`-- not an "optional dependency" at 
all. But I'm going to proceed without committing to the identity of 
<<some other module>>.)

Building the module foo ends up triggering resolution of the module 
org.apache.logging.log4j.core, and in turn resolution of <<some other 
module>>, but the latter isn't found.

The problem isn't with Maven failing to add log4j-core's run time 
dependencies at compile time, but rather with foo depending on 
log4j-core at all. (Which in turn occurs because log4j-core probably has 
exports of interest to foo, beyond its role as 'service provider for 
log4j-api'.)

> PS: As I stated before, these problems appear in version 2.x of
> `log4j-core` that was retrofitted with JPMS. Version 3.x is designed
> with JPMS in mind, so only annotation dependencies are `static`.

Thumbs up to using `requires static` only for annotations.

Alex