In the previous posts in this series, we've talked about how a repository manger changes the development cycle. In this post, I'm going to talk about how a repository manager can be used as a way to interact with third parties. Specifically, I'm going to talk about vendors and partners.
While Maven Central contains a huge number of libraries, there are still some pretty important things missing. Anything covered by a non-open-source license, like the Oracle JDBC drivers or anything proprietary, isn't going to be made available from the Maven Central repository. Very often there are going to be commercial libraries that you will need to download and install in a third party repository. While this works, it requires some manual work to upload the artifact.
When your vendors embrace repository management, there's no reason why you would have to manually install any third party JARs in your corporate repository. Instead, vendors who need to provide binaries to customers would provide them via authenticated public repositories. These vendor-run repositories, protected by authentication credentials, would allow customers to synchronize local, corporate repository managers with commercial software vendors. This would allow vendors to capitalize on a new, "always connected" model for software delivery.
Now, the situation for the customer is simple. Once they set up an authenticated proxy repository to connect to a vendor's repository, the vendor can deliver new updates and software directly to a customer's repository.
The situation for the vendor is equally straightforward. Instead of having to send the customer a packaged set of binaries, they simply tell the customer to update a version number in a dependency. The build will then interrogate the customer's repository and then automatically download the repository from the vendor.
Both the customer and the vendor have fewer moving parts to worry about, and the task of delivering software becomes very simple.
The vendor receives another benefit from this setup. They are now able to keep track of which customers had requested which artifacts. The vendor can control which artifacts or features of a product suite a customer has access to, and they could use the repository manager as a way to enforce licensing or provide metered, on-demand access to software components.
In today's increasingly connected world, it is very common for one company to provide an API for partners. Sites like Twitter and Google provide APIs for the general public, and other companies provide partner-specific APIs for collaboration. If you provide an API for a partner company, you can expose libraries and interfaces using a public-facing, authenticated repository.
Suppose that you work at a financial institution that needs to partner with another financial institution. The two institutions have agreed to collaborate with one another using a simple set of REST services. While these REST services are very well documented, you also want to make sure that your partner is invoking these REST services according to a set of standards. To make it easier to consume these services, you've created a simple client library for your partner.
To make it even easier for your partners to use this library, you've published versions of this library to a public-facing, authenticated repository. Using the security features of a modern repository manager, you can create partner-specific library versions and limit access to just the intended recipients. You can also maintain detailed audits of when a particular API was delivered to a particular partner.
As more and more organizations start to adopt the best practice of running a repository manager, these same organizations will be creating ad-hoc, private relationships to emulate the ease of Maven Central for a corporate environment. Partners, vendors, and consortia of companies will create repositories to facilitate code sharing and cooperation.
