After attending to Jason van Zyl’s session about Maven3 we decided to start using Maven 3 instead of the 2.2 we were using. Since it is fully backward compatible we made it run without making a change to our pom’s. However, what this version does add is generate warnings for all kinds of ‘misconfigurations’ in the poms. This does not lead to problems in this version but it might do so in future version, so it is better to solve this issues.
Continue reading…

For a new interface that we have to implement we have to transfrom a file with ‘character separated values’ to a XML message. One way to obtain this transformation is by using Smooks. Smooks is an extensible framework for building applications for processing XML and non XML
data (CSV, EDI, Java etc) using Java. Although Smooks can run standalone, we want to combine it with our integration platform that is based on Mule CE
Continue reading…

As I said before we were asked to check out the new Management Console of Mule. In this post I will show the steps I took to get the console up and running and the first results of the evaluation.

• The first thing I had to fix was the fact that the Management Console only works with the Enterprise Edition. Luckily there is a 30 days trial available of the Enterprise Edition here, so I started by downloading that one.
  Continue reading…

I knew I solved this problem earlier: I just didn’t know how I solved it. That’s just why wiki’s and blogs are invented.

The problem? One of the developers we’re currently coaching was getting started with the Mule ESB using the book Mule in Action .

When trying to run the Maven-based samples that came with the book, Maven wasn’t able to find the com.sun.jmx:jmxri:1.2.1 and com.sun.jdmk:jmxtools:jar:1.2.1 dependency. Looking at our internal repository, only the related pom.xml appeared to be there (and not the jar).

Continue reading…

I needed Mule to determine the outbound endpoint based on the content of properties in my custom XML message. Although this might look as common functionality I couldn’t find a complete example for this on the net. This one was close, but didn’t match completely with my situation:
I receive an XML message that is conform my own custom format. Based on the content of several fields in this XML message I determine what the next endpoint must be to process the message. Then my message is forwarded to that endpoint.
Continue reading…

In my current project we are going to need a BPEL engine besides our Mule CE implementation. Actually, we will use Mule for our stateless communication between systems and use BPEL for the stateful processes. One of the possible frameworks to use as a BPEL engine is Apache ODE. In this post I will show you how you can start a BPEL process in Apache ODE with Mule. As you will see, it is merely a combination of posts I made earlier, but I think it is nice to have the complete thing in one post.

Continue reading…

Some time ago I already explained how you could use Maven and the jboss-plugin to deploy your war or ear to your JBoss server. Now this works fine as long as your JBoss is a local installation running on the same machine as the one that is running Maven.
Of course there is a big chance that this is not the case in your development environment.
Continue reading…

Although I am using Maven for quite some time now over the last years I have never had the need to create my own archetype. Untill my current project. And luckily this is greatly simplified in Maven2.2.
The first thing to do is to create your ‘base’ module that you want to use as template for your other modules. When this is in place you simply go to the root of your base module and enter:
mvn archetype:create-from-project
After this has successfully completed you go to the directory ‘target/generated-sources/archetype’ and enter the command:
mvn install
And after that you can add the archetype to the catalog in your local repository with the command:
mvn deploy
Continue reading…

In my last post I told about the XSLT processing that I have to do to get the XSD as I wanted it to be. Unfortunately there is not just one XSD that has to be processed but there are actually several of them. And for every change in our CDM (Common Data Model) I had to perform all these transformations by hand. Now that doesn’t feel good so I decided to automate that process. And since we are already heavily using Maven I also wanted to do this with Maven, which actuallly is rather easy to do. I even added a validation step so I can test the created XSD at the same time.
Continue reading…

As I promised here this is the last part about using Maven2 to build, test and deploy an EJB3 application to JBoss5. In part 2 I showed how you can build and deploy your EJB3 application in JBoss. In this step I want to show you how you can (unit)test your EJB3 module before you deploy it to JBoss. In part 2 we had to deploy the bean first, before we could test it, but that is not the most optimal way. It would be nicer if the code is tested before it is deployed to the JBoss server. To do this, I make use of OpenEJB. This is a lightweight container that is very easy to use with Maven. Another advantage of this approach is that the EJB component is tested/used in two different EJB containers and reduces the possiblity that container-specific code is used in the application.
Continue reading…