views:

1818

answers:

5

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

+4  A: 

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!

Ben Hardy
A bit late, but here'e a good book for maven http://www.sonatype.com/books/mvnref-book/reference/public-book.html
crowne
+2  A: 

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.

Ken Liu
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
Roland Tepp
thanks for the clarification!
Ken Liu
+1  A: 

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

Zoltán Ujhelyi
+2  A: 

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

Henrik Lindberg
+2  A: 
Thomas Hallgren