Re: Renaming `log4j-core`

2023-06-25 Thread Matt Sicker
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  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`

2023-06-25 Thread Piotr P. Karwasz
Hi Tim,

On Sat, 24 Jun 2023 at 22:00, 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?

This is probably the best solution.
We could also consider adding other dependencies to `log4j-core` that
were split into separate modules, like `log4j-smtp`.

Piotr