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: , , ,

ClassNotFoundException When Executing JUnit Test Runner In Eclipse With M2Eclipse


Running unit tests in Eclipse with Maven tooling can be a little tricky as the JUnit plugin for eclipse is expecting to find all of the compiled classes under target/classes.

This would be fine, except that the JUnit plugin simple tells Eclipse to build, which invokes the Maven builder (which is called by m2eclipse plugin of eclipse) to build, which only goes through Maven’s compile phase – meaning it only compiles regular source files – not test files.

This is kind of a miss by the folks who wrote the m2eclipse plugin as they should have added an additional builder for Eclipse that would kick off the compiler:testCompile goal which does compile the test files – but alas, it’s not my plugin.

Anyway, for the JUnit runner to work correctly in Eclipse we need to add an additional builder to each project that we want to run tests. This builder will invoke maven in a separate step of Eclipse’s build process to compile the test classes before JUnit executes.

Follow these steps:

  • Select he project to configure and alt+enter to open its properties.
  • Select Builders
  • Click New to bring up the configuration type dialog.
  • Select Program and then click Ok

This brings us to the launch configuration properties dialog which we need to fill out to create the launch configuration.

  • Enter Maven Test Compiler for the Name property
  • Location refers to the executable that you’d like to run. This needs to point to your mvn.bat file
  • In Working Directory, click on the Variables… button and select project_loc and then click Ok
  • Under Arguments enter – wthout the qutoes – “compiler:testCompile”
  • Go to the Build Options tab, and make sure that the check boxes under Run the builder are selected for all except During a “Clean” and then click Ok

This should take you back to the project’s properties. You can now select Ok and happily enjoy running the eclipse JUnit test runner!

Tags: ,