Tag: configurations Parent: ivy-module
Container for configuration element. If this container is not present, it is assumed that the module has one public configuration called 'default'.
since 1.3 You can define a new default conf mapping on this container by specifying the defaultconfmapping attribute.
A default conf mapping is very similar to the defaultconf which can be set on the dependencies tag, but it has a slightly different behaviour.
The default conf mapping not only defines the conf mapping to use when no conf mapping is specified for a dependency in this ivy file, but it also modify 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.
See examples on the dependency page.
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. This is an advanced feature which should be used only if you understand its implication.
For a discussion about the origin of this feature see this thread.
Attribute | Description | Required |
---|---|---|
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 |
Element | Description | Cardinality |
---|---|---|
conf | declares a configuration of this module | 0..n |
include | include configurations from another file | 0..n |
Tag: conf Parent: configurations
Declares a configuration of this module. As described in the reference page, a configuration is a way to use or construct a module. Some modules may be used in different ways (think about hibernate which can be used inside or outside an application server), and this way may alter the artifacts you need (in the case of hibernate, jta.jar is needed only if it is used outside an application server). Moreover, a module may need some other modules and artifacts only at build time, and some others at runtime. All those differents ways to use or build a module are called in ivy configurations.
The conf element in the configurations section declares one configuration. This declaration gives the name of the configuration declared, its visibility and the other configurations of the module it extends.
Visibility is used to indicate whether or not a configuration can be used from other modules depending on this one. Thus a private configuration is only used for internal purpose (maybe at build time), and other modules cannot declare to depend on it.
A configuration can also extend one or several other ones of the same module. When a configuration extends another one, then all artifacts required in the extended configuration will also be required in the configuration that extends the other one. For instance, if configuration B extends configuration A, and if artifacts art1 and art2 are required in configuration A, then they will be automatically required in configuration B. On the other hand, artifacts required in configuration B are not necessarily required in configuration A.
This notion is very helpful to define configurations which are similar with some differences.
since 1.4 The extends attribute can use the following wildcards:
* | all other configurations |
*(public) | all other public configurations |
*(private) | all other private configurations |
since 1.4 A whole configuration can be declared as non transitive, so that all dependencies resolved in this configuration will be resolved with transitivity disabled. Note that the transitivity is disabled for all the configuration dependencies (including those obtained because this conf extends other ones), and only for this configuration (which means that a conf extending this one with transitivityy enabled will get transitive dependencies even for dependencies being part of the non transitive configuration).
This is very useful to build a compile configuration, for instance, forcing the dependency declaration on each direct dependency, with no risk to forget some because of transitivity.
since 1.4 This tag supports extra attributes.
Attribute | Description | Required |
---|---|---|
name | the name of the declared configuration | Yes |
description | a description for the declared configuration | No |
visibility | the visibility of the declared configuration. 'public' means that this configuration can be used by other modules, while 'private' means that this configuration is used only in the module itself, and is not exposed to other modules |
No, defaults to public |
extends | a comma separated list of configurations of this module that the current configuration extends |
No, defaults to none |
transitive | a boolean to indicate if this conf is transitive or not since 1.4 | No, defaults to true |
deprecated | indicates that this conf has been deprecated by giving the date of the deprecation. It should be given in this format: yyyyMMddHHmmss |
No, by default the conf is not deprecated |
<conf name="core" visibility="private" />
<conf name="compile" extends="core" transitive="false" visibility="private" />
<conf name="runtime" extends="compile" description="everything needed to run this module" />
Declares three configurations, core compile and runtime, with only the runtime one accessible from other modules, and with the compile one being non transitive.
Therefore the core configuration will only be composed of dependencies declared in the core configuration itself, the compile configuration will be composed of all dependencies required in either core or compile configuration, but without transivity (neither for core nor compile dependencies), and runtime will be composed of all dependencies, all transitively, including the dependencies declared only in compile.
Tag: include Parent: configurations
Include configurations specified in another file. since 1.3
The included file should have a configurations tag as root tag, which follow the same specification as the configurations tag of the ivy file.
This means that it can contain conf declarations, other file inclusion, and also a defaultconfmapping.
When delivering an ivy file with such an inclusion, the included configuration file is inlined, i.e. ivy remove the dependency on the external file.
Attribute | Description | Required |
---|---|---|
file | the file to include | Yes |
<ivy-module version="1.0">
<info organisation="myorg"
module="mymodule"
/>
<configurations>
<include file="path/to/included-configurations.xml"/>
<conf name="conf3"/>
</configurations>
<dependencies>
<dependency name="mymodule1" rev="1.0"/>
<dependency name="mymodule2" rev="2.0" conf="conf2,conf3->*"/>
</dependencies>
</ivy-module>
with included-configurations.xml like this:
<configurations defaultconfmapping="*->@">
<conf name="conf1" visibility="public"/>
<conf name="conf2" visibility="private"/>
</configurations>
Defines 3 configurations, conf1, conf2 and conf3. mymodule1 is required in each configuration, with for each the same configuration (conf1 is needed in conf1, conf2 in conf2, and conf3 in conf3) due to the defaultconfmapping defined in the included file.