Tag: namespaces
Namespaces are an advanced feature of Ivy which let you use resolvers in which module names and organisations are not consistent between each other.
For instance, if you want to use maven2 repository and ivyrep collectively, you will face some naming issues. For example all apache commons projects are declared to be part of the organisation apache in ivyrep whereas in maven2 ibiblio repository, they are declared to be part of the organisation of the same name of the module.
So if you try to use both maven2 and ivyrep repositories, you will face some issues like:
How do I declare a dependency on commons-lang ?
I have an error while trying to resolve module xxx. It says that it depends on [commons-httpclient commons-httpclient] ant that it isn't available.
...
Ivy has an answer to give to this kind of troubles, and this answer is called namespaces. In short, you can affect a namespace to each dependency resolver in Ivy, and each namespace defines rules to convert names from the system namespace to the defined namespace itself, and vice versa.
This very powerful feature is thoroughly used in the build your own repository tutorial, and this is a good place to have examples of what can be done with namespaces.
| Element | Description | Cardinality |
|---|---|---|
| namespace | defines a new namespace | 0..n |
Tag: namespace
Defines a new namespace. A namespace is identified by a name, which is used to reference the namespace in the resolvers using the namespace.
Namespaces overview is given in the namespaces documentation.
A namespace mainly consists of a list of rules, each rule defining a translation between system namespace and the defined namespace, and vice versa.
There are two main possibilities for using these rules. By default, a namespace iterate through the rules, and when it finds one that translate the given name, it returns the translated name. But the namespace can be configured to do use the list as a translator chain: in this case, all rules are applied in order, the result of the first rule translation being passed to the second, and so on.
| Attribute | Description | Required |
|---|---|---|
| name | the namespace name | Yes |
| chainrules | true to indicate that namespaces rules should be chained, false otherwise | No, defaults to false |
| Element | Description | Cardinality |
|---|---|---|
| rule | defines a new namespace rule | 0..n |
<namespace name="test">
<rule>
<fromsystem>
<src org="systemorg"/>
<dest org="A"/>
</fromsystem>
<tosystem>
<src org="A"/>
<dest org="systemorg"/>
</tosystem>
</rule>
</namespace><namespace name="test">
<rule>
<fromsystem>
<src org="systemorg2" module="system\-(.+)"/>
<dest org="B" module="$m1"/>
</fromsystem>
<tosystem>
<src org="B" module=".+"/>
<dest org="systemorg2" module="system-$m0"/>
</tosystem>
</rule>
</namespace><namespace name="test" chainrules="true">
<rule>
<fromsystem>
<src org="systemorg"/>
<dest org="A"/>
</fromsystem>
<tosystem>
<src org="A"/>
<dest org="systemorg"/>
</tosystem>
</rule>
<rule>
<fromsystem>
<src module="systemmod"/>
<dest module="A"/>
</fromsystem>
<tosystem>
<src module="A"/>
<dest module="systemmod"/>
</tosystem>
</rule>
<rule>
<fromsystem>
<src module="systemmod2"/>
<dest module="B"/>
</fromsystem>
<tosystem>
<src module="B"/>
<dest module="systemmod2"/>
</tosystem>
</rule>
</namespace>Tag: rule
Defines a new namespace rule. A rule defines a translation between system namespace and the defined namespace, and vice versa.
See namespace doc for details.
| Element | Description | Cardinality |
|---|---|---|
| fromsystem | defines the translation to apply from system namespace to the defined namespace | 1 |
| tosystem | defines the translation to apply from the defined namespace to system namespace | 1 |
Tag: fromsystem / tosystem
Defines a one way translation rule, i.e. a translation from system namespace to the defined namespace or vice versa.
| Element | Description | Cardinality |
|---|---|---|
| src | defines a source name which can be accepted | 1..n |
| dest | defines the translation to apply when a name is accepted by an src pattern | 1 |
Tag: src
Defines the acceptation part of a translation rule. If a name matches this src, it will be translated using the dest part.
| Attribute | Description | Required |
|---|---|---|
| org | the organisation to match as a regexp | No, defaults to .* |
| module | the module name to match as a regexp | No, defaults to .* |
| rev | the revision to match as a regexp | No, defaults to .* |
Tag: dest
Defines the translation part of a translation rule. If a name has matched a corresponding src, it will be translated using this dest part.
The new names can contain references to groups of the matched name, using a slightly modified regexp syntax. Indeed, referenced groups can be part of either the organisation, module or revision part of the original name. So, to reference the groups, you just have to add a letter identifying the part in which the group should be selected: o for organisation, m for module, and r for revision.
For instance, $o0 matches the whole matched organisation, and $m0 the whole matched module name. $o1 matches the first group of the matched organisation.
For details about regexp and groups, see the Pattern class documentation in the jdk.
| Attribute | Description | Required |
|---|---|---|
| org | the new organisation name | No, defaults to $o0 |
| module | the new module name | No, defaults to $m0 |
| rev | the new revision | No, defaults to $r0 |
<fromsystem>
<src org="systemorg2" module="system\-(.+)"/>
<dest org="B" module="$m1"/>
</fromsystem>Matches modules from systemorg2 which have a name beginning with system followed by a minus and anything else, and translate it to organisation B and module the part following system- of the original name.