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.

Essential Readings: Look for your cow, assassin evilly your cow.

Taken from The Rhetorical Journey 

This is a tale about dependency, "we aren't that bad"-ing and cowardy inside us all. Be critic with yourself, your work and your way of life everyday.


Kill the cow

A family lives in the outskirts of a remote village on a small plot of land.  The family own one cow.  Each day they live from the milk of the cow.  If there is little milk, they eat little.  It there is lots of milk, they eat well.  The lives of the mother, the father, the children depend on the cow.

One autumn day, a lone traveller stops in the village.  He is hungry.  The family share their milk.  The traveller is grateful.

The traveller wishes to return the favour and help the family.  He doesn't know how to help the family.  He hears that there is a wise man in the village.  He walks over to the home of the wise man.

"I was hungry and the family fed me.  I would like to help them.  How can I help this family?"

The wise man said "Kill the cow."

"Kill it?  How can that help them?  They depend for their lives on that cow."

The wise man repeated "Kill the cow."

The traveller was nervous about following such strange advice,  but the reputation of the wise man was such that he went ahead and killed the cow.

A year later the traveller happened to pass again through the village.  He noticed new shops and a thriving market.  He saw a new hotel that provided beds and food to the travellers who came for the market.  

The traveller entered the hotel.  Behind the bar he found the eldest son of the family of the cow.  The man was standing tall, smiling and happy.  The traveller greeted him and asked "What happened?".

"We lost our cow.  There was no milk.  We had to go out and do something to eat.  We set up a small market, it grew.  We set up this hotel, it is growing.  Without the milk from our cow, we had to try new things."

Silently to himself, the traveller reflected on the power of the wise man's words.  "Kill the cow."

What is your cow?

Roll your own Continuous Integration System (C.I.S.): Abstract.

Roll your own Continuous Integration System (C.I.S.)


Content:

Abstract

Install Tomcat

Basic Tomcat configuration - Memory

Basic Tomcat configuration - JMX

Basic Tomcat configuration - Application Manager and permissions

Apache and uSVN

Installing Artifactory from WAR

Configure Artifactory and MySQL

Configuring Artifactory security and repositories

http://looking4q.blogspot.com/2011/01/roll-your-own-continuous-integration.html

This is the very first goal for the followers of this blog.

For those who doesn't know what a Continuous Integration System is, you could take a look at wikipedia, but, summarizing with an example, is a software that every night downloads your code, compiles it, executes unitary testing and deploys it in your server or in your dependency repository.

That's not all. It could pass several control checks like code style, testing code coverage, code quality, it makes a report and send it to your email, and other for the guilty developer that wrote some code that generates lots of warnings.

This information is processed for cyclic dependencies, copied&pasted code, percent of commented code, percent of tested code... reports and more reports.

Some of this reports are also postprocessed in order to evaluate each developer independently. Then it creates a dashboard with scores for each participant, trying to motivate the team for a better code.

Appealing enough?

I have selected some tools that I use in my company. This list might be modified in near future:

Code Repository: We are using Subversion
Dependencies manager: Maven
Dependencies repository: Artifactory, which understands Maven among others.
C.I.S Manager: Hudson: which understands Maven and SVN among others.
Extra: Sonar as quality of code reporter.
Extra: Wiki or CMS

And Tomcat6 as the container of everything or almost everything.

In next articles, I will try to explain how to install and deploy each tool in order to get something similar to my example in your own company or at home.

See you soon!