Maven: A Good Idea

The fundamental premise behind Maven is that it better to make software projects fit the build tool than it is to make a build tool which can handle free form project structure; that doing so has some significant benefits and can be achieved without a loss of generality in the final product. This is opposed to 'free form'<a href="#footnotes" />1</a> build tools which do not impose structure and are better able to accommodate any organisation of source code.

There are two aspects to the standardisation, projects should be both:

  • organised internally in a standard manner
  • organised externally in a standard manner

Standard internal organisation

The standardisation of the layout of source folders<a href="#footnotes" />2</a>, documentation and project meta has the following benefits:

  • unburden developers with making trivial naming decisions
  • make projects more comprehensible to unfamiliar developers
  • (most importantly) simplify usage and programming of build tasks

Importantly, the arrangement of source files within a project does not place any restrictions or particular hindrance on the output that can be produced. Indeed in free form build systems it is increasingly recognised as best practice to standardise project layouts.

Standard external organisation

Projects should be named and versioned in a consistent manner. Within a build it should be possible to reference dependencies by only their name and version<a href="#footnotes" />3</a>, a fundamental to proper dependency management in which the concern of actually locating dependencies is handled by the build system.

This decoupling is an example of separation of responsibilities — a fundamental good practice in software development. It de-contextualises the build process, making it much easier to port to different machines and different systems. Again, in free form build systems standardised layout has become increasingly recognised as best practice.

Declarative Configuration and Build Plugins

The standardisation of projects facilitates a second important idea, which is that the build process can be described in completely declarative way, decomposed into discrete steps to be performed by specialised build plugins. This contains logic and messy details within separate projects, and has all the concomitant benefits of properly managing the build code in a unified system.

This is opposed to free form build systems where logic is contained within auxiliary build files within a project. In the free form way there are two separate worlds: the project code, managed by the build system, and the the build code, managed in a more ad-hoc manner. Concerns such as how to specify the runtime path are duplicated with the build code<a href="#footnotes" />4</a>.

Representing the build in a declarative manner yields a further benefit, the potential for harmonious co-existence between the build and the development environment (most commonly an IDE). For it enables the description of the build process to be used as the basis for generating the configuration required by the development environment<a href="#footnotes" />5,6</a>.


The basic premise behind Maven is a good one, with significant benefits there to be realised. Indeed EBuild is also based upon the principles outlined. However, in implementation, there are a lot of problems with Maven — as discussed in this follow-up article ‘Maven: The Bad Parts’. It may be the case that frustrations with Maven have made people question the premise and thus they persevere with free form build solutions.

It is beyond the overarching ideas outlined here that the design of EBuild diverges from Maven. The follow-up article ‘EBuild: Design Principles’ discusses in further detail how it aims to improve upon existing build technologies.


<a name="footnotes" />

  1. For example the emblematic src/main/java.
  2. i.e. Not locations in the file system, relative or otherwise, or urls.
  3. the consequence of virtually guaranteeing that the build language is dynamic
  4. In case it is not clear, a free form build file cannot be used as the basis to generate configuration, because turing completeness means it is impossible to reliably extract such information.
  5. Or indeed directly as the configuration of the IDE.