category
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
category:subcategory1:subcategory2
). - compilation:groovy-dsl
- compilation:java:unused-import
- deprecation:user-code-direct
- task-selection:no-matches
Return
this
Parameters
the type name
the type subcategories