<!--
  ~ Copyright 2015 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.
  -->
<chapter id='software_model_concepts'>
    <title>Software model concepts</title>
    <note>
        <para>
            Support for the software model is currently <link linkend="feature_lifecycle">incubating</link>. Please be aware that the DSL, APIs and other configuration may change in later Gradle
            versions.
        </para>
    </note>
    <para>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:
    </para>
    <para>
        <itemizedlist>
            <listitem id="component_definition">A <firstterm>component</firstterm> 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.
            </listitem>
            <listitem id="library_definition">A <firstterm>library</firstterm> 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.
            </listitem>
            <listitem id="source_set_definition">A <firstterm>source set</firstterm> 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.
            </listitem>
            <listitem id="binary_definition">A <firstterm>binary</firstterm> 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.
            </listitem>
            <listitem id="variant_definition">A <firstterm>variant</firstterm> 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.
            </listitem>
            <listitem id="api_definition">The <firstterm>API</firstterm> 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.
            </listitem>
        </itemizedlist>
    </para>

</chapter>
