netzooid

Now that we’ve got XFire 1.0 out, I thought I’d write some thoughts on Maven 2. We switched to Maven 2 right before our release candidate, because the multiple Maven versions were causing user confusion. People would look at our samples and try to use them with M2, but they were written in M1. Since M2 has the idea of transitive dependencies, which wanted to produce valid M2 poms with our project so our examples could take advantage of that.

To give you some idea to the size of our build, we have around 10 different modules which produce

• Individual jars for each module
• A bundled jar of all the modules (but not their dependencies)
• A distribution with the bundled jar, the individual jars, the javadocs, the manual from Confluence, and select dependencies.

There was some definite advantages in switching:

• Our example poms ended up being quite a bit shorter because we only needed to declare a dependency or two and the rest were brought in automagically by Maven.
• Builds were a fair amount faster.
• The release:prepare goal rocks. It updates all the versions of your poms to the released version – say 1.0, then checks it in to cvs and tags it. Once thats done it updates the poms again to the snapshot version – say 1.1-SNAPSHOT, and then checks them in again. Very cool.

But I ran into several issues as well:

• We create a bundle jar which contains all the XFire modules called xfire-all. The assembly plugin can’t do this right now so I had to write a MOJO to do this. While it wasn’t horribly hard, it was a bit of a PITA. Overall the assembly plugin needs some lovin to become really useful.
• Maven is really really rigid. You must conform or use something else. While doing another M2 build I couldn’t find a way to optionally skip the generate-test-resources phase which downloaded a 6MB jar. There are certain times you don’t want to do that and just run Maven with -Dmaven.test.skip
• Transitive dependencies really started to get on my nerves. There is no way to declare that a dependency is needed for compiling and testing, but shouldn’t be included by default on the classpath with transitive dependencies. So things like Jetty or HTTPUnit are automatically pulled in via XFire’s transitive dependencies despite my feeble attempts.
• While release:prepare worked great, release:perform didn’t. For some reason our build froze when doing a release:perform, although I haven’t been able to track down why yet. I suspect its some bad interaction with our unit tests and surefire.
• Building a distribution was the hardest part. There is no way to build a master javadoc of several different modules so I had to do that with Ant. I also had to do some hacks to make sure certain jars weren’t included in the distribution by the assembly plugin.

I go back and forth on M2, but I think overall it was better than if I had done the project in Ant. Give Maven a little more time though and I think it could really start to be killer. Really my gripes just focus on the assembly & release plugins, and they are aware of these issues and will be fixing them I’m sure.

Interesting tidbits from the Microsoft people going around on queued messaging. Clemens Vasters starts it off talking about how WS-RM != durable:

There is no rule saying: “the received message MUST be written do disk”. WS-ReliableMessaging is as reliable (and unreliable in case of very long-lasting network failures or an endpoint outright crashing) and plays the same role as TCP. The mapping is actually pretty straightforward like this: WS-Addressing = IP, WS-ReliableMessaging = TCP.

And Shy Cohen weighs in on whats happening with WCF and queued messaging:

Reliable sessions are implemented using the WS-ReliableMessaging protocol. This protocol is yet another misnamed WS-* protocol, as it actually only deals with the reliability of the transfer and says nothing about durability, delivery acknowledgments, TTL for a message, long running sessions where a particular message is lost forever, etc. Currently, there is no active work going on to develop an interoperable Queued Messaging specification, but I expect that we will get to it in the near future….

We do hear what folks are saying though, and we are actively working on a set of features that will allow Queued Messaging implementations to leverage WCF’s WS-ReliableMessaging implementation. With this feature set you’d be able to “bring your own durable store� and have an interoperable Queued Messaging channel that fits nicely and naturally into the WCF architecture.

Finally Dave Chappell discusses why there is no spec quite yet:

I have no first-hand knowledge, but it’s easy to imagine that IBM isn’t too keen on creating web services standards in this area. WebSphere MQ holds a commanding share of this market, and so it would be understandable if IBM wasn’t enthusiastic about creating another WS-* spec that commoditized queued messaging. Still, without interoperable queued messaging, web services-based SOAs will be limited in significant ways.

Mmm more design by committee. I hope it turns out to be as swell as WS-RM!
It’ll be interesting to see how popular something like this would become. I think most people are going to opt for the transport level reliability like JMS or something like it. With ActiveMQ working on both .NET and Java, I think SOAP over JMS makes a lot more sense in those situations.

Steve: The most poignant metric of interop problems is how Sun and Microsoft are so proud of collaborating so that their SOAP stacks will work together. Why don’t you see the same vendors getting together to demo Http client/server or Xml Parser interop? Because if you were that incompetent, people would notice. Also its because Apache, in the form of commons-httpclient and Xerces fixed the problems for Sun.

First – Hahahahaha!

Second – In that post Steve outlines a bunch of reasons for interop problems with SOAP+XSD+WSDL+WS-*. Do people think there is a market for a non-xsd, non-wsdl xml messaging solution? Think SOAP+RelaxNG+SomethingBetterThanWSDL+WS-*.

Don Box has an excellent post on making design choices for your web service. If you are contemplating REST vs SOAP vs Whatever, be sure to read it.