-
Notifications
You must be signed in to change notification settings - Fork 456
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
more flexibility in keeping "sloppy" parts of existing license header #1611
Comments
I would read these two resources
To implement what you want, there would still be only one licenseHeader step, but that one step would specify a template which had some kind of regex inside it. Currently, the license header step doesn't read very much in the existing header. It calculates "this is what the header ought to be", and either it exactly matches or it doesn't. It does read some things, such as the copyright header. It does this so that it can preserve the existing copyright year and add new years on top. So it would be possible to add some "softness" into the step, but it would be a new feature. We'd be happy to merge such a feature. I would start by updating the docs for the existing license header step to your dream scenario, and then building to that spec. |
Given #1607, could this be achieved with 2 |
@blacelle Thanks for the tip. that's useful for when any of us look again at these checks. For v4 we're likely leave as-is in the interests of time. |
@blacelle I agree that is possible, but it's such an advanced move I'm a bit worried about how to document it, versus adding something like |
If you are submitting a bug, please include the following:
gradlew spotless[Apply/Check] --stacktrace
If you're just submitting a feature request or question, no need for the above.
Our large codebase has some variations in copyright specifically in terms of spaces between comment chars & the license text
So our
checkstyle
config (not merged, just trying to find a good tool to add this check since we migrated from maven) becomesThat seems good enough, so I'm wondering if I can use spotless instead, as it offers more functionality which we may use in future
Obviously we have have a preferred spacing (for auto fix) but want to tolerate additional spaces
I tried without the comments, but then all files fail the check
Interestingly I also wanted to only report warnings, and note that though multiple errors on a project will now be reported, in a multi module build, the build will terminate as that project build fails (unless --continue is used).
Finally, in the example above I'd need two license header steps, but this seems to not be allowed?
The text was updated successfully, but these errors were encountered: