Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate to SLF4J for logging #1120

Merged
merged 5 commits into from Feb 15, 2022
Merged

Conversation

jamietanna
Copy link
Contributor

Closes #1116.

@jamietanna jamietanna marked this pull request as ready for review February 6, 2022 13:13
Copy link
Member

@nedtwigg nedtwigg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks very much, this LGTM. I'd like one other committer to sign-off on this before I press merge though.

Copy link
Contributor

@lutovich lutovich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me 👍

Just curious, why do we use LoggerFactory.getLogger(Type.class.getName()) instead of LoggerFactory.getLogger(Type.class)?

@@ -127,8 +127,7 @@ private static Provisioner forConfigurationContainer(Project project, Configurat
if (!projName.isEmpty()) {
projName = projName + "/";
}
logger.log(
Level.SEVERE,
logger.error(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps use a {} placeholder here instead of mavenCoords

@nedtwigg
Copy link
Member

nedtwigg commented Feb 14, 2022

@jamietanna can you address the points @lutovich raised above?

@jamietanna
Copy link
Contributor Author

Just curious, why do we use LoggerFactory.getLogger(Type.class.getName()) instead of LoggerFactory.getLogger(Type.class)?

I'd kept this in line with the existing code to do this, as I'd assumed that there was a reason behind it. Looking at the code for java.util.logging.Logger#getLogger, it only takes a String, whereas we can provide a Class<?> with SLF4J.

I'm happy amending it, as it then looks more common for SLF4J, and that can then perform the .getName() call itself?

As noted in diffplug#1116, it'd be ideal if we moved to SLF4J as our logging
interface.

We can do this pretty easily, making sure we remove our `package-list`
reference, as well as making sure the SLF4J API is only used for
compilation.

We also need to map the error logging levels that most closely mirror
what `java.util.logging` uses.

Closes diffplug#1116.
As it removes unnecessary String concatenation at runtime, if the log
levels aren't enabled.
As SLF4J allows passing in a `Class<?>`, instead of a `String` for the
class name, we can simplify interactions with the logger creations.
@nedtwigg
Copy link
Member

If we're adopting log4j, let's do it canonically. Also take a look at "Perhaps use a {} placeholder here instead of mavenCoords". Thanks!

@jamietanna
Copy link
Contributor Author

Done, thanks for the speedy reply!

@nedtwigg
Copy link
Member

Thanks! In the future, please add new commits instead of force-pushing, easier to review :)

@jamietanna
Copy link
Contributor Author

Sorry about that. I would've fixup'd if I'd have known. Will remember in the future 😄

@lutovich
Copy link
Contributor

Looks good. Thanks for addressing my comments!

@nedtwigg nedtwigg merged commit 7331070 into diffplug:main Feb 15, 2022
@nedtwigg
Copy link
Member

Thanks a ton for taking on the SLF4J migration @jamietanna!

@nedtwigg
Copy link
Member

Published in plugin-gradle 6.3.0, not enough new features to justify a maven release yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use SLF4J throughout plugin
3 participants