Hi Herve,

On Fri, 1 Sept 2023 at 09:10, Herve Boutemy <hbout...@apache.org> wrote:
>
> it's not "mono vs multi (Git) repo setup" but "monolithic vs 
> component-oriented release"

Thanks for putting the discussion back on track. I think we could look
at what other logging frameworks do.

Ceki's SLF4J/Logback has:
 * one monolithic release for SLF4J + bindings to generation 1 logging
backends; this really bugs me, since some (most?) releases only update
the obsolete bindings,
 * one monolithic release for Logback.

On the other hand James' JBoss Logging/LogManager has a separate
release for each component.

If we decide to split `log4j-api` into its own repo (let's say for
3.x) and have a separate release cycle:

 * we can safely split the two implementations `log4j-to-jul` and
`log4j-to-slf4j` into their own repos/lifecycle,
 * we can safely split all the bridges into their own repos/lifecycle;
remark that `log4j-jpl` should probably have been in its own repo from
the beginning, since it even has a different Java version requirement,
 * `log4j-1.2-api` and `log4j-web` are partially joined at the hip
with `log4j-core`, although their main functionality is independent.
 * all the remaining modules depend on the **internal** API of
`log4j-core`. They could stay in the current repo.

The way I see it, if one of the modules that depend only on the
`log4j-api` needs a fix to work with a newer API, we messed up
something.

The modules that stay with `log4j-core` would still have a coordinated
lifecycle, but we probably still need a separate repo/Maven module to
test that everything works together. E.g. I am not entirely sure that
someone can use `log4j-cassandra` together with `log4j-flume-ng`:
their dependencies have incompatible Guava requirements and I don't
know if our modules don't use Guava transitively.

Piotr

Reply via email to