Ignore items from .gitignore

[anton-johansson]

Would it be possible to automatically exclude files that are found in .gitignore (maybe SVN ignore too, but that's probably a bit harder, since it's an SVN property)?

I get this currently when building my project:

[INFO] --- license-maven-plugin:3.0:check (default) @ my-project ---
[INFO] Checking licenses...
[WARNING] Unknown file extension: /home/anton/projects/my-project/.checkstyle
[WARNING] Unable to find a comment style definition for some files. You may want to add a custom mapping for the relevant file extensions.

Sure, I can manually exclude the .checkstyle file, however, it would be nice to automatically ignore files that aren't in the Git repository.

[woj-tek]

I just came here with the same problem - a lot of times this leads to duplication of .gitignore in plugin configuration.

[bjakke]

For that kind of workflow, it might be even better (to have a feature) to just only include git tracked files (e.g. https://stackoverflow.com/questions/15606955/how-can-i-make-git-show-a-list-of-the-files-that-are-being-tracked).

Note that there are also workflows in which you need to apply the plugin to files specifically ignored by .gitignore, for example to set a header for files in target/generated-sources (my usecase, a commercial lib with large parts being code-generated and that also has a source-edition, which needs the headers). Note however that I already use <useDefaultExcludes>false</useDefaultExcludes>.

P.S. This plugin is very nice! Makes my life a lot easier.

[mathieucarbou]

I guys, Not that I am against the idea (I like GIT also), but the feature requested is rally git-dependant. SVN also has some exclusion mechanism and some other versioning system too. This is a maven plugin, so it is agnostic currently to the versioning system used related to its configuration. But I am willing to merge if someone creates a PR and solve it through an elegant way that could also be extended to work with other SCM.

[woj-tek]

I think the suggestion, if implemented, is to use generic solution - gitignore was provided as the most popular example. AFAIK from cursory look at the code there are already parts that handle git and svn specific things.

[mathieucarbou]

@woj-tek : yes right but they are extensions used to provided properties for the header templates. They are not meant to modify the scanning behaviour.

The problem with looking at SCM ignore list is that there are several ways to set patterns for each SCM. In example in git you can ignore through the .gitignore file, but also through the global ~/.gitignore_global, and also locally for a specific repo at .git/info/exclude.

Going through another way and asking for each folder for the list of ignored files using some SCM tool (aka git check-ignore would slow-down considerably the check for large repositories), or be impossible if you have large number of folders.

So as I said, this is not impossible, but would be a big change in the plugin code since we would need to implement some sort of scanning extensions (a little like the properties extensions) that can be queried for each visited file by the plugin, and also make sure to support correctly the different kind of exclusions capabilities for each SCM.

[McFoggy]

@mathieucarbou if we wanted we could also purelly delegate to git the knowledge of files to parse.

• git ls-files : for files already part of index
• git ls-files -o --exclude-standard : for new files not yet in index
• git ls-files --other --ignored --exclude-standard : all files matching some git ignore

For sure it would be faster than trying to do by hand.

[mathieucarbou]

For git, using jgit and a TreeWalk with a specific filter (example: NotIgnoredFilter, or its opposite) might work.

We just need to wire things properly in the plugin and set some rules if the user provides its own include/exclude filters on top of that.

Reminder:

1. default exclusions: can be on or off
2. include pattern: defaulted to ** if not set, and if set, any included pattern would "override" the default exclusions
3. exclude pattern: final check to decide whether to include or exclude

So if we have a "use git ignored patterns flag" that we activate, we could build a list of the ignored files (equivalent of git ls-files --other --ignored --exclude-standard with a TreeWalk and an IgnoredFilter) and then, use this list to complete the user's exclude filter, by first removing entries explicitly included from the include filter. This would still allow the flag useDefaultExcludes to be set on or off depending on the need.