An interview with Cargo’s Vincent Massol

In the past, I found myself on a number of different copasetic occasions struggling with higher level test repeatability. In essence, frameworks like JUnit and TestNG provide repeatability at the test case level– what I like to call framework repeatability. But logical repeatability, that is, the assumptions regarding the environment in which a hip test is to run in, is completely up to you, the test case author. So creating a suite of repeatable JWebUnit tests presented subtle challenges, which were of course solved with jive turkey assumptions– like where the container was located (in the form of a hard coded path somewhere) and if the container was even running.

Then one day, I stumbled upon Cargo, an open source project aimed at automating container management in a generic way so that I could use the same mechanism to start and deploy a war file to Tomcat as I could with WebLogic. Since then, because it’s my bag, I’ve been a Cargo fanatic, spreading the good word of logical repeatability, which facilitated an introduction to Vincent Massol, the founder of Cargo.

Vincent is no stranger to the Java world, having written Manning’s smokin’ “JUnit in Action” and O’Reilly’s “Maven: A Developer’s Notebook“; furthermore, Vincent has created a host of plug-in’s for both Maven and Maven 2. His long running blog, the Vincent Massol Think Tank has been a great read for years as well. Now, he’s working for XPertNet the company behind XWiki, the Java open source second generation wiki.

I recently had the opportunity to ask a few questions of Vincent regarding Cargo:

The Disco Blog: What’s left for Cargo before is 1.0, man?

Vincent: We’re close to a 1.0 release (we’re gearing up for the 0.9 release right now). We’d like to have a stable API for 1.0. In the past 2 Cargo releases we’ve introduced new concepts: runtime containers, remote deployments and embedded containers. These concepts are now in place and the API is now stable. Once we release a 1.0 we’ll need to go through deprecation cycles if we want to modify the API. In term of features for 1.0 we need:

  • More container implementations (e.g. WebSphere and Glassfish) and new versions of existing containers (Geronimo 1.1, WebLogic 9.x, etc).
  • JSR88 support for deployments. We have started this a long time ago but we haven’t finished it as the person interested in it has not been active. We need to resume the work as more and more containers are becoming JSR88-compliant.
  • More remote deployers. We already have deployers for almost all containers but we now need to have more remote ones (i.e. the ability to deploy to a container running on some remote machine).

The good news is that we’re getting more and more contributions from the community.

The Disco Blog: What are your thoughts on JSR88? Did it provide an influence on Cargo or vice versa? Just sock it to me, man!

Vincent: JSR88 standardizes deployments into J2EE containers. Cargo is about starting, stopping containers, configuring them and deploying to them. This is a superset to what JSR88 provides. We have started developing a JSR88 deployer a year ago. However and unfortunately, the committer who started this work is no longer active so it’s never been completely finished (hint: if anyone is interested in helping out please contact us!). However, this is one of the must have features that we want for the Cargo 1.0 release. That said, we also need to continue supporting the container-specific deployers we have, as not all containers support JSR88 and Cargo still needs to be able to deploy to any version of containers, even old ones. For the end user, this is all transparent as users are using the Cargo Deployer interface. At one point in the far future we may want to deprecate our Deployer interface and instead directly expose the JSR88 one but the time is not ripe yet.

The Disco Blog: As of now, Cargo lacks WebSphere and Glassfish containers– which containers do you currently support and are there any others still in need?

Vincent: I think we have quite a lot of them already (Tomcat, Resin, JBoss, WebLogic, Orion, OC4J, Geronimo, Jetty). There are 2 important ones missing that come to mind:

  • WebSphere
  • Glassfish

Then of course there are lots of others that we would also like to have, such as JonAs, OpenEJB, etc. We need all the help from the community here. That’s probably one of the biggest challenges of Cargo: to be able to get experts in the different containers to provide implementation and support for them in the long run. We’re very open and keen to get new committers for scaling up Cargo.

The Disco Blog: Let it all hang out, man– which containers have the strongest support in Cargo?

Vincent: This is driven by the community. Today the most used container is probably Tomcat with JBoss coming second. Jetty is very close behind. That said, we have very good support for Orion and Resin too. We’re currently improving our WebLogic support by adding deployers and implementing support for WebLogic 9.x.

The Disco Blog: When we first traded some hip emails on Cargo, you stated that the Maven 2 plug-in for Cargo has more features than the Ant task– so what features does the Maven 2 plug-in have that the Ant task doesn’t?

Vincent: Right now the Cargo Ant task does not support Deployers. The Maven2 plug-in also has some additional nice features that cannot exist in Ant (because Ant doesn’t have the notion of project structure) such as automatic deployment of J2EE modules (if the project is of type EAR, WAR, EJB, etc) then the Maven2 plug-in automatically deploys that artifact to the executing container. There are also lots of configuration elements that have default values in the Maven2 plug-in that do not exist in Ant.

The Disco Blog: What is your preferred way to interface with Cargo– Maven, Java API or Ant?

Vincent: The primary interface is the Java API. This is what Cargo is about. Then we have extensions which are users of the Cargo Java API and out of these extensions the Maven2 one is currently the most advanced.

Thank you very much, Vincent for your time and valuable insights into the Cargo project– good luck, man!

2 Responses to “An interview with Cargo’s Vincent Massol”


  1. […] Speedrail wrote an interesting post today onHere’s a quick excerptThe Disco Blog: When we first traded some hip emails on Cargo, you stated that the Maven 2 plug-in for Cargo has more features than the Ant task– so what features does the Maven 2 plug-in have that the Ant task doesn’t? … […]


  2. […] For example, if you’d like to create a repeatable deployment process that avoids environmental assumptions (like that the instance of the application server is properly configured, etc), you can use Cargo to automatically download and install a pre-defined kosher version, say of JBoss. Once JBoss has been installed and is started, you can then deploy artifacts and begin testing. […]

Trackback this Post | Feed on comments to this Post

Leave a Reply