- Documentation (2.2.0)
- Release Notes
- Tutorials
- Reference
- Developer doc
Using namespaces
Now that you have seen how simple it is to create your own repository from an existing one, you may wonder how you can handle more complex cases, like when the source and destination repositories don't follow the same naming conventions.
On the road to a professional repository
In this section, you will learn how to build a professional repository. What is a professional repository? Our vision is to say that a good quality repository must follow clear rules about projects naming and must offer correct, useable, configurations and verified project descriptors. In order to achieve those goals, we think that you have to build your own repository.We have seen in the previous example, that we could use some public repositories to begin to build our own repository. Nevertheless, the result is not always the expected one, especially concerning the naming rules used.
This problem is pretty normal when you have an existing repository, and want to benefit from large public repositories which do not follow the same naming conventions. It also shows up because many public repositories do not use a consistent naming scheme. For example, why don't all the apache commons modules use the org.apache.commons organization? Well.. for historical reasons. But if you setup your own repository, you may not want to suffer from the mistakes of history.
Fortunately, Ivy has a very powerful answer to this problem: namespaces.
Using namespaces
If you look at the repository built with the previous tutorial, you will see exactly what we were talking about: all apache commons modules use their own name as their organization.So let's see what Ivy can do using namespaces (we will dig into details later):
[ivy@apache:/ivy/build-a-ivy-repository]$ ant maven2-namespace Buildfile: /ivy/build-a-ivy-repository/build.xml load-ivy: init-ivy: maven2-namespace: [ivy:install] :: Ivy 2.2.0 - 20100923230623 :: http://ant.apache.org/ivy/ :: [ivy:install] :: loading settings :: file = /ivy/build-a-ivy-repository/settings/ivysettings-advanced.xml [ivy:install] DEPRECATED: 'defaultCache' is deprecated, use 'caches[@defaultCacheDir]' instead (file://ivy/build-a-ivy-repository/settings/ivysettings-advanced.xml) [ivy:install] :: installing apache#commons-lang;1.0 :: [ivy:install] :: resolving dependencies :: [ivy:install] found apache#commons-lang;1.0 in libraries [ivy:install] :: downloading artifacts to cache :: [ivy:install] downloading http://repo1.maven.org/maven2/commons-lang/commons-lang/1.0/commons-lang-1.0.jar ... [ivy:install] ....................................................................................................................... (62kB) [ivy:install] .. (0kB) [ivy:install] [SUCCESSFUL ] apache#commons-lang;1.0!commons-lang.jar (3151ms) [ivy:install] downloading http://repo1.maven.org/maven2/commons-lang/commons-lang/1.0/commons-lang-1.0-javadoc.jar ... [ivy:install] ..................................................................................................................................................................................................................................................................................................................................................................... (170kB) [ivy:install] .. (0kB) [ivy:install] [SUCCESSFUL ] apache#commons-lang;1.0!commons-lang.jar(javadoc) (3104ms) [ivy:install] :: installing in my-repository :: [ivy:install] published commons-lang to /ivy/build-a-ivy-repository/myrepository/advanced/apache/commons-lang/jars/commons-lang-1.0.jar [ivy:install] published commons-lang to /ivy/build-a-ivy-repository/myrepository/advanced/apache/commons-lang/javadocs/commons-lang-1.0.jar [ivy:install] published ivy to /ivy/build-a-ivy-repository/myrepository/advanced/apache/commons-lang/ivys/ivy-1.0.xml [ivy:install] :: install resolution report :: [ivy:install] :: resolution report :: resolve 0ms :: artifacts dl 6255ms --------------------------------------------------------------------- | | modules || artifacts | | conf | number| search|dwnlded|evicted|| number|dwnlded| --------------------------------------------------------------------- | default | 1 | 1 | 1 | 0 || 2 | 2 | --------------------------------------------------------------------- BUILD SUCCESSFUL Total time: 10 seconds
$ find /ivy/build-a-ivy-repository/myrepository/advanced -type f -print /ivy/build-a-ivy-repository/myrepository/advanced/apache/commons-lang/ivys/ivy-1.0.xml /ivy/build-a-ivy-repository/myrepository/advanced/apache/commons-lang/ivys/ivy-1.0.xml.md5 /ivy/build-a-ivy-repository/myrepository/advanced/apache/commons-lang/ivys/ivy-1.0.xml.sha1 /ivy/build-a-ivy-repository/myrepository/advanced/apache/commons-lang/jars/commons-lang-1.0.jar /ivy/build-a-ivy-repository/myrepository/advanced/apache/commons-lang/jars/commons-lang-1.0.jar.md5 /ivy/build-a-ivy-repository/myrepository/advanced/apache/commons-lang/jars/commons-lang-1.0.jar.sha1 /ivy/build-a-ivy-repository/myrepository/advanced/apache/commons-lang/javadocs/commons-lang-1.0.jar /ivy/build-a-ivy-repository/myrepository/advanced/apache/commons-lang/javadocs/commons-lang-1.0.jar.md5 /ivy/build-a-ivy-repository/myrepository/advanced/apache/commons-lang/javadocs/commons-lang-1.0.jar.sha1
<?xml version="1.0" encoding="UTF-8"?>
<ivy-module version="1.0">
<info organisation="apache"
module="commons-lang"
revision="1.0"
status="integration"
publication="20051124062021"
namespace="ibiblio-maven2"
/>
...
How does this work ?
Actually, Ivy uses the same repository as before for the source repository, with only one difference: the namespace parameter:<ibiblio name="libraries"A namespace is defined by a set of rules. These rules are based on regular expressions and tell Ivy how to convert data from the repository namespace to what is called the system namespace, i.e. the namespace in which Ivy runs most of the time (Note: the Ivy cache always uses the system namespace).
root="${ibiblio-maven2-root}"
m2compatible="true"
namespace="maven2"
/>
For the namespace we call maven2, we have declared several rules. Below is one of the rules:
rule handling the imported apache maven1 projects
<rule> <!-- imported apache maven1 projects -->
<fromsystem>
<src org="apache" module=".+"/>
<dest org="$m0" module="$m0"/>
</fromsystem>
<tosystem>
<src org="commons-.+" module="commons-.+" />
<src org="ant.*" module="ant.*" />
...
<src org="xmlrpc" module="xmlrpc" />
<dest org="apache" module="$m0"/>
</tosystem>
</rule>
Note about regular expressions usage :
In order to distinguish matching regular expressions found in organization, module, and revision, the notation Ivy uses prefixes the matching regular expression with the letters 'o', 'm' and 'r'.
$o0 : the whole matching value in the organization attribute
$o1 : the first matching expression group that was marked in the organization attribute
...
The same applies for modules : $m0, $m1, ...
and for revisions : $r0, $r1, ...
To understand namespaces,
$o0 : the whole matching value in the organization attribute
$o1 : the first matching expression group that was marked in the organization attribute
...
The same applies for modules : $m0, $m1, ...
and for revisions : $r0, $r1, ...
- fromsystem : we define here that the projects defined in the system namespace under the organization called "apache" are transformed into the destination namespace into projects whose organization is named with the module name, whatever the revision is. For example, the project apache#commons-lang;1.0 in the system namespace will be translated into commons-lang#commons-lang;1.0 in the maven2 resolver namespace.
- tosystem : we define here the reverse mapping, i.e. how to translate apache projects from maven 2 repo into apache projects in the system namespace. The rule used here tells Ivy that all projects matching commons-.+ (see it as java regular expression) for their organization name and module name are transformed into projects whose organisation is apache with the module name as it was found. The same kind of rule is defined for others apache projects like ant, etc.
Run
ant maven2-namespace-depsand you will see the resulting repository is cleaner than the first one we built.
From our experience, investing in creating a namespace is worth the time it costs if you often need to add new modules or revisions of third party libraries in your own repository, where naming rules already exist or are rather strict.