The availability of most Java libraries in Maven's repositories is the most valuable of its features. It is difficult to say if Maven's build and deploy tools were the catalyst or that its appearance simply coincided with a time when it was obvious to all that centralized repositories with a common access protocol was needed. The why does not matter much now as we have Maven and it is well established in the Java ecosystem.
A Maven repository (aka a site) is a well defined file system accessible via one of several protocols. If you are using HTTP then the repository server needs to implement the GET and PUT methods for files. For example, if your dependency is (pom.xml)
<dependency> <groupId>com.andrewgilmartin</groupId> <artifactId>example1</artifactId> <version>1.0</version> </dependency>
and the repository is
<repository> <id>neighborhood</id> <url>http://localhost:8080/repository/</url> </repository>
then when you use Maven to build, eg
mvn -U clean package
Maven will initially GET the dependency's files
and then based on the detail in maven-metadata.xml it get will GET the files
/repository/com/andrewgilmartin/example1/1.0/example1-1.0.jar /repository/com/andrewgilmartin/example1/1.0/example1-1.0.jar.sha1 /repository/com/andrewgilmartin/example1/1.0/example1-1.0.pom /repository/com/andrewgilmartin/example1/1.0/example1-1.0.pom.sha1
When you deploy, eg
using the distribution management (pom.xml)
<distributionManagement> <snapshotRepository> <id>neighborhood-snapshots</id> <name>Neighborhood Snapshots</name> <url>http://localhost:8080/repository/</url> </snapshotRepository> <repository> <id>neighborhood-release</id> <name>Neighborhood Releases</name> <url>http://localhost:8080/repository/</url> </repository> </distributionManagement>
Maven will first GET the files
/repository/com/andrewgilmartin/example1/1.0/maven-metadata.xml /repository/com/andrewgilmartin/example1/1.0/maven-metadata.xml.sha1 /repository/com/andrewgilmartin/example1/maven-metadata.xml /repository/com/andrewgilmartin/example1/maven-metadata.xml.sha1
and then PUT the files
/repository/com/andrewgilmartin/example1/1.0/maven-metadata.xml /repository/com/andrewgilmartin/example1/1.0/maven-metadata.xml.md5 /repository/com/andrewgilmartin/example1/1.0/maven-metadata.xml.sha1 /repository/com/andrewgilmartin/example1/1.0/example1-1.0.jar /repository/com/andrewgilmartin/example1/1.0/example1-1.0.jar.md5 /repository/com/andrewgilmartin/example1/1.0/example1-1.0.jar.sha1 /repository/com/andrewgilmartin/example1/1.0/example1-1.0.pom /repository/com/andrewgilmartin/example1/1.0/example1-1.0.pom.md5 /repository/com/andrewgilmartin/example1/1.0/example1-1.0.pom.sha1 /repository/com/andrewgilmartin/example1/maven-metadata.xml /repository/com/andrewgilmartin/example1/maven-metadata.xml.md5 /repository/com/andrewgilmartin/example1/maven-metadata.xml.sha1
The Maven client does all the work to ensure that the repository has all the necessary metadata about the deployed package. That is, the HTTP server needs no Maven intelligence. A dedicated repository manager, like Apache Archiva, Sonatype Nexus, and JFrog Artifactory, does far more than just manage files, but for small collections these features are not needed.
For the next stage in migrating your Ant project to Maven you need only configure an HTTP server for GET and PUT. If the HTTP server uses the file system directly, then it will need to be able to create the intermediate directories for any PUT files. During the Ant to Maven transition, however, you can use my simple HTTP server at https://github.com/andrewgilmartin/filehttpserver/. For production you will likely want to use, for example, Apache2 and WebDav.