Pretend for a moment that you work for a company that has lots of shared components that don’t always do everything correctly and publish artifacts that declare a dependency on log4j-core (Note: I do). If we change the name of log4j-core to something else then suddenly both an older version of log4j-core and the new artifact are going to be on the class path. The user will absolutely not know this until they start running their application and start to have weird problems. This is exactly why when Commons components change the artifact name they also require the package names to be changed. However, this still would not really help in our case as now both log4j 2.x and log4j 3.x would be present which would undoubtedly create a host of problems.
Without having an easy and foolproof way to deal with that I would have to vote -1 on changing the artifact name. Note that all the examples of projects renaming do not have the same problems Log4j will when both are present on the class path. However, I am in favor of splitting the web site in two between the API and the implementation, possibly even giving some of the optional modules their own web site or at least breaking them more clearly into their own pages. Ralph > On Jun 22, 2023, at 1:34 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi all, > > I think one of the main problems preventing Log4j API from being used > more wildly are naming problems and misinformation on many sites. > > Personally I find the name `log4j-core` for our implementation quite > unfortunate: this is often interpreted as "core Log4j classes", which > suggests that all artifacts including `log4j-api` should be considered > as a unit. > > I would profit from the major version bump to change it to > `log4j-impl` or `log4j-runtime`. > > Similar changes have occurred in other projects. For example JAXB > changed it's implementation from `jaxb-impl`[1] to `jaxb-runtime`[2] > (and also the group id), during the jakartification process. > > The Java EE Mail project used `javax.mail-api` for their API and > `javax.mail` for their implementation. Now they renamed their > implementation to `angus-mail`, which stresses the difference between > API and implementation more (although in this case Angus **is** the > only implementation available). > > So, what do you think about renaming `log4j-core`? > > Piotr > > [1] https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-impl > [2] https://mvnrepository.com/artifact/org.glassfish.jaxb/jaxb-runtime > [3] https://mvnrepository.com/artifact/javax.mail/javax.mail-api > [4] https://mvnrepository.com/artifact/com.sun.mail/javax.mail > [5] https://mvnrepository.com/artifact/org.eclipse.angus/angus-mail
