Moxie

Design

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.

Dependency Management

Moxie does not use Ivy nor Maven to retrieve artifacts or to solve transitive dependencies. It has it's own solution engine written based on the Maven, Ivy, and Gradle documentation.

Moxie employs a two-pass solver which is executed for each scope (compile, test, etc).

  1. The first pass retrieves POMs for all dependencies regardless of scope by walking up and down the dependency graph.
  2. The second pass generates the complete tree of resolved artifacts and then employs the nearest rule to eliminate duplicates in the graph.

Dependency Resolution

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:

  1. manually defined groupId affinities
  2. known origin urls (primarily used for metadata and SNAPSHOT updates)
  3. repository .meta/prefixes.txt, offered by some Maven repositories
  4. user-defined order in repositories setting

Version Ranges

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.

Moxie Root Directory

By default, Moxie stores it's retrieved artifacts and metadata in ${user.home}/.moxie.

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.talend.com]
  +--[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

data
directory where Moxie stores Moxie metadata about an artifact: it's origin, record keeping dates, solved transitive dependencies, etc
local
directory where artifacts you build are installed based on their release status
directory where artifacts are copied to when using the COPY Maven cache strategy to re-use ${user.home}/.m2/repository artifacts
lucene
directory where Lucene indexes are maintained, per-registered repository
only applies to Moxie Proxy
remote
directory where retrieved artifacts and standard Maven metadata files are stored, per-repository

Reference links