// Copyright 2017 the original author or authors.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//      http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

[[software_model_extend]]
= Extending the software model

[CAUTION]
====
Rule based configuration link:https://blog.gradle.org/state-and-future-of-the-gradle-software-model[will be deprecated].
New plugins should not use this concept.
Instead, use the standard approach described in the <<custom_plugins.adoc#custom_plugins, Writing Custom Plugins>> chapter.
====

== Introduction

One of the strengths of Gradle has always been its extensibility, and its adaptability to new domains. The software model takes this extensibility to a new level, enabling the deep modeling of specific domains via richly typed DSLs. The following chapter describes how the model and the corresponding DSLs can be extended to support different domains. Before reading this you should be familiar with the Gradle software model <<software_model.adoc#software_model,rule based configuration>> and <<software_model_concepts.adoc#software_model_concepts,concepts>>.

The following build script is an example of using a custom software model for building Markdown based documentation:

=== Example: an example of using a custom software model

[source.multi-language-sample,groovy]
.build.gradle
----
include::{samplesPath}/customModel/languageType/build.gradle[tag=build-script]
----
NOTE: The code for this example can be found at **`samples/customModel/languageType/`** in the ‘-all’ distribution of Gradle.

The rest of this chapter is dedicated to explaining what is going on behind this build script.


[[sec:concepts]]
== Concepts

A custom software model type has a public type, a base interface and internal views. Multiple such types then collaborate to define a custom software model.


[[sec:public_type_and_base_interfaces]]
=== Public type and base interfaces

Extended types declare a _public type_ that extends a _base interface_:

* Components extend the link:{javadocPath}/org/gradle/platform/base/ComponentSpec.html[ComponentSpec] base interface
* Binaries extend the link:{javadocPath}/org/gradle/platform/base/BinarySpec.html[BinarySpec] base interface
* Source sets extend the link:{javadocPath}/org/gradle/language/base/LanguageSourceSet.html[LanguageSourceSet] base interface

The _public type_ is exposed to build logic.

[[sec:internal_views]]
=== Internal views

Adding internal views to your model type, you can make some data visible to build logic via a public type, while hiding the rest of the data behind the internal view types. This is covered in a <<#software-model-extend-internal-views,dedicated section>> below.

[[sec:components_all_the_way_down]]
=== Components all the way down

Components are composed of other components. A source set is just a special kind of component representing sources. It might be that the sources are provided, or generated. Similarly, some components are composed of different binaries, which are built by tasks. All buildable components are built by tasks. In the software model, you will write rules to generate both binaries from components and tasks from binaries.

[[sec:components]]
== Components

To declare a custom component type one must extend link:{javadocPath}/org/gradle/platform/base/ComponentSpec.html[ComponentSpec], or one of the following, depending on the use case:

* link:{javadocPath}/org/gradle/platform/base/SourceComponentSpec.html[SourceComponentSpec] represents a component which has sources
* link:{javadocPath}/org/gradle/platform/base/VariantComponentSpec.html[VariantComponentSpec] represents a component which generates different binaries based on context (target platforms, build flavors, ...). Such a component generally produces multiple binaries.
* link:{javadocPath}/org/gradle/platform/base/GeneralComponentSpec.html[GeneralComponentSpec] is a convenient base interface for components that are built from sources and variant-aware. This is the typical case for a lot of software components, and therefore it should be in most of the cases the base type to be extended.


The core software model includes more types that can be used as base for extension. For example: link:{javadocPath}/org/gradle/platform/base/LibrarySpec.html[LibrarySpec] and link:{javadocPath}/org/gradle/platform/base/ApplicationSpec.html[ApplicationSpec] can also be extended in this manner. Theses are no-op extensions of `GeneralComponentSpec` used to describe a software model better by distinguishing libraries and applications components. link:{javadocPath}/org/gradle/testing/base/TestSuiteSpec.html[TestSuiteSpec] should be used for all components that describe a test suite.

=== Example: Declare a custom component

[source.multi-language-sample,groovy]
.DocumentationComponent.groovy
----
include::{samplesPath}/customModel/languageType/buildSrc/src/main/groovy/sample/documentation/DocumentationComponent.groovy[tag=component-declaration]
----

Types extending `ComponentSpec` are registered via a rule annotated with link:{javadocPath}/org/gradle/platform/base/ComponentType.html[ComponentType]:

=== Example: Register a custom component

[source.multi-language-sample,groovy]
.DocumentationPlugin.groovy
----
include::{samplesPath}/customModel/languageType/buildSrc/src/main/groovy/sample/documentation/DocumentationPlugin.groovy[tag=component-registration]
----


[[sec:binaries]]
== Binaries

To declare a custom binary type one must extend link:{javadocPath}/org/gradle/platform/base/BinarySpec.html[BinarySpec].

=== Example: Declare a custom binary

[source.multi-language-sample,groovy]
.DocumentationBinary.groovy
----
include::{samplesPath}/customModel/languageType/buildSrc/src/main/groovy/sample/documentation/DocumentationBinary.groovy[tag=binary-declaration]
----

Types extending `BinarySpec` are registered via a rule annotated with link:{javadocPath}/org/gradle/platform/base/ComponentType.html[ComponentType]:

=== Example: Register a custom binary

[source.multi-language-sample,groovy]
.DocumentationPlugin.groovy
----
include::{samplesPath}/customModel/languageType/buildSrc/src/main/groovy/sample/documentation/DocumentationPlugin.groovy[tag=binary-registration]
----


[[sec:source_sets]]
== Source sets

To declare a custom source set type one must extend link:{javadocPath}/org/gradle/language/base/LanguageSourceSet.html[LanguageSourceSet].

=== Example: Declare a custom source set

[source.multi-language-sample,groovy]
.MarkdownSourceSet.groovy
----
include::{samplesPath}/customModel/languageType/buildSrc/src/main/groovy/sample/markdown/MarkdownSourceSet.groovy[tag=markdown-lang-declaration]
----

Types extending `LanguageSourceSet` are registered via a rule annotated with link:{javadocPath}/org/gradle/platform/base/ComponentType.html[ComponentType]:

=== Example: Register a custom source set

[source.multi-language-sample,groovy]
.MarkdownPlugin.groovy
----
include::{samplesPath}/customModel/languageType/buildSrc/src/main/groovy/sample/markdown/MarkdownPlugin.groovy[tag=markdown-lang-registration]
----

Setting the _language name_ is mandatory.

[[sec:putting_it_all_together]]
== Putting it all together


[[sec:generating_binaries_from_components]]
=== Generating binaries from components

Binaries generation from components is done via rules annotated with link:{javadocPath}/org/gradle/platform/base/ComponentBinaries.html[ComponentBinaries]. This rule generates a `DocumentationBinary` named `exploded` for each `DocumentationComponent` and sets its `outputDir` property:

=== Example: Generates documentation binaries

[source.multi-language-sample,groovy]
.DocumentationPlugin.groovy
----
include::{samplesPath}/customModel/languageType/buildSrc/src/main/groovy/sample/documentation/DocumentationPlugin.groovy[tag=binaries-generation]
----


[[sec:generating_tasks_from_binaries]]
=== Generating tasks from binaries

Tasks generation from binaries is done via rules annotated with link:{javadocPath}/org/gradle/platform/base/BinaryTasks.html[BinaryTasks]. This rule generates a `Copy` task for each `TextSourceSet` of each `DocumentationBinary`:

=== Example: Generates tasks for text source sets

[source.multi-language-sample,groovy]
.DocumentationPlugin.groovy
----
include::{samplesPath}/customModel/languageType/buildSrc/src/main/groovy/sample/documentation/DocumentationPlugin.groovy[tag=text-tasks-generation]
----

This rule generates a `MarkdownCompileTask` task for each `MarkdownSourceSet` of each `DocumentationBinary`:

=== Example: Register a custom source set

[source.multi-language-sample,groovy]
.MarkdownPlugin.groovy
----
include::{samplesPath}/customModel/languageType/buildSrc/src/main/groovy/sample/markdown/MarkdownPlugin.groovy[tag=markdown-tasks-generation]
----

See the sample source for more on the `MarkdownCompileTask` task.

[[sec:using_your_custom_model]]
=== Using your custom model

This build script demonstrate usage of the custom model defined in the sections above:

=== Example: an example of using a custom software model

[source.multi-language-sample,groovy]
.build.gradle
----
include::{samplesPath}/customModel/languageType//build.gradle[tag=build-script]
----
NOTE: The code for this example can be found at **`samples/customModel/languageType/`** in the ‘-all’ distribution of Gradle.

And in the components reports for such a build script we can see our model types properly registered:

=== Example: components report

.Output of **`gradle -q components`**
----
> gradle -q components
include::{samplesPath}/customModel/languageType//softwareModelExtend-components.out[]
----


[[software-model-extend-internal-views]]
== About internal views

Internal views can be added to an already registered type or to a new custom type. In other words, using internal views, you can attach extra properties to already registered components, binaries and source sets types like `JvmLibrarySpec`, `JarBinarySpec` or `JavaSourceSet` and to the custom types you write.

Let's start with a simple component public type and its internal view declarations:

=== Example: public type and internal view declaration

[source.multi-language-sample,groovy]
.build.gradle
----
include::{samplesPath}/customModel/internalViews/build.gradle[tag=type-declaration]
----

The type registration is as follows:

=== Example: type registration

[source.multi-language-sample,groovy]
.build.gradle
----
include::{samplesPath}/customModel/internalViews/build.gradle[tag=type-registration]
----

The `internalView(type)` method of the type builder can be called several times. This is how you would add several internal views to a type.

Now, let's mutate both public and internal data using some rule:

=== Example: public and internal data mutation

[source.multi-language-sample,groovy]
.build.gradle
----
include::{samplesPath}/customModel/internalViews/build.gradle[tag=internal-view-mutation]
----

Our `internalData` property should not be exposed to build logic. Let's check this using the `model` task on the following build file:

=== Example: Build script and model report output

[source.multi-language-sample,groovy]
.build.gradle
----
include::{samplesPath}/customModel/internalViews/build.gradle[tag=build-script]
----

.Output of `gradle -q model`
----
> gradle -q model
include::{samplesPath}/customModel/internalViews/softwareModelExtend-iv-model.out[]
----

We can see in this report that `publicData` is present and that `internalData` is not.
