Validator tuning
Whether or not a validator validates a particular resource depends on the filters that are in place for that validator.
When a validator is first developed, the implementer of
the validator defines a default set of filters. These filters might
be based on:
- file extensions
- folder or file names
- project natures
- project facets
- content types
- Performance: if you have a large workspace, you might reduce the amount of validation.
- Non-standard conventions: if you use a non-standard naming convention (for example stores XML in files with an .acme-xml extension), you could still enable the appropriate validators to run against those files.
Filters are stored in groups. There are two types of groups: Include groups and Exclude groups. You can have as many Include groups as you like. Filters inside of an Include group cause resources to be validated. If any rule matches, then the entire group matches. Inside of a group the filter rules are OR'd together. However, individual Include groups are AND'ed together. You can have one Exclude group. If any of its filter rules match, then the resource is excluded. Exclusion takes precedence over inclusion.
These rules are illustrated with this hypothetical example:

- If the resource is in the disabled folder, it will be excluded because exclusion takes precedence over everything else.
- If the resource does not have the JSP source content type, and it does not have the JSP fragment source content type, and it does not have a file extension of .jsp or .jspf then it is excluded because none of the rules in the first group matched.
- If the project does not have the module core nature then, it is excluded because the single rule in the second group did not match.
- Otherwise, the resource is validated by this particular validator.