Be just enough. Be useful. Don't overreach. Don't impose. Don't Repeat Yourself.
Moxie is not designed to be Maven. It is designed to be an Ant enhancement for a Maven-dominated world.
Moxie employs a two-pass solver which is executed for each scope (compile, test, etc).
To improve the efficiency of dependency resolution, Moxie uses the following information sources to re-order your repositories, per-dependency, to hopefully download the dependency from the first repository contacted:
Version ranges are the ugly duckling of Moxie. They are only partially supported. Maven (Aether) has a very sophisticated mechanism for dealing with version ranges which Moxie will never attempt to reproduce. IMHO version ranges are an unnecessary implementation complexity.
When confronted with a version range specification, Moxie will resolve the highest version it can by consulting the maven-metadata.xml file. Moxie does not consult the entire dependency graph during version range resolution. This is a gross-simplification of the Maven version range feature.
By default, Moxie stores it's retrieved artifacts and metadata in
The directory structure takes design elements from both Maven and Gradle. Despite my preference for Gradle's groupId directory structure (org.apache.ant/ant/1.8.4), the Maven 2 directory structure was adopted (org/apache/ant/ant/1.8.4) because it allows direct http or ftp serving of those folders to a Maven 2-compatible client. This is exploited by Moxie Proxy, which can serve any Moxie root directory.
A typical Moxie root directory structure may look something like the following:
[data] +--[com] +--[org] +--[commons-io] +--[commons-io] +--[2.2] -metadata.moxie [local] +--[releases] +--[snapshots] [lucene] +--[central] +--[releases] +--[restlet] [remote] +--[maven.restlet.org] +--[repo1.maven.org_maven2] +--[commons-io] +--[commons-io] +--[2.2] -commons-io-2.2.pom -commons-io-2.2.pom.sha1 -commons-io-2.2.jar -commons-io-2.2.jar.sha1 -moxie-toolkit-0.7.0.jar -moxie-toolkit-0.7.1.jar -moxie-toolkit-0.7.2.jar