1) Ivy File
Ivy's use is entirely based on the modular descriptor known as "Ivy file." Ivy files are XML files, often called ivy.xml, that contain a description of the module dependencies, the artifacts it publishes, and its configuration.
Here is one of the simplest Ivy files:
<ivy-module version="2.0">
<info organisation="myorg"
module="mymodule"
/>
</ivy-module>
If you want to know an example of a module descriptor that uses almost all Ivy files, see here, with XSLT and without XSLT.
Before you begin the reference document, you are required to have an understanding of the terminology defined in the main page of this reference document.
For those familiar XML schemas, schemas used to validate Ivy files can be found here. For those Ides that use XSD, you can benefit from automatic code completion and validation by declaring these xsd in your Ivy file.
<?xml version="1.0" encoding="UTF-8"?>
<ivy-module version="2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation=
"http://ant.apache.org/ivy/schemas/ivy.xsd">
<info organisation="myorg"
module="mymodule"
/>
</ivy-module>
2) dynamic or fixed ivy file
The module descriptor (Ivy file) is required before and after each revision of the module is released. In this case, the module descriptor can be dynamic or fixed:
1. Dynamic Descriptor for Module development
In the time of module development, between releases, descriptors help manage the dependencies of all possible changes in the module. In this purpose, ivy files in the development time can affirm dynamic dependencies to allow maximum flexibility of use. Dynamic revisions such as "latest.integration" or "1.0.+" are possible and can be resolved to different artifacts at different times. Variables can be used for more flexibility. Development time Ivy files are called "dynamic" because they can produce different results over time. Dynamic ivy files are typically treated as source files and kept together with them (under SCM control).