This group of parameters allows you to filter classes and members that will appear in the generated Java API documentation.

You can identify classes and members to be documented both:

- Explicitly -- those that are marked with including tags/annotations
- Implicitly -- those that are not marked with the excluding tags/annotations

## Exclusion of Classes

The inclusion/exclusions of classes is controlled separately, which allows you to exclude specific classes from the documentation, yet to let some their public/protected members be visible still.

The overall effect will be that the generated JavaDoc will look as if the excluded classes themselves did never exist at all, however, everything else is in place and correct.

In that case, the generated Java API documentation will effectively reorganize your actual Java implementation, excluding certain classes and showing some of their member as if they belong to other classes (derived from the excluded ones). In fact, there is nothing wrong with such a reorganization, because the standard Javadoc actually does it too. For instance, when you specify documenting only public classes, the package-local ones will get excluded, but the public members defined in them may show up as part of the documented classes, which inherit them.

### Inheriting methods of excluded classes

As an example, suppose we have the following situation:

- class `C1` extends class `C2`
- class `C2` extends class `C3`
- class `C3` contains a public method `m()` -- which is supposed to be documented

Now, let's assume that the class `C3` must be excluded from the documentation. What will happen with the method `m()`? It will be shown in the documentation as declared in the class `C2`! Then, for the class `C1`, `m()` must appear as inherited from the class `C2` (rather than from the class `C3`, as it actually is in the code).

### Shadowing of equally named fields

The same situation is with fields, which is actually even more complicated, because equally named fields do not overload but shadow each other. For example:

- class `C1` extends class `C2`
- class `C2` implements interface `I`
- class `C2` contains a private field `F`
- interface `I` contains a public field `F` -- which might be documented

Let's assume the interface `I` must be excluded from the documentation. What will happen with the field `I.F`? Actually, nothing! It shouldn't get in the documentation because it is shadowed by `C2.F`, which is private and, therefore, must be invisible.

### Dynamic extension of type variables

For example, we have a class `C1` defined like this:

      class C1 {
        ...
        public void mmm (V param);
      }

and class `C2` that extends `C1`:

      class C2 extends C1 {
        ...
      }

Now, suppose that class `C1` should be excluded from the documentation, but its method `C1.mmm()` should not. Then, showing that method like:

  `C2.mmm (V param)`

would be incorrect because class `C2` has no type variable `'V'` (and even if it had that would be actually a different variable). So, what would be correct then? Actually this:

  `C2.mmm (String param)`

And that's how it will be process and documented by this template set!