Managing Maven dependencies with an external dependencies repository

Content:

Maven abstract.

Tunning your Maven proyect

Maven standard folders

Managing dependencies with Maven

Adding a nature in Eclipse

Maven profiles inheritance

Managing Maven dependencies with an external dependencies repository

I have been talking a lot about Maven dependencies for a local machine. It is high time to start talking about remote dependencies.

When you define a dependency in your pom.xml file, that dependency is sought in repo1.maven.org. But your libraries and internal dependencies are not there. Certainly they are in your local repository, but not in your workmate's own.

I do not find necessary to speak in favour of a code repository, the reasons are widely known. Reasons for a dependency repository might be less known because code is always used, but Maven is not (always).
Basic scenario is easy to find nevertheless:

• You create a library for a project with Maven.
• You design that library as a dependency for that project.
• You might want your workmate to compile the project in his/her computer, but...
• Binaries should never be uploaded to code repository!
• Shared folders are system dependant and difficult to automatize, trace and export.
• We are looking for zero specific configuration in a compilation.

If you could only upload to a private repo1.maven.org repository in order to make accessible an internal dependency for your company... You can!

There are two main open-source implementation for this task: Nexus and Artifactory. Both seem alike, but I chose to know deeply the last one, maybe I could find some time for comparing both in installation, configuration and performance. 

If you had in your pom.xml a configuration like this:

    <repositories>

        <repository>

            <snapshots />

            <id>snapshots</id>

            <name>libs-internal</name>

            <url>http://localhost:8080/artifactory/libs-internal</url>

        </repository>

    </repositories>

With this entry in pom.xml, we are asking Maven to search in this URL for any dependency we might need, and, for being in pom.xml, that configuration is project-scoped, being shared with the project itself in code repository.

All we have to keep in mind is that the server MUST be accessible by any of your partners who you are expecting to compile the project. In this example, our partners will find that they do not have Artifactory installed in their localhost, and you will find lots of complains for creating a local-dependant configuration for a department project.

Your second try made it better:

        <repository>

            <snapshots />

            <id>snapshots</id>

            <name>libs-internal</name>

            <url>http://srvmachine:8080/artifactory/libs-internal</url>

        </repository>

and now, if that machine is accessible for all your department, and permissions are well configured, so firewall is, and half a dozen more configurations, your dependencies would be able to download broadly.

However, as you find comfortable to download dependencies, you will find awful to upload your libraries manually through web interface. It is possible as well to improve this.

With the correct Artifactory and Nexus (trying to be neutral by now) settings, you can automatize your system for uploading a library once it is compiled by Maven:

<distributionManagement>
    <repository>
        <id>linux-wdx0</id>
        <name>linux-wdx0-releases</name>
        <url>http://srvmachine:8080/artifactory/libs-release-local</url>
    </repository>
</distributionManagement>


by typing "mvn deploy" instead of "mvn install" in your Maven console or IDE compilation button.

Now you can enjoy of an easy way to share and download department-scoped libraries within your department in a new fashion way of making things work. Your objetive: your project should compile and run only by downloading it in any machine with zero configuration.