Last week I optimized the deployment process of a number of Mavenized projects. I noticed that the way I automated the project was not yet (fully) known by the developers. This is why I decided to write this blogpost.
It appeared to be a true eyeopener for the developers.
Earlier, we blogged about generating JAXB classes based on XSD files. However, sometimes we need multiple configurations with multiple XSD files. Previous blog posts did not cover this topic, so I thought I’d cover it in a seperate post.
The solution is to add multiple executions for the maven-jaxb2-plugin plugin. Each execution is bound to the generate-resources phase of the Maven build process. Now, each time the project is build, the executions kick in and the JAXB classes are generated.
Today I created a Maven module which holds our integration tests. The disadvantage when holding these tests in your ‘normal’ Maven modules is that the tests are fired every time the module is built (by you or your continuous integration server like Hudson). Since these tests take rather long to execute, developers tend to use the ‘skipTests=true‘ option when they build the code, which is taking away a great part of one the main reasons why you should use Maven. See also this article for more info about this subject. (more…)
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. (more…)
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 (more…)
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.
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).
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. (more…)
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.
(more…)
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. (more…)