I disagree with putting these into `logging-log4j-tools` with the current state of the project: It is intended for *internal* usage. For `log4j-changelog`, I want to make it explicit that it is not intended for usage outside Log4j itself. I have two proposals:
1. Create a new `logging-log4j-infra` (groupId: `o.a.l.l.infra`) repository and move the `log4j-changelog` module there and put Piotr's stuff into `logging-log4j-tools` (groupId: `o.a.l.l.tools`) 2. Move everybody to their own repo: `logging-log4j-changelog`, `logging-log4j-instrument`, `logging-log4j-errorprone`, etc. This might turn out to be a better approach given aforementioned projects will most probably have totally different development cycles. What do you think? Regarding code rewrites, i.e., `log4j-errorprone`, Spring Boot 3 has introduced Spring Boot Migrator <https://github.com/spring-projects-experimental/spring-boot-migrator>, which uses OpenRewrite <https://docs.openrewrite.org/> under the hood. Judging from my personal experience, code rewrite functionality in Error Prone never got mass adoption and Spring is really influential in the Java domain. I expect OpenRewrite to get quite some steam in the near future. On Tue, Jan 3, 2023 at 1:50 AM Ralph Goers <ralph.go...@dslextreme.com> wrote: > I think putting it in the tools repo would be fine. > > Ralph > > > On Jan 2, 2023, at 2:34 PM, Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > > > Hi, > > > >> On Mon, 2 Jan 2023 at 10:08, Volkan Yazıcı <vol...@yazi.ci> wrote: > >> Agreed with the separate repository idea. I suggest moving it to the > >> `logging-log4j-maven-plugins` repository – you need an INFRA ticket to > >> create the repository. > > > > The Maven plugin will not be the only use-case of the code after I > > finish up the project. > > > > Since I am really bad at naming things, so maybe I'll describe the > > feature-set and someone will come with the ideal name. :-D > > > > I imagine one module that will weave bytecode (`log4j-instrument`) to: > > * convert classical Log4j2 API calls to LogBuilder calls with location, > > * convert other API calls (Log4j 1.2, JCL, SLF4J and especially > > `java.util.logging`) to Log4j2 API calls (LogBuilder with location for > > now), > > * implement `java.lang.instrument.ClassFileTransformer` so that we > > can use it to weave at runtime. > > > > A second module would be based on a refactoring library (Error Prone? > > called `log4j-errorprone`?) to: > > * convert classical Log4j2 API calls to LogBuilder (this simplifies > > weaving a lot), > > * convert other API calls to Log4j2 API, > > * check for common mistakes of new Log4j2 API adopters: e.g. `if > > (logger.isDebugEnabled() logger.debug(...);` or `logger.debug("Hello > > name " + name + ".")`. > > > > A Maven module would use `log4j-instrument` to: > > * weave a project's classes, > > * weave all JAR dependencies (well, with some default exclusion > > patterns such as `log4j-*.jar` of course), > > * create a POM that only references Log4j2 API. > > > > And of course Maven is not the only build tool on the market. > > Contributors could submit plugins for other build tools. > > > > I think that `logging-log4j-tools` would be a nice name for a > > repository, but it is taken. :-) Unless `log4j-changelog` is targeted > > at a larger audience, in which case we can share. :-) > > > > Piotr > >
