Import order and POM formatting
Hi all, I noticed a difference in the spotless configuration of our repos. The `logging-log4j2` repo uses: java,org,com,\# The `logging-log4j-tools` repo uses: java,javax,org.apache.logging,,\#java,\#javax,\#org.apache.logging,\# I copied the latter to `logging-log4j-transform`, so I don't disagree with it. However I would like a common rule for all repos, so that I can configure my editor accordingly. Should we move Volkan's order to all other repos? I am not sure if `org.apache.logging` imports should be highlighted with their own group (it might be unexpected for contributors), but it looks nice. Another question is POM sorting. In `logging-log4j-transform` I experimented with: false true true scope,artifactId,groupId artifactId,groupId artifactId,groupId This is basically what I tried to do in September, the only difference is that it does not (and can not) sort `org.apache.logging` artifacts before all others. What do you think about introducing the Spotless rule to the main repo? Piotr
Re: Import order and POM formatting
I’m ok with whatever ordering we use. As much as spotless build failures annoy me, I am loving the increased consistency in some of the annoying parts of code style. — Matt Sicker > On Jan 14, 2023, at 03:52, Piotr P. Karwasz wrote: > > Hi all, > > I noticed a difference in the spotless configuration of our repos. > > The `logging-log4j2` repo uses: > > java,org,com,\# > > The `logging-log4j-tools` repo uses: > > java,javax,org.apache.logging,,\#java,\#javax,\#org.apache.logging,\# > > I copied the latter to `logging-log4j-transform`, so I don't disagree > with it. However I would like a common rule for all repos, so that I > can configure my editor accordingly. > > Should we move Volkan's order to all other repos? I am not sure if > `org.apache.logging` imports should be highlighted with their own > group (it might be unexpected for contributors), but it looks nice. > > Another question is POM sorting. In `logging-log4j-transform` I > experimented with: > > >false >true >true >scope,artifactId,groupId >artifactId,groupId >artifactId,groupId > > > This is basically what I tried to do in September, the only difference > is that it does not (and can not) sort `org.apache.logging` artifacts > before all others. What do you think about introducing the Spotless > rule to the main repo? > > Piotr
Re: LOG4J2-3228 - Remove support for Serializable
So I’ve updated the PR to remove the generic parameter from Layout. I’ve also found the remaining classes implementing Serializable and updated them which includes several interesting things like: * Logger (all of them) * Level * Message * MessageFactory * LogEvent * ThreadContextMap * ThreadContextStack * Some random plugins and plugin builder classes that felt like being serializable for some reason * Comparable implementations (used to be suggested that these should be serializable) * The extended stack trace and throwable proxy classes There may be a few others, but that’s the main list. The only code that still references serializable at all is some JMS code that’s explicitly for serializable classes, though that could also potentially be removed. — Matt Sicker > On Jan 11, 2023, at 23:13, Matt Sicker wrote: > > Not really I guess? Layout already extends Encoder, and the only > reasonable return value now is String since byte[] is already covered by > another method, and ByteBuffer is covered by the Encoder interface. That > could further simplify things! > — > Matt Sicker > >> On Jan 11, 2023, at 14:50, Gary Gregory wrote: >> >> Is the generic needed at all? >> >> Gary >> >> On Wed, Jan 11, 2023, 12:19 Matt Sicker wrote: >> >>> I’ve opened https://github.com/apache/logging-log4j2/pull/1199 to handle >>> this issue. The vast majority of the changes are from replacing `Layout>> extends Serializable` with just `Layout`. Please take a look and provide >>> any feedback. >
