Maven and other technology quick-starts and hello-worlds we find on-line are usually written in the context of least resistance.  We usually don’t have to worry about firewalls, proxies, or other hoops to jump through.  If this were any different, the so-called “quick-start” would quickly turn into a “painfully-slow-start”.  This is why quick-starts don’t stress these kinds of details, because their primary focus is the new technology at hand. But what happens when we’re in a corporate environment? We have network restrictions, proxies, white-lists, and a plethora of other considerations we need to handle!  This is where typical quick-starts quickly (pardon the pun), become not so helpful.

We’ve set up our environment as per the vanilla instructions, but now we have to get creative.  In this blog, we’re going to discuss how to implement a Maven repository, a critical component of the popular Maven build tool, on a typical corporate network (one that has restrictions).

Environment

In our discussion, we will leave the heavy details of network complexities behind us, and will describe our topology as a network which has different restrictions. All we need to acknowledge is that our network has different areas with different restrictions.  Some machines (developers’ workstations) can connect to the Internet, others (production servers) cannot.  This is an absolutely acceptable setup, and is of course the recommended approach for network security.  In the easy case, there are 2 straightforward solutions.  Either configure Maven to use a proxy or punch a hole through the firewall to allow the needed traffic.  However, what if for whatever reasons, these solutions are not possible?  In the worst case, we have a work-around to configure our Maven repository even in a restricted network like described.

Developers develop code in their IDE, and commit their code to a VCS (version control system).  Maven needs access to all the dependencies required by the application’s source code.  Our build machine is in the part of the network which does not have access to the Internet. Our Maven build tool uses its Maven repository regardless of the set up.  Whether Maven is running standalone or is running inside a CI tool like Jenkins, the end-result is the same – Maven is using its repository to do the build. Since developers’ machines have access to the Internet, developers do not have any problems having Maven download the needed dependencies.

Maven Repository Workflow

The problem is that our build machine does not have access to the Internet.  To solve this problem:

• Set up a Helper Jenkins instance on a development machine.  The sole purpose of this instance is to have Maven update its repository on this Helper Jenkins instance. You do not want to configure any build notifications on this Helper Jenkins instance.
• Next, set up a cron job if you are on Linux, or a scheduled task if you are on Windows, which runs an rsync command. Periodically, this task will transfer all the deltas from the Helper Jenkins instance’s Maven repository to the Official Jenkins instance’s Maven repository on the build server behind the Internet.

As an example, let’s say that our Official Jenkins Maven repository currently has version 3.3.1 of commons-lang3 from org.apache.commons.

• A developer checks in a new revision of source code into the VCS, including a new POM update with a dependency on version 3.6 of this artifact.
• The Helper Jenkins instance will download this new artifact to its local repository while it is doing the build of the new source code revision.
• Subsequently, the scheduled rsync job will pick up this delta, and will transfer this new version of commons-lang3 to our Official Maven repository. Diagram follows.

As such, the Official Jenkins instance will always have an updated repository. On this Official Jenkins instance, you want to configure build notifications, plugins, and anything else you need. Thus, this is your production Jenkins instance. You can then use this instance to deploy your built binaries to the target deployment servers.

Summary

By working around your network limitations, even in instances when your proxy will not allow connectivity to the official Maven repository on the Internet, you are able to get your repository up and running by following the process outlined in this blog. You are simply leveraging your existing network in a novel way, and are following all the existing rules with which your network has been configured.