Apache™ > Apache Ant™ > Apache Ivy™ > Documentation (2.1.0) > Tutorials > Building a repository > Using namespaces

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, when the source and destination repositories don't follow the same naming conventions for instance.

On the road to a professional repository

We will study in this section how to build a professionnal repository. What is a professionnal repository? Our vision is to say that a good quality repository must follow clear rules about projects naming and must offer corrects, usuables, configurables 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 usual when you have an existing repository, and want to benefit from a large public repositories which do not follow the same naming conventions. Or simply because you find the public repository you use as a basis is not consistent enough - why all apache commons module aren't don't use the org.apache.commons organization? For historical reasons. But if you setup your own repository you may not want to suffer from history.

Fortunately Ivy has a very powerful answer to this kind of 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 module use their own name as organization.

So let's see what Ivy can do using namespaces (we will dig into details later): Now if we look at our repository, it seems to look fine. We can even have a look at the commons-lang ivy file in our repo: Allright, we see that the organization is now 'apache'. But where did Ivy picked this up?

How does this work ?

Actually Ivy uses the same repository as before as source repository, with only one difference: the namespace parameter:

<ibiblio	name="libraries" 
    root="${ibiblio-maven2-root}" 
    m2compatible="true"
    namespace="maven2"
/>

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 from and to what is called the system namespace, i.e. the namespace in which Ivy runs most of the time (Ivy cache is always using the system namespace for instance).

For the namespace we call maven2, we have declared some rules, here is one:

rule handling 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>

To understand namespaces,

• 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, ie how to translate apache projects from maven 2 repo into apache projects in the system namespace. The rule used here tells 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 applied for others apache projects like ant, etc.

Ok, you should now get the idea behind namespace, you can now check the whole namespace settings provided in the example, and test the installation of a module and its dependencies using namespaces.

Run

ant maven2-namespace-deps

and 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 are already existing or rather strict.