-
Notifications
You must be signed in to change notification settings - Fork 460
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
Add maven support for git-based copyright headers #626
Conversation
This is the last PR in this train, I'll cut releases of everything once this gets merged. |
@@ -120,6 +121,9 @@ | |||
@Parameter(property = "spotlessFiles") | |||
private String filePatterns; | |||
|
|||
@Parameter(property = LicenseHeaderStep.spotlessSetLicenseHeaderYearsFromGitHistory) | |||
private String setLicenseHeaderYearsFromGitHistory; |
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.
Can this field/parameter be boolean instead of string?
I think this could simplify type signatures (boolean
instead of Optional<String>
) and the check in LicenseHeader
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.
I think there's a decent chance that we'll allow values besides "true" in the future. For example, you might want to exclude certain commits, say formatting commits, from the git history that you care about, and this is the pipe that we'll put that through.
plugin-maven/src/main/java/com/diffplug/spotless/maven/generic/LicenseHeader.java
Outdated
Show resolved
Hide resolved
Published in maven |
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
-SNAPSHOT
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
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 the 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 :)