Re: Deterministic formatter
Hmm... interesting but I can't help but think that we are making our build more complex by jumping through hoops to fix problems of our own making: We already use spotless in the builds. Now we want to use OpenRewrite but that makes a "mess", so now we want to use _another_ plugin to fix that, that in itself is a mess IMO. My favorite way to deal with formatting and refactoring is to use Eclipse which has a large set of formatting configuration options and clean-ups. Not everyone uses Eclipse, so sharing an Eclipse or any other IDE formatter config might be pointless. I think we need to keep refactorings OUT of builds, formatting is already weird enough. Gary On Wed, Sep 20, 2023 at 1:45 AM Piotr P. Karwasz wrote: > > Hi, > > Right now our Spotless configuration just specifies the lines endings, > forbids tabs and sorts the imports. If we want to apply some > OpenRewrite rule to the codebase (e.g. migrate all string > concatenations to parameterized logging or migrate JUnit4 to Junit5), > we need a deterministic formatter to clean up the mess OpenRewrite > leaves behind. > > On my personal projects I've bee playing with Google Java format[1] > for some time and it basically corresponds to what we already use > except: > > * it has a non-configurable indentation of 2 spaces. > > There is also a Palantir Java format[2], which is as far as I can tell > also non-configurable (which is a feature, not a problem). Both have > maintained Eclipse and IntelliJ plugins. > > On the other hand of the spectrum there is an Eclipse formatter, which > is fully configurable and apparently has an IntelliJ plugin[3]. This > is the one I used at my dayjob, but it lead to months of discussions, > complains about the settings and a list of trick and tips on how to > change the formatting with comments. We also had a minor problem with > import sorting: > > * the formatter does not sort imports, so we used Spotless to do it. > However Spotless and the Eclipse IDE use a different collation, which > generated some conflicts. > > What do you think about enforcing a deterministic formatter on our code? > > Piotr > > [1] https://github.com/google/google-java-format > [2] https://github.com/palantir/palantir-java-format > [3] > https://plugins.jetbrains.com/plugin/6546-adapter-for-eclipse-code-formatter
Re: Retire Chainsaw
I think I was the last person to perform a release of Chainsaw. The release process I followed was the same one used for Log4j2, Log4j Kotlin, etc., as documented in Confluence. The main thing I was unable to do, though, was make binaries besides regular jar files. To publish binaries for Windows and macOS, you typically need to use some code signing mechanism, too, which ASF Security does have some service for, but I don’t know much at all about packaging desktop software (unless your desktop happens to be a server). > On Sep 19, 2023, at 1:45 PM, Volkan Yazıcı wrote: > > Scott, could you (or anybody else) spare time to perform the following > maintenance tasks? > > 1. Update dependencies (e.g., `hsqldb:hsqldb:1.8.0.7` has a CVE) > 2. Revamp the CI (preferably move it to GitHub Actions) > 3. Migrate to GitHub Issues > 4. Document the release process (unless it already exists) > 5. Clean up the code base (e.g., `pom.xml` still refers to SVN) > 6. Clean up the docs > > Otherwise, I agree with Ralph's points and I think it is better we > communicate to our users that the project is not maintained anymore by > means of archiving the repository. We can still keep links, docs, etc. > around. If anybody later on steps up to maintain it and starts landing > digestible, regular PRs, PMC can always decide to re-activate the archived > repository. > > > On Tue, Sep 19, 2023 at 8:27 PM Scott Deboy wrote: > >> Ralph, >> >> I already removed the socket appender vulnerability. I believe that was the >> only one. >> >> Scott >> >> On Tue, Sep 19, 2023, 11:10 AM Ralph Goers >> wrote: >> >>> Scott, >>> >>> Apparently Chainsaw has dependencies that have CVEs reported against them >>> (or so I am told). We haven’t enabled GitHub Issues for Chainsaw AFAIK. >>> Both of these need to be addressed if the project is going to be >> considered >>> active. Are you willing to help with both of these? >>> >>> Ralph >>> On Sep 19, 2023, at 3:25 AM, Scott Deboy >> wrote: Well, it still works well, and real time log analysis and Chainsaw's support for filtering are very powerful for many dev-local use cases. User base I can't speak to, but I agree based on lack of questions it's probably very low to non-existent. I'd prefer we find an option that isn't "nuke it from orbit". Scott On Tue, Sep 19, 2023, 12:00 AM Volkan Yazıcı wrote: > AFAIC, Chainsaw is hardly getting any maintenance. Considering its >>> activity > over the years, I haven't witnessed a user base either. I suppose the >>> trend > in processing logs (i.e., rendering them into JSON and storing them in > Elasticsearch, GCP/AWS log sinks, etc.) is shifted away from > `PatternLayout`-rendered files collected under `/var/logs`. I would >>> like to > retire[1] Chainsaw in a vote thread. Thoughts? > > [1] Retirement translates to archival of the repository and clearing >> up >>> its > mentions in `logging.apache.org`. > >>> >>> >>
Re: Deterministic formatter
We use the Google Java formatter in Spinnaker, and while I know some of my teammates despise the particular code style chosen there, my preference is consistency over anything. A deterministic formatter would be best for avoiding merge conflicts. If we adopt a formatter, as long as it’s IDE-agnostic (like the GJF one is), then I’m alright with it. > On Sep 20, 2023, at 8:29 AM, Gary Gregory wrote: > > Hmm... interesting but I can't help but think that we are making our > build more complex by jumping through hoops to fix problems of our own > making: We already use spotless in the builds. Now we want to use > OpenRewrite but that makes a "mess", so now we want to use _another_ > plugin to fix that, that in itself is a mess IMO. My favorite way to > deal with formatting and refactoring is to use Eclipse which has a > large set of formatting configuration options and clean-ups. Not > everyone uses Eclipse, so sharing an Eclipse or any other IDE > formatter config might be pointless. I think we need to keep > refactorings OUT of builds, formatting is already weird enough. > > Gary > > On Wed, Sep 20, 2023 at 1:45 AM Piotr P. Karwasz > wrote: >> >> Hi, >> >> Right now our Spotless configuration just specifies the lines endings, >> forbids tabs and sorts the imports. If we want to apply some >> OpenRewrite rule to the codebase (e.g. migrate all string >> concatenations to parameterized logging or migrate JUnit4 to Junit5), >> we need a deterministic formatter to clean up the mess OpenRewrite >> leaves behind. >> >> On my personal projects I've bee playing with Google Java format[1] >> for some time and it basically corresponds to what we already use >> except: >> >> * it has a non-configurable indentation of 2 spaces. >> >> There is also a Palantir Java format[2], which is as far as I can tell >> also non-configurable (which is a feature, not a problem). Both have >> maintained Eclipse and IntelliJ plugins. >> >> On the other hand of the spectrum there is an Eclipse formatter, which >> is fully configurable and apparently has an IntelliJ plugin[3]. This >> is the one I used at my dayjob, but it lead to months of discussions, >> complains about the settings and a list of trick and tips on how to >> change the formatting with comments. We also had a minor problem with >> import sorting: >> >> * the formatter does not sort imports, so we used Spotless to do it. >> However Spotless and the Eclipse IDE use a different collation, which >> generated some conflicts. >> >> What do you think about enforcing a deterministic formatter on our code? >> >> Piotr >> >> [1] https://github.com/google/google-java-format >> [2] https://github.com/palantir/palantir-java-format >> [3] >> https://plugins.jetbrains.com/plugin/6546-adapter-for-eclipse-code-formatter
Re: [log4j-kotlin] 1.3.0 release rampdown
I just noticed that it’s already synced to the latest Log4j release. Carry on then. :) > On Sep 18, 2023, at 11:35 AM, Matt Sicker wrote: > > Sounds good to me! Might want to re-sync the Log4j version to the latest > release, though. > >> On Sep 15, 2023, at 8:00 AM, Volkan Yazıcı wrote: >> >> I renovated `log4j-kotlin` quite a bit and I think we are ready for >> the `1.3.0` release. I share the tentative release notes below to give >> you an idea. Are there anything else you want to incorporate into this >> release? >> >> ### Added >> >> * Added an extension property for storing a cached logger (#29) >> * Added facade APIs for manipulating the context map and stack (#30) >> * Added missing `catching` and `throwing` API methods in `KotlinLogger` (#32) >> >> ### Changed >> >> * Updated Log4j dependency to `2.20.0` >> * Bumped `logging-parent` version to `10.0.0` and overhauled the >> entire project infrastructure to take advantage of its goodies (#37) >> * Migrated tests to JUnit 5 >> * Bumped Kotlin and Kotlin Extensions baseline to `1.6.21` and `1.6.4` >> respectively >
Re: Retire Chainsaw
On Tue, Sep 19, 2023, at 20:47, Vladimir Sitnikov wrote: > I truly do not understand why PMC suggests "all or nothing". Either > "chainsaw must be fully maintained" or "it must be nuked right away > from the website". I think this was not proposed. If we archive a project, we'd move it to a dormant section where everything remains available. However, it would be clear that there is no active maintenance. > What is wrong with just adding "ok, this is no longer receiving > attention because..." and keeping the website open for everybody in > case they happen to run into chainsaw? Adding a note on the current status is surely not a bad idea. We can add this note on the chainsaw website right away, maybe also saying: "this repo is in need of maintainers - please help out, i fyou can" Kind regards, Christian > > Vladimir
Re: Retire Chainsaw
On Tue, Sep 19, 2023, at 20:52, Vladimir Sitnikov wrote: >> Scott, could you (or anybody else) spare time to perform the following >> maintenance tasks? > > I don't use chainsaw personally, however, I am afraid I might run into > a project that does, so I would prefer to keep docs afloat. > > Volkan, > Does the deal qualify for log4j 1.x? > I would love to resolve issues like 1..6 for log4j 1.x: adding GitHub > Actions CI, fixing stale pom references, documenting release steps, > and so on. We discussed this back then and agreed not to revive a project for several reasons. However, time has passed. You should make a separate thread on this topic on this list, and we should exchange arguments again if you want to talk about it. I cannot say if something changed in the PMC opinion, but we also have some new people on the board; maybe there are other opinions now. Kind regards, Christian
Re: Retire Chainsaw
Hi we have last commits in 2022, so there was at least a little activity. I would guess we should open "issues" for Chainsaw, and add a note on the website saying "We need help". If we don't see new people stepping up, we can still do something and announce EOL. On Tue, Sep 19, 2023, at 20:45, Volkan Yazıcı wrote: >1. Update dependencies (e.g., `hsqldb:hsqldb:1.8.0.7` has a CVE) >2. Revamp the CI (preferably move it to GitHub Actions) >3. Migrate to GitHub Issues What does this task mean exactly? Copying issues from Jira to Github? Kind regards Christian
Re: Retire Chainsaw
Typically means to enable GitHub Issues, disable Jira (I think), and update any issue tracker links to point to GHI. > On Sep 20, 2023, at 1:12 PM, Christian Grobmeier wrote: > > Hi > > we have last commits in 2022, so there was at least a little activity. > I would guess we should open "issues" for Chainsaw, and add a note on the > website saying "We need help". > If we don't see new people stepping up, we can still do something and > announce EOL. > > > On Tue, Sep 19, 2023, at 20:45, Volkan Yazıcı wrote: >> 1. Update dependencies (e.g., `hsqldb:hsqldb:1.8.0.7` has a CVE) >> 2. Revamp the CI (preferably move it to GitHub Actions) >> 3. Migrate to GitHub Issues > > What does this task mean exactly? Copying issues from Jira to Github? > > Kind regards > Christian
Re: Deterministic formatter
Hi Gary, On Wed, 20 Sept 2023 at 16:23, Gary Gregory wrote: > Hmm... interesting but I can't help but think that we are making our > build more complex by jumping through hoops to fix problems of our own > making: We already use spotless in the builds. Now we want to use > OpenRewrite but that makes a "mess", so now we want to use _another_ > plugin to fix that, that in itself is a mess IMO. My favorite way to > deal with formatting and refactoring is to use Eclipse which has a > large set of formatting configuration options and clean-ups. Not > everyone uses Eclipse, so sharing an Eclipse or any other IDE > formatter config might be pointless. I think we need to keep > refactorings OUT of builds, formatting is already weird enough. Sure, I don't plan to add refactorings into the builds, but if we do use OpenRewrite locally we need a way to fix the formatting problems caused by the refactoring. The current Spotless configuration does not do it. Spotless supports many formatter plugins, the main ones being Eclipse, Google and Palantir formatters. All three are IDE agnostic. I like the idea of using a non-configurable one, since it is a binary choice, but the Eclipse formatter is a great tool with literally hundreds of options. As long as we don't have to discuss every option and the options that bloat the line length (like "align field initializers") are off, I am fine with it. Could you maybe add your formatter's configuration to `logging-parent` so that we can evaluate how it formats code? Piotr PS: I can submit an option to Spotless, so that package `foo` is ordered before class `FooBar` (as the Eclipse IDE does it). Spotless right now only uses `String.compareTo`.
