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

Make license checks more relaxed #11

Open
radarsh opened this issue Jan 7, 2019 · 6 comments
Open

Make license checks more relaxed #11

radarsh opened this issue Jan 7, 2019 · 6 comments

Comments

@radarsh
Copy link

radarsh commented Jan 7, 2019

Is there anyway to make the license checks a bit more relaxed? For instance, ignore parts of the template based on some condition / expression. We have a large number of source files which were created in 2018 with a header containing the copyright year as follows:

Copyright (c) Example, 2018. All rights reserved.

This is generated using the template

Copyright (c) Example, ${year}. All rights reserved.

Now starting 1/1/2019, all our builds are failing because the year in the file header does not match the current year. So we're left with two unattractive options now:

  1. Disable failing the build by setting ignoreFailures = true but this is a bit brute force and it doesn't fail the build when there are new files without license headers.
  2. Update the year in every single source file which is not ideal and means every file in every project needs to have a new year at the beginning of every year.

My proposal is have a separate DSL for configuring the checks where we can specifically exclude certain variables from it. To start with, maybe something like:

license {
    ext.year = LocalDate.now().year
    sourceSets = [project.sourceSets.main]
    
+    checks {
+        ignoreVariables = ['year']
+    }
}

Appreciate the time and effort you have put into this plugin.

@stephan-gh stephan-gh added this to the 1.0.0 milestone Jan 7, 2019
@stephan-gh
Copy link
Member

So essentially you want the ${year} variable to represent the year the file was created in?

What would happen if you make other changes to the license template? Would it then update all license headers to the current year?

@radarsh
Copy link
Author

radarsh commented Jan 7, 2019

So essentially you want the ${year} variable to represent the year the file was created in?

Correct. If I create a new file today, I want it to get today's year. However, I don't want to touch any other existing files created last year.

What would happen if you make other changes to the license template? Would it then update all license headers to the current year?

Not getting too many ideas at present, but perhaps an option to forcibly update all licenses might do the trick.

@stephan-gh
Copy link
Member

Not getting too many ideas at present, but perhaps an option to forcibly update all licenses might do the trick.

Hmm. After running the update task, all headers should be in a valid state. So I'd rather not skip some headers. However, if we consider other years as valid, then updating would only make changes if you make other changes to the license template (e.g. if you switch to another license). In this case, all years would be reset to the current year.

If that's fine for you, I can imagine adding such a feature. Although I'm not entirely sure what's the best way to exclude a variable from the check. I will think about it for a while.

@radarsh
Copy link
Author

radarsh commented Jan 7, 2019

Yeah that's fine by me 👍

@LexManos
Copy link

Throwing a +1 on this, as it would be quite useful.
If its possible to have the year be either the last time the file was touched in git, the created date, or the current year {in that order} as possible valid headers. It would save us a lot of 'Update year' commits on old branches.

@joschi
Copy link
Contributor

joschi commented Feb 19, 2021

@radarsh While not addressing the exact same problem, do you think #20 could work for you as a workaround?

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

No branches or pull requests

4 participants