logging-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject [log4j] The shape of Log4j
Date Sun, 21 Jan 2018 15:55:01 GMT
Hi All,

I am writing this to in an effort to understand how we can manage and grow
Log4j. I use the term 'grow' not in the 'bigger is better' sense but more
in the maturing sense.

I am prompted to write this by Ralph's comment that log4j-core and the main
repo is too big and that releases take too long make, partially prompted by
my addition of a new module called log4j-jdbc-dbcp2 which currently
contains one small class with a dependency on Apache Commons DBCP 2.

I would like to express my gratitude at Ralph's efforts to revitalized
Log4j and performing most release management duties. Thank you Ralph!

I can see two main orthogonal issues:
- The size of the git repo.
- The size of the log4j-core module.

Ralph has proposed that new modules like log4j-jdbc-dbcp2 be moved to
another 'plugin' repo.

I really dislike this idea:
- The plugin repo has never been released. Not that one releases a repo but
you get the point.
- How do you keep things in sync between repos and code when we have no
official 'core' SPI.

For my money, we should keep _everything_ in one repo. Good enough for
Google, so good enough for me. What we release out of that repo is a
different story and what I would like to discuss next.

This is not the same as Maven plugins IMO but the case could be made for it
I suppose where a lot/most plugins live in their own repos. It is not the
same as with Maven IMO because our plugins rely on log4j-core and it's
guts, for which we only make loose compatibility guarantees -- as opposed
to log4j-core where we are strict(er). Maven OTOH, has a API for plugin

For example, log4j-jdbc-dbcp2 replies on the guts of log4j-core and we have
no 'official' core SPI, so splitting it off into a separate repo would
greatly increase the risk of it falling out of sync. It is just so much
more easier to maintain when it is all in one repo.

My proposal is to:

- Put everything back into one repo (Chainsaw too?)
- Define a core SPI for plugin writers where we make some statement about
BC, more than the casual 'we try not break stuff.'
- Defining what Log4j project 'components' we have and release based on
that. For example, today, all of the main Log4j repo is one component with
many modules. Chainsaw would be another component of the Log4j project.
Maybe we need to redefine components: API, File, JDBC and so on. A
component can have one of more module
- Got for there.

Thoughts? Help me flush this out?

Thank you for reading!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message