Re: Renaming `log4j-core`
Can we publish log4j-core so it spits out a deprecation warning and just pulls in log4j-impl or log4j-runtime or whatever? That might address Ralph's concern. If we can't avoid the issues Ralph describes, then I'd vote -1 too. On Thu, Jun 22, 2023 at 8:13 AM Ralph Goers wrote: > 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 > 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 > >
Re: Renaming `log4j-core`
The only thing I am aware of is a “relocation” - https://maven.apache.org/guides/mini/guide-relocation.html. This would mean continuing to publish log4j-core and have to reference the new artifact. However, I recall doing that was attempted to redirect log4j 1.x to reload4j and I don’t recall that being very successful. Ralph > On Jun 24, 2023, at 1:00 PM, Tim Perry wrote: > > Can we publish log4j-core so it spits out a deprecation warning and just > pulls in log4j-impl or log4j-runtime or whatever? That might address > Ralph's concern. If we can't avoid the issues Ralph describes, then I'd > vote -1 too. > > On Thu, Jun 22, 2023 at 8:13 AM Ralph Goers > wrote: > >> 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 >> 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 >> >>
Re: Renaming `log4j-core`
Hi Ralph, On Sun, 25 Jun 2023 at 00:23, Ralph Goers wrote: > > The only thing I am aware of is a “relocation” - > https://maven.apache.org/guides/mini/guide-relocation.html. This would mean > continuing to publish log4j-core and have to reference the new artifact. > However, I recall doing that was attempted to redirect log4j 1.x to reload4j > and I don’t recall that being very successful. I think the PMC didn't agree to relocate `log4j:log4j` to an external artifact. Other artifacts like `slf4j-log4j12` have been relocated: https://mvnrepository.com/artifact/org.slf4j/slf4j-log4j12 Piotr
