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)?

Frannie

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.

Agnella

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!

Bridgettebridgewater

A bit late, but here'e a good book for maven sonatype.com/books/mvnref-book/reference/public-book.html – Meteorite

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

Krever

Answer 4

The biggest advantage of using Buckminster is when compiling OSGi bundles or Eclipse plug-ins, because it can reuse the PDE build infrastructure, that handles all kinds of versioning information already present in the manifest.mf/plugin.xml files. When using Maven, this information has to be duplicated (AFAIK). If you don't develop Eclipse plug-ins, and are already familiar with Maven, then Buckminster will offer no real advantage, especially considering the steep learning curve. On the other hand for building Eclipse plug-ins it offers better ot-of-the-box support.

You can extend Buckminster by writing new readers (to obtain source from other locations) or new actors (that provide build steps - these actors can reuse Maven or Ant, thus providing extra functionality).

Wrasse

Answer 5

I wonder why nobody mentioned Tycho. Tycho has been proposed as Eclipse Project and now in Incubating Phase.

I tried to get along with Buckminster but I will now have a look at Tycho. This has the following reasons:

• As mentioned the documentation of buckminster is really bad.
• Actually I never got one of the buckminster examples running.
• I know Maven and the documentation is IMHO better than buckminster's.
• I want to use an build server (Jenkins) and the integration of Maven is quite good.

I have no experience at the moment with Tycho, but it seems promising.

Sherysherye

It seems that Tycho is a maven based set of tools for creating eclipse plugins. It is not really relevant because it is a specific application of maven, while buckminster is a general build system. – Frannie

Yes, that's right Dave. Tycho is indeed a maven plugin. I wanted to be sure to mention it, because is quite new. – Sherysherye

In my mind tycho has the same problem like maven - it will be solve one version for one dependency. You can't depend on version A and version B in the same build. But in a osgi environment sometimes it is needed. So i am looking for a generic build system. (In the last time i have worked with maven and tycho and its worked fine for standard cases). Now my hope is currently buckminster and b3 or buildboost. – Thermic

Answer 6

My (extremely limited) understanding of Buckminster in a nutshell is that it is a system for versioning and sharing Eclipse project configurations for a set of projects among team members. It does seem to overlap with Maven in that it manages dependencies, but I think these are Eclipse project level dependencies and not java dependencies.

I would personally not want to tie my build process to Eclipse or any other IDE. There are a lot of benefits to being able to perform a full build from a command line tool without the need for an IDE or some other GUI tool.

The free O'Reilly book Maven: The Definitive Guide is superbly written and really fills in the Maven documentation gap.

Lung

While Buckminster implementation is tied to Eclipse, it is not in any way tied to the Eclipse IDE as a build system. Out of the box, Buckminster recognizes Maven projects, Eclipse plug-ins and you can add metadata to your plain java projects so any java project, thus allowing you to build anything – Managing

"Maven: The Definitive Guide" was split into two separate books a few years ago. See blog.sonatype.com/2010/01/… – Interrelated

Answer 7

Due to lack of buckminster documentation I created an example of a Building Products with Buckminster/Hudson. This may help to get started, also works with Jenkins.

I used Ralf's tutorial to get an good overview about the topic.

Target Platform

How to setup Hudson and Buckminster can be read in Ralf's tutorial. Little tip, to prevent OutOfMemoryErrors, add -Xmx1024m to the "additional parameters" of your Buckminster installation (see troubleshooting tip Hudson out of memory).

I have a separated free style job to publish my target platform for other jobs. In the "Source-Code-Management" section I checkout the feature which contains my target definition (in my case ch.scodi.client.site).
To actually resolve the target definition, I added a build step "Run Buckminster" with the following command:

importtargetdefinition -A '${WORKSPACE}ch.scodi.client.site/TargetDefinition.target'

In the Post-Build-Action checked "Archive and publish an Eclipse Target Platform" and added .metadata/.plugins/org.eclipse.pde.core/.bundle_pool as path.

Consider that the TargetDefinition can not resolve directory locations. My target definition used to have a directory location containing bundles from the springsource repository.
I tried using the rmap file to get the bundles during materialization but had some trouble with that, so I decided to create an own update site for those bundles and add this site to the target definition. More on that can be found here:
http://www.eclipse.org/forums/index.php?t=msg&th=164508&start=0&

Building the Product

After the target definition job is run, we can start building the products.
This is pretty straight forward, see Ralf's tutorial on how to checkout your source from SVN.
I have three different builds for each, server and client product: Integration, Nightly and Release.
For each build the plug-in qualifier should be different (e.g. I20100326-2, N20100326, R20100326-01). To accomplish this I installed the flowing plug-in:
http://wiki.hudson-ci.org/display/HUDSON/Version+Number+Plugin
In the integration job I choose "Create a formatted version number" name it "version" and use something like this I${BUILD_YEAR, XXXX}${BUILD_MONTH, XX}${BUILD_DAY, XX}-${BUILDS_TODAY} as format.

To finally build the client product I added a Buckminster build step, selected the previously published target platform and used the following as commands:

import '${WORKSPACE}source/scodi-rcp/features/ch.scodi.client.site/site.cquery'

build

perform -D target.os=* -D target.ws=* -D target.arch=* -D
qualifier.replacement.*=${version} ch.scodi.client.site#site.p2.zip
perform -D target.os=win32 -D target.ws=win32 -D target.arch=x86
ch.scodi.client.site#create.product.zip perform -D target.os=win32 -D
target.ws=win32 -D target.arch=x86_64
ch.scodi.client.site#create.product.zip

Notice qualifier.replacement.*=${version}, this tells Buckminster/Eclipse to use my formatted version as qualifier and results in plug-ins named like this com.softmodeler.model_1.0.0.I20100325-3.jar, requires that Bundle-Version: 1.0.0.qualifier is defined in the bundle manifest.

http://flaviodonze.blogspot.ch/2010/03/building-products-with.html

Overtire