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 <tim.v...@gmail.com> 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 <ralph.go...@dslextreme.com>
> 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 <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
>> 
>> 

Reply via email to