This is Tooling Trusted Release issue Incorrect license checks for non-code files #1214 for discussion
https://release-test.apache.org/report/db-jdo/3.3/jdo-3.3-SNAPSHOT-source-release.tar.gz The proposed release fails some checks that should not fail. The source license in 7 java files are correctly failed. These have been fixed. But: There should not be a license check for .gitignore because it contains no Intellectual Property. Similarly, there should not be a license check for jdo-3.3-SNAPSHOT/tck/src/main/resources/meta/META-INF/services/org.junit.platform.launcher.TestExecutionListener because "This is a Java service loader file — it contains only a class name and doesn't need a license header. Service files in META-INF/services/ are not source files and are not expected to carry license headers; the LICENSE and NOTICE files at the project root cover them." sbp response: @clr-apache Thanks for the report. I downloaded the source archives and noticed that they both contain .rat-excludes files. You can add the files that you want to ignore to those files: **/.gitignore **/META-INF/services/* But, then you may be wondering why we don't just ignore these by default. We actually do ignore .gitignore by default, at least, but only when a .rat-excludes file is not present. If such a file is present, it would be impossible to turn off any of our default choices, so projects would not have control over what files they ignore. In other words, the presence of a .rat-excludes file means that we hand control of what is ignored over to the project. If a .rat-excludes file is not present, we use default ignores from RAT's standard ignore collections. We choose a small set of collections, but we defer to the RAT project as to what is in those collections. I was wondering how you normally use RAT. If you run RAT through the Maven plugin, with the plugin defaults, I expect that it will skip **/.gitignore but it won't skip **/META-INF/services/*, because it uses similar collections to ATR. Therefore, through normal Maven plugin use you would have to add the latter to your custom ignores anyway. It might be reasonable to suggest **/META-INF/services/* as a candidate for inclusion in one of their standard ignore collections. Craig L Russell [email protected]
