-
Notifications
You must be signed in to change notification settings - Fork 465
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
Enable json in maven plugin #1446
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great PR! Needs
- an entry in
plugin-maven/CHANGES.md
- at least one test for Gson and one test Simple
Oh, also run |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great PR, thanks!
@nedtwigg Would it be reasonable to add |
We used to have a lot of
There are some cases where a standard is common enough that most users won't need to change it. e.g. The great underappreciated value of needing to manually specify the target is that it's self-documenting. Someone new joins the project, is confused by what's getting formatted, searches "spotless" in their project. And right there, they can see how to change it. If the target hasn't been set, the default is an invisible mystery. Invisible mysteries are nice, but only when they work, so it's important to only set a default if it's almost definitely right. We got this wrong earlier in Spotless' life. |
Published in |
Following #1445
Please DO NOT FORCE PUSH. Don't worry about messy history, it's easier to do code review if we can tell what happened after the review, and force pushing breaks that.
Please make sure that your PR allows edits from maintainers. Sometimes its faster for us to just fix something than it is to describe how to fix it.
After creating the PR, please add a commit that adds a bullet-point under the
[Unreleased]
section of CHANGES.md, plugin-gradle/CHANGES.md, and plugin-maven/CHANGES.md which includes:If your change only affects a build plugin, and not the lib, then you only need to update the
plugin-foo/CHANGES.md
for that plugin.If your change affects lib in an end-user-visible way (fixing a bug, updating a version) then you need to update
CHANGES.md
for both the lib and all build plugins. Users of a build plugin shouldn't have to refer to lib to see changes that affect them.This makes it easier for the maintainers to quickly release your changes :)