Perhaps we can keep the artifact id but advertise the module as something 
besides “Log4j Core”? When introducing the hypothetical new name for the 
module, we can include a parenthetical “AKA Log4j Core” to clarify.
—
Matt Sicker

> On Jun 22, 2023, at 10:12, 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