Why Moxie?

Why not. :)

Moxie is written for those who prefer Ant or for those who must continue building with Ant, though they may yearn for Maven or Gradle.

Don't Repeat Yourself

As a Java developer you are faced with the need to develop code and then build deliverables from your code. Often these two requirements have different solutions which require maintaining IDE settings and an Ant script full of paths and properties. (i.e. Eclipse .classpath is not directly usable from Ant). This is maintenance intensive, often leads to verbose Ant build scripts, and violates the DRY Principal.

At it's core, Moxie does two things for you:

1. Allows you to define your project code structure and dependencies once.
   This information is used to generate IDE settings and to setup classpaths and properties for your Ant script.
2. Resolves and retrieves your dependencies (and their dependencies) with checksum verification.

Limitations

Some will consider Moxie rinky-dink, and I have to agree that it is less capable than the alternatives.
If the following limitations are of concern, then Moxie may not suit your needs.

1. Moxie employs the Maven 2 transitive dependency resolution mechanism
   Currently, Maven 2.0 only supports using the "nearest definition" which means that it will use the version of the closest dependency to your project in the tree of dependencies. You can always guarantee a version by declaring it explicitly in your project's POM. Note that if two dependency versions are at the same depth in the dependency tree ... the first declaration wins.
2. Moxie has simplified/limited support for version ranges.
   When Moxie encounters a version range specification it will always resolve the highest version number possible based on the range specification and the list of versions in maven-metadata.xml. The resolved version identifier is substituted for the version range specification. From that point the "nearest definition" rule is applied. Maven version-pinning, like [1.2.3], is not honored.
3. Moxie does not currently deploy artifacts to a remote repository.

Why not Maven?

There is much to admire and respect about Maven.

Maven has done some tremendous things and has moved the Java ecosystem forward. But while I like Maven repositories and the artifact metadata, I dislike the Maven build process. I want to define my own build rules and flow, not be forced to use Maven's grand unified process.

Lessons learned from Maven

1. A central repository of project artifacts accessible by http is brilliant.
   I don't think Maven is given enough credit for the amazing achievement of convincing hundreds of Java open-source projects to offer their artifacts through a central repository.
2. Defining and recursively retrieving dependencies of those artifacts is really brilliant.
3. Fighting Maven causes pain.
   Convention-over-configuration simplifies the build process, but convention-instead-of-configuration is too restrictive. Not every project can be easily represented by a Maven POM without massive reorganization.

Why not Gradle?

I like the idea of Gradle. I have not used it. I may use it in other projects, but I feel that Ant doesn't have to be put out to pasture quite yet.

Why not Ant+Ivy?

Ivy is probably a more robust dependency manager and definitely supports more transports. But it is strictly an artifact retrieval/deployment tool. It does nothing to decrease the complexity or verbosity of Ant build scripts. It is a artifact manager with a complex XML configuration file. And at 1 MB it is a bit too large to embed within a repository, IMO.

Why not EasyAnt?

EasyAnt, if you've never heard of it - because I had not - is an Apache incubator project which targets offering a Maven-like experience using an enhanced Ant. Moxie is not as ambitious in it's design as EasyAnt; Moxie is more of a subset of EasyAnt. EasyAnt is based on Ivy.