Log4j-tools
We currently have logging-log4j-tools which contains the log server code. The log4j server isn’t really a tool so I would propose that the repo either be renamed to logging-log4j-samples or logging-log4j-server. The pros and cons are: logging-log4j-samples: Pros: 1. Other sample code currently in the log4j2 repo could move here. Cons: 1. If we ever want to release log4j-server it would be hard to do from a samples repo. However, we could create the logging-log4j-server repo at that time and then move the code there. logging-log4j-server: Pros: 1. Lets us do whatever we want with the server code. Cons: 1. Doesn’t do anything to allow other sample code to be moved from the log4j2 repo. Another option is to do both. Note - I am also proposing that the changes utility code that Volkan is creating be moved into logging-log4j-tools as it really doesn’t belong in log4j2 itself and can be used by both 2.x and 3.x. If we do this then the utility classes can be independently maintained and released. My preference would be to clone logging-log4j-tools to logging-log4j-server and then delete what is currently in the log4j-tools repo. Thoughts? Ralph
Re: Log4j-tools
Hi Ralph, On Mon, 28 Nov 2022 at 17:31, Ralph Goers wrote: > > We currently have logging-log4j-tools which contains the log server code. The > log4j server isn’t really a tool so I would propose that the repo either be > renamed to logging-log4j-samples or logging-log4j-server. The pros and cons > are: > > logging-log4j-samples: > Pros: > 1. Other sample code currently in the log4j2 repo could move here. > Cons: > 1. If we ever want to release log4j-server it would be hard to do > from a samples repo. However, we could create the logging-log4j-server repo > at that time and then move the code there. +1 I agree we should put in a separate repository all unpublished artifacts. The projects in `log4j-samples` and those in `log4j-spring-cloud-config-samples` cause unnecessary compilation, test and dependency problems. I don't think they need to be compiled at every commit. Besides there are PRs like: https://github.com/apache/logging-log4j2/pull/763 that I don't really want in the main repo, but are fine for a samples repo. Piotr
Re: Log4j-tools
I would prefer logging-log4j-server. Gary On Mon, Nov 28, 2022, 11:31 Ralph Goers wrote: > We currently have logging-log4j-tools which contains the log server code. > The log4j server isn’t really a tool so I would propose that the repo > either be renamed to logging-log4j-samples or logging-log4j-server. The > pros and cons are: > > logging-log4j-samples: > Pros: > 1. Other sample code currently in the log4j2 repo could move here. > Cons: > 1. If we ever want to release log4j-server it would be hard to do > from a samples repo. However, we could create the logging-log4j-server repo > at that time and then move the code there. > > logging-log4j-server: > Pros: > 1. Lets us do whatever we want with the server code. > Cons: > 1. Doesn’t do anything to allow other sample code to be moved from > the log4j2 repo. > > Another option is to do both. > > Note - I am also proposing that the changes utility code that Volkan is > creating be moved into logging-log4j-tools as it really doesn’t belong in > log4j2 itself and can be used by both 2.x and 3.x. If we do this then the > utility classes can be independently maintained and released. > > My preference would be to clone logging-log4j-tools to > logging-log4j-server and then delete what is currently in the log4j-tools > repo. > > Thoughts? > > Ralph
