Why choose Buckminster over Maven?

Question

I've been using Maven for several months and I am pretty comfortable with how it works conceptually and in practice.

I have also looked at Buckminster quite extensively (but have not gotten to running samples yet) to try and figure out what it is and how it compares. The documentation is poor. For instance, they use terminology like Build Automate and Deploy, but I have yet to see anything about deployment. Staged-migration is another hinted-at but un-discussed topic.

Both Maven and Buckminster give you the ability to specify dependencies and generally manage the build, test and possibly deploy processes.

They both have eclipse integration and should both (having only used Maven) trivialize the setup and sharing of eclipse based projects and their dependencies.

The major differences that I can see are:

• Dependencies:

  • Buckminster can specify dependencies living in source repositories and it's own type of repository in addition to being able to reference Maven repositories for dependencies.
  • Buckminster can group dependencies into virtual distros and is also platform aware. The grouping of software certainly seems possible in Maven with poms that reference other dependecies and group them.

• Build

  • Maven uses an implicit build system based on layout. It is very easy to create a default project, put things where they are expected to be and have maven build, test and create jars. At the same time, being implicit can also be constricting. You have to live with how Maven does things.
  • Buckminster - It is not clear to me how Buckminster decides what to build and how to build it. It would seem that this would align with the eclipse process for doing the same. Buckminster also allows the use of ant, but it is not clear if this is a requirement. At the very least, the lifecycle is less (un?) defined for good or bad, allowing more flexibility.
  • Both tools allow for headless builds, although buckminster may carry a bit more baggage along with it.

• Plugins

  • Maven has a very extensive set of plugins for all phases of the lifecycle for many different kinds of automation, from code generation to running embedded services for testing.
  • Buckminster does not appear to have the same concept of plugins. There are readers and actors, but they do not seem to play the same role. Buckminster should have access to the extensive set of plugins available for ant. It is not clear how well ant actions can be seamlessly integrated with the rest of Buckminster processes (this is also an issue for the maven ant plugin).

• Deployment

  • Maven has a number of plugins for generating distributions of software (assemblies) and moving them around (wagons). Does Buckminster get all of this from Ant?

• Complexity

  • The different schemas for Buckminster can be quite complex, between CPECs RMAPs MSPECs, etc.
  • Maven is somewhat simpler configuration-wise, although it can get complex with large and multi-module projects. Maven also has Archetypes for easy creation of new projects.

• Documentation

  • They are both bad. ;-)
  • Buckminster is very shallow, documentation-wise. Not enough examples are available.
  • Maven plugins tend to have very poor documentation, making it difficult to get them running correctly.

From my perspective, most of what I would want to do with Buckminster I can do with Maven. "Materializing" from version control is a plus, but developers within an organization can publish maven snapshots to a repository to share with each other, in addition to just providing fixed versions.

There does seem to be more flexibility and freedom from the strictures of the Maven lifecycle (ever wanted to add another phase, like post-test for cleanup? Gotta wait for them to do it in the core).

What am I missing? Is there some major amount of functionality in Buckminster that is worth the step up in complexity?

Are there any wildly innacurate statements above (given that I am not a Buckminster user and only a low-mid level Maven user)?

Answer 1

Some clarifications.

• Dependencies

  Buckminster does not have a repository type of its own. It has a discovery mechanism that translates existing meta-data such as a Maven POM into a model that can be understood by Buckminster. This meta-data can be added verbatim as an XML file if it cannot be derived in any other way.

• Build

  Buckminster decides what to build the same way the Eclipse IDE does. In addition to that it extracts information from known artifacts such as the manifest, build.properties, plugin.xml etc. and translates it into actions in the model that can be explicitly triggered using the Buckminster perform command.

  I'm not at all convinced that Buckminster carries more baggage for headless builds. In fact, I think the opposite is more common. Building with Maven on an empty machine often starts with a download of a very large number of components even if the task at hand is trivial.

• Plugins

  Buckminster is based on OSGi and extended using Eclipse Extension points. It is possible to add new types of repositories, new types of actions, new discovery mechanisms, and more using this mechanism.

• Complexity

  A minimum Buckminster configuration only needs one CQUERY and an RMAP. With them, it is possible to build a full p2 update site of arbitrary size that is signed and processed with pack200. No files needs to be added to any of the features and bundles. Nothing needs to be "Buckminsterized". So I'm not sure I agree that Maven is simpler to configure.

Aside from the benefits already mentioned by Roland and Zoltán, I'd like to add that since the buckminster build is a true workspace build, it will leverage all builders that have been declared in the .project file. Here are some examples:

• PDE Manifest builder - generates warnings and errors from manifests, property files, etc.
• PDE Schema builder (same thing for Extension point schemas)
• All other builders made for the Eclipse Build structure. This includes XML schema validation builders, Java Script builders, and many many others.

I'm sure that Maven has correspondence for a majority of them. The point with Buckminster is that you don't need to maintain an extra build system. What works in the IDE workspace, also works headlessly.

Answer 2

Maven uses an implicit build system based on layout. It is very easy to create a default project, put things where they are expected to be and have maven build, test and create jars. At the same time, being implicit can also be constricting. You have to live with how Maven does things.

Actually, you can explicitly specify where you put things in Maven. The default locations are just that, defaults, easy to override, though there's rarely a good reason to.

Buckminster - It is not clear to me how Buckminster decides what to build and how to build it. It would seem that this would align with the eclipse process for doing the same. Buckminster also allows the use of ant, but it is not clear if this is a requirement. At the very least, the lifecycle is less (un?) defined for good or bad, allowing more flexibility.

I think Maven tends to follow the philosophy of sensible defaults which are easily overrode.

Maven is somewhat simpler configuration-wise, although it can get complex with large and multi-module projects. Maven also has Archetypes for easy creation of new projects.

Maven's real strength is in its management of dependencies and this tends to shine particularly well in complex projects with multiple subprojects. It's pretty easy to define a hierarchy of subprojects and have it just work.

Documentation: They are both bad. ;-)

Can't disagree with that!

Answer 3

There is a Buckminster Book in PDF available from the Buckminster Download page - more than 250 pages of documentation and includes both introduction and detailed reference documentation.

Download it from here: http://www.eclipse.org/downloads/download.php?file=/tools/buckminster/doc/BuckyBook.pdf