////
   Licensed to the Apache Software Foundation (ASF) under one
   or more contributor license agreements.  See the NOTICE file
   distributed with this work for additional information
   regarding copyright ownership.  The ASF licenses this file
   to you 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

     https://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.
////

*Tag:* configurations *Parent:* link:../ivyfile{outfilesuffix}[ivy-module]

A container for configuration elements. If this container is not present, it is assumed that the module has one public configuration called `default`.

(*__since 2.2__*) You can define the default conf on this container by specifying the `defaultconf` attribute. This attribute defines the conf mapping to use when no conf mapping is specified for a dependency in this Ivy file.

(*__since 1.3__*) You can define a default conf mapping on this container by specifying the `defaultconfmapping` attribute.

This attribute modifies the way Ivy interprets conf mapping with no mapped conf. In this case, Ivy will look in the default conf mapping and use the conf mapping defined in the default conf mapping for the conf for which there is no mapped conf.

In order to maintain backwards compatibility with Ivy 2.1.0 and earlier, the `defaultconfmapping` also provides one additional function. If no `defaultconf` is specified (on either the configurations tag or the dependencies tag), the `defaultconfmapping` becomes the default configuration for dependencies in this Ivy file when no configuration is specified. In other words, in addition to altering the interpretation of individual configurations with no mapping, `defaultconfmapping` also performs exactly like `defaultconf` in the absence of a definition for `defaultconf`.

If several `defaultconfmapping` or `defaultconf` attributes are defined (in the configurations tag, one or several in an included configurations file, and/or in the dependencies tag, then it's only the last definition of each property which is taken into account. The others will have no effect at all.

See link:#defaultconfmapping[examples below] to clarify the behavior of these two attributes together.

(*__since 1.4__*) You can activate a `confmappingoverride` mode for all configurations, in which case the extending configurations will override the mappings of the configurations they extend from.

(*__since 2.5__*) Attributes inherited via link:extends{outfilesuffix}[`extends`] are added to both `configurations` and `dependencies` on link:../use/deliver{outfilesuffix}[delivery]. If the latter element has attributes, their values override values of the corresponding attributes of the former element.

== [[attributes]]Attributes

[options="header",cols="15%,50%,35%"]
|=======
|Attribute|Description|Required
|defaultconf|the default conf to use in this Ivy file (*__since 2.2__*)|No, defaults to no default conf
|defaultconfmapping|the default conf mapping to use in this Ivy file (*__since 1.3__*)|No, defaults to no default conf mapping
|confmappingoverride|`true` to activate configuration mapping override, `false` otherwise (*__since 1.4__*)|No, defaults to `false`
|=======

== Child elements

[options="header",cols="20%,60%,20%"]
|=======
|Element|Description|Cardinality
|link:conf{outfilesuffix}[conf]|declares a configuration of this module|0..n
|link:include{outfilesuffix}[include]|include configurations from another file|0..n
|=======

== Configuration mappings details

When Ivy parses your Ivy file, it will create (internally) modify the configuration mapping of your dependencies.

For instance, say you have:
[source,xml]
----
<configurations defaultconfmapping="conf1->other1;conf2->other2">
   <conf name="conf1"/>
   <conf name="conf2" extends="conf1"/>
</configurations>
<dependencies>
   <dependency name="other-module" conf="conf1"/>
</dependencies>
----

When Ivy parses this file, it will construct the following dependency (in-memory only):
[source,xml]
----
<dependency name="other-module" conf="conf1->other1"/>
----

So, if you now resolve the `conf2` configuration, you will only get the other1 dependencies of your other-module.

But when you set `confmappingoverride` to `true`, Ivy will construct the following dependency in memory:

[source,xml]
----
<dependency name="other-module" conf="conf1->other1;conf2->other2"/>
----

As you can see, the `defaultmappings` of the extending configurations are also added (although you didn't explicitly defined them)

When you now resolve the `conf2` configuration, you'll get the `other2` dependencies of your `other-module`.

== Examples involving defaultconf and [[defaultconfmapping]]defaultconfmapping

The table below indicates how Ivy interprets the conf attribute according to how link:#attributes[defaultconfmapping] and link:#attributes[defaultconf] are set:

[options="header",cols="15%,40%,15%,30%"]
|=======
|defaultconf|defaultconfmapping|conf|Ivy interpretation
| | | |`$$*->*$$`
| | |`runtime`|`$$runtime->runtime$$`
| | |`test`|`$$test->test$$`
|`runtime`| | |`$$runtime->runtime$$`
|`runtime`|`$$runtime->*;test->default$$`| |`$$runtime->*$$`
|`runtime`|`$$runtime->*;test->default$$`|`test`|`$$test->default$$`
| |`$$runtime->*;test->default$$`| |`$$runtime->*;test->default$$`
| |`$$runtime->*;test->default$$`|`runtime`|`$$runtime->*$$`
| |`$$runtime->*;test->default$$`|`test`|`$$test->default$$`
|=======