Pains with Fuse / ServiceMix


Ok, so I’m just starting out with ESB’s – crazy I know for as long as I’ve been at java development (over 10 years). To be totally honest, I was never really able to wrap my head around exactly what they can do for you – the definitions being so ambiguous that it really just sounded like a marketing ploy.

Anyway, the light has kind of gone off for me and I decided to delve into some open source ESB stacks like ServiceMix, OpenESB, and Fuse. Needless to say there were quite a few new concepts, as well as technical hurdles, that I needed to overcome in order to get a simple test running. All in all about 3 days work. “Three days!”, you say to yourself, “This guys gotta be a nimrod”. That wasn’t wholly the case (well, maybe partially). If you know how I work and digest things you’d know that just getting something to work simply isn’t enough. I actually like to know how things are working internally. Why does this do that, what makes that kick off, what exactly is MEP, JBI, and DSL. What’s the NMR and how does it work – that kind of stuff.

I settled on Fuse, which is really an enterprise supported edition of Servicemix, because it seemed to adhere to all the standards I wanted to follow as well as providing what appeared to be pretty decent documenation – at least as decent as open source documentation goes. I dug in, did my research on the different technologies involved and their interactions. As it turns out, the documentation was spotty and a few versions behind (gasp!) – so there I was, off and digging.

As it turns out, they have nifty maven archetypes for just about anything that you want to create. Simple SU and SA assemblies for ServiceMix / Fuse as well as other types of artifacts. Seems pretty easy and well put together… until the above bit me. Everything is out of date – from the documentation to the archetypes, which makes them not so handy for a variety of reasons.

Although the archetypes are moderately helpful for creating the basic project structure and the poms, they were completely useless in actually building a working project. The plugin tooling was the wrong version, the dependencies for the binding components were incorrect, and even worse – there is nowhere, and I mean nowhere – that the correct versions of all the dependencies are listed in order to fix the issue. Not outside of trial and error anyways – which is just not practical considering the sheer number of BE’s and BC’s that exist.

So I did some snooping around the examples and the dark recesses of the distribution. As it turns out they did a nice job of pom inheritance in their examples. And this is what led me to a resolution. If you follow the pom inheritance change up to it’s root from one of the examples you come to the master pom. In  which, and thank you so much SMX/Fuse contributers, they have a dependencyManagement section which lists all of the possible dependencies for the BC’s and BE’s!

Now that I figured out all the correct versions of everything the only thing left to due was to create a master pom for my purposes that included that dependencyManagement section. Why didn’t I just use it as my master pom? There was way too much SMX/Fuse specific build process in it and it was just easier to strip out what I needed rather than molding my process to fit theirs.

So there you have it – simple, huh? I’m now off an building service assemblies sans issues like a champ.

Hope this helps someone out there save a few hours of research!

Well, like a champ apparently was a little premature. More issues have arisen due some xbean issues, which again, I’m trying to scour the internet and figure out. Not that I can’t get things to work, just that they aren’t working the way I want them to work…

Tags: , , ,