gradle
8.6

# category

abstract fun category(category: String, subcategories: Array<String>): ProblemSpec(source)

A category groups related problems together.

Category is a mandatory property to configure when emitting a problem with ProblemReporter.

A category defines the following hierarchical elements to distinguish instances:

- namespace
- category
- subcategories

The namespace provides separation for identical problems emitted from different components. Problems emitted from Gradle core will use the `org.gradle` namespace. Third party plugins are expected to use their plugin id for namespace. Problems emitted from build scripts should use the `buildscript` namespace. The namespace is bound to ProblemReporter, hence it is absent from the argument list.

A category should contain the most broad term describing the problem. A few examples are: `compilation`, `deprecation`, `task-validation`.

The problem category can be refined with an optional hierarchy of subcategories. For example, a problem covering a java compilation warning can be denoted with the following subcategories: `[java, unused-variable]`.

The categorization depends on the domain and don't have any constraints. Clients (i.e. IDEs) receiving problems should use the category information for properly group and sort the received instances. However, we recommend to use the same conventions as the problems emitted from Gradle core use.

- Entries should be all-lowercase using a dash for separator (i.e. kebab-case)
- Should be strictly hierarchical: the category declares the domain and subcategories provide further refinement

A few examples with a path-like notation (i.e. `category:subcategory1:subcategory2`).

- compilation:groovy-dsl
- compilation:java:unused-import
- deprecation:user-code-direct
- task-selection:no-matches

#### Return

this

#### Parameters

category

the type name

subcategories

the type subcategories