// 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_concepts]]
= Software model concepts

[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.
====

The software model describes how a piece of software is built and how the components of the software relate to each other. The software model is organized around some key concepts:

* A _component_ is a general concept that represents some logical piece of software. Examples of components are a command-line application, a web application or a library. A component is often composed of other components. Most Gradle builds will produce at least one component.
* A _library_ is a reusable component that is linked into or combined into some other component. In the Java ecosystem, a library is often built as a Jar file, and then later bundled into an application of some kind. In the native ecosystem, a library may be built as a shared library or static library, or both.
* A _source set_ represents a logical group of source files. Most components are built from source sets of various languages. Some source sets contain source that is written by hand, and some source sets may contain source that is generated from something else.
* A _binary_ represents some output that is built for a component. A component may produce multiple different output binaries. For example, for a C++ library, both a shared library and a static library binary may be produced. Each binary is initially configured to be built from the component sources, but additional source sets can be added to specific binary variants.
* A _variant_ represents some mutually exclusive binary of a component. A library, for example, might target Java 7 and Java 8, effectively producing two distinct binaries: a Java 7 Jar and a Java 8 Jar. These are different variants of the library.
* The _API_ of a library represents the artifacts and dependencies that are required to compile against that library. The API typically consists of a binary together with a set of dependencies.

The <<software_model_extend.adoc#software_model_extend, software model can be extended>>, enabling deep modeling of specific domains via richly typed DSLs.