If you know all about Maven skip down to A DNS Record for Maven Repositories
Most people that do software development and/or deployment on environments that run on the JVM (Java Virtual Machine), have come across Apache Maven (or tools such as Apache Ivy that interface with Maven repositories), and know that it is a great tool for managing dependencies for applications. Most Open Source and commercial (or semi-commercial) software packages and modules offer public Maven repositories to get the components (and the right versions of them) automatically downloaded when you are building/assembling your application.
There is also challenges, such as Maven allows you to declare dependencies, and automatically resolve dependencies in third party modules, but what if that particular module is not available in the public Maven repository, where can you find it? You often end up googling for things like “+org.restlet +maven +repository” to find where that particular module is published and downloadable for Maven, and adding that repository either to the build files (for Maven, Ivy etc) or to your maven settings in your home directory.
I think this could be done much more automated, and thus I am proposing an introduction of a DNS record to expose Maven repositories and have Maven (and other tools that use Maven repositories) be able to resolve these repository end-points automatically.
A DNS Record for Maven Repositories
The standard I propose would make it easy for anybody, open source project or commercial software company, to publish a pointer to a Maven Repository (and it can even be fully or partially protected for commercial modules) through a simple DNS entry, and then have Maven automatically resolve that repository.
The whole idea is to allow the owners of an domain to declare a pointer in their DNS that tells Maven where to find the Maven Repository associated with that domain.
This is an example DNS record of how to declare a Maven Repository (this would be part of the DNS zone file):
@ 3600 IN TXT "maven-repository=https://nicolaiwadstrom.com/maven2/"
Try this for my domain, in a Mac OS X, Linux or Windows terminal/command prompt enter:
nslookup -type=txt nicolaiwadstrom.com
This should give a response as follows:
Server: 172.16.1.1 Address: 172.16.1.1#53Non-authoritative answer: nicolaiwadstrom.com text = "maven-repository=https://nicolaiwadstrom.com/maven2/"
This would in the standard I propose here, tell Maven that for all packages with an Maven Group ID (or organization identifier) of “com.nicolaiwadstrom”, the primary repository is located at “https://nicolaiwadstrom.com/maven2/”.
We always reverse the the Maven Group ID (or Organization in other words), we are always asking the authority (owner of that domain/DNS, such as nicolaiwadstrom.com) for the packages that are part of “com.nicolaiwadstrom”.
This do not mean that we fix any existing problems with man-in-the-middle DNS attacks, but we do not introduce additional security issues (as anybody in the middle can spoof any existing Maven repositories, such as the central Maven repository). Existing standards such as DNS Sec should be used to address those concerns.
Multiple repositories with priorities. This standard would typically need to support multiple repositories to support fail-over etc. Proposed format for this would be to have multiple DNS entries, and prepend the priority such as:
@ 3600 IN TXT "maven-repository=10;https://maven1.nicolaiwadstrom.com/maven2/"@ 3600 IN TXT "maven-repository=20;https://maven2.nicolaiwadstrom.com/maven2/"@ 3600 IN TXT "maven-repository=30;https://maven3.nicolaiwadstrom.com/maven2/"
This would be resolved as 3 different URL’s for this Maven repository, top priority is “https://maven1.nicolaiwadstrom.com/maven2/”, if that can’t be reached (or does not contain the component, or version referenced), “https://maven2.nicolaiwadstrom.com/maven2/” should be tried and finally “https://maven3.nicolaiwadstrom.com/maven2/”. This also allows open source projects that are available in the central Maven repository to point to that as a primary resource, and have lookups fail-over back to their own servers.