Note: All comparisons are made in good faith and to the best of the author's knowledge. If there are any factual inaccuracies, or overly egregious subjective inaccuracies please contact us so the comparisons can be updated.

  1. EBuild Vs. Ant(+Ivy)?
  2. EBuild Vs. Maven?
  3. EBuild Vs. SBT
  4. EBuild Vs. Gradle/Buildr?
    1. Imperative/Declarative or Declarative
    2. Features
    3. Other Differences
    4. Conclusion

EBuild Vs. Ant(+Ivy)?

It is possible, but challenging to create complex and reliable builds using the combination of Ant and Ivy. However it is an expert process, which requires a lot of time and understanding. It lacks, by design, important features such as IDE configuration generation, and the inability to reason about the build at a higher level (there is no real concept of a module in Ant for example) is limiting.

Ant is an old design which is becoming a legacy environment and as such not really considered as a serious competitor to EBuild. This article contains a more in depth discussion of the limitations of Ant.

EBuild Vs. Maven?

EBuild shares the same basic premise as Maven, which we believe to be a good one. The problem with Maven is the limitation in its build model and an inelegant implementation. Overcoming these limitations and having a better implementation are important considerations in the design and development of EBuild.

Maven is a mature platform, which has advantages. However if forced to workaround Mavens limitations, or work within its limitations then EBuild is a good alternative.

EBuild Vs. SBT

SBT is a scala-DSL based build tool. Out of the tools listed here, it can be considered most similar to Gradle/Buildr, (but it is perhaps simpler and less ambitious in scope than either of Gradle, Buildr or EBuild).

EBuild Vs. Gradle/Buildr?

Gradle and Buildr are included together due to their similarities. They are all nascent build systems which post-date Maven and are built upon dynamic languages (Gradle/Groovy, Buildr/JRuby) on the JVM and share a lot in common in terms of their design. Gradle in particular can be thought of as an evolution of Ant, introducing a more expressive language and higher level concepts such as a project model<a href="#footnotes" />1</a>. As more modern and sophisticated build systems, Gradle and Buildr warrant a more in depth comparison to EBuild.

Imperative/Declarative or Declarative

Coming after Maven, Gradle/Buildr acknowledge the need for supporting standardised project structure and a dependency resolution. They do this using a hybrid imperative/declarative configuration model. In this system the build file (i.e. build.gradle / buildfile) is responsible for constructing a project model which describes the desired build process. From this project model they are able to perform the build and generate IDE configuration files<a href="#footnotes" />2</a>.

They have the perhaps dubious advantage over EBuild, that the expressive power of Groovy/JRuby can be used when constructing the build model. In EBuild it is considered that the build model is designed to be completely general and can build anything without compromise<a href="#footnotes" />3</a>. As such scripting and the hybrid declarative model are unnecessary complication.

The obvious disadvantage of using scripting languages is that there is a lot to them which needs to be known or learnt in addition to understanding the build model. The other issue is that they introduce increased scope for misunderstanding and generally make for a more complicated build process that is harder to comprehend and maintain.

EBuild does not feel that scripting languages are even a necessarily required as part of the build process<a href="#footnotes" />4</a>, rather any high level language could be used, given appropriate library support. The prevalence of scripting in build tools . is the practice of associating a build script with a project which effectively meant that providing a separate path and compilation to the build script was never a properly solved problem. By making dependency management as light weight as possible, EBuild enables the developer to split off any custom build logic into its own build module so that it can be managed as a 1st class entity within the build system, with dependency management and unit testing (if so desired) in the same fashion as any other project.

Gradle/Buildr are turing complete environments. A consequence of this is that it is not possible to write reliable graphical interfaces for configuring their build models, which is the kind of basic functionality that full IDE integration would look to provide (although some workaround could conceivably be arranged). However this distinction is somewhat academic since neither they nor EBuild have such a plugin.


EBuild, Gradle and Buildr currently have comparable level of support in terms of languages supported, other plugins and documentation. Gradle is probably the most mature of the three, followed by Buildr, followed by EBuild which was released latest.

Other Differences

The Gradle/Buildr build models do not make the distinctions that EBuild makes between Modules and Products<a href="#footnotes" />5</a>, and are more complicated for this.

Buildr and Gradle centrally installed tools which is not good for build reproduceability. This is particularly an issue with tools which are still in pre-1.0 development, since breaking backwards compatablity will result in being unable to build older versions of a project.


The design of EBuild is simple, yet general, which makes it easy to learn and maintain. On the other hand if there are non-negotiable constraints, such as pre-existing project structures or the need to locate dependencies in arbitrary locations, then Gradle/Buildr are certainly easier to customise due to the flexibility of their approach.

<a name="footnotes" />

  1. Indeed Gradle was preceded by Gant, which was just Groovy+Ant, without any of the higher level concepts.
  2. And in doing so overcoming one of the major weakness of imperative build systems, in which the duplication of dependency information in IDE configuration files is essentially unavoidable.
  3. Certain features such as parameterized builds, are not yet supported but are in the road map.
  4. Although there is nothing preventing the use of scripting. It can even be embedded in the build file if it is supported by the Assembler/Builder.
  5. Since the two cases of depending on a Module for code, and depending on a Product for inclusion are fundamentally different (transitive vs. intransitive; Modules need conf in IDEs, Products do not ... etc).