Dangers of mixing artifact versions across maven modules

Sometimes when a quickfix is urgently required, we are tempted to branch off and make it happen on our own until the authors of the original branch release their latest version. I found myself in such a situation and decided to only use the patched version for a small~ish maven module/artifact known in my project as "commons". What could go wrong? Well I ran into the following error at runtime:

java.lang.NoSuchMethodError: org.springframework.amqp.core.AmqpAdmin.declareQueue(Lorg/springframework/amqp/core/Queue;)Ljava/lang/String;

Turns out that my "commons" module was expecting to use a slightly different method signature than what was available in my main project:

// method signature from spring-amqp-1.3.0.BUILD-SNAPSHOT
String declareQueue(Queue queue);

// method signature from spring-amqp-1.2.0M1
void declareQueue(Queue queue);

So ... lesson learned :) push the authors to release quicker ;)

Maven plugins & extensions for working with WSDLs, XSDs and POJOs

My favorite plugin for generating a webservice from a WSDL file (WSDL-first-approach) is Apache CXF because it loops in Spring, JAX-WS and other standards and implementations to make it happen.

Before CXF became by BFF I had gone looking for a maven archetype/template that would bring everything together for me in Eclipse. I did some templates but none that used the WSDL-first-approach to generate a sample project for me. So I gave up on looking for archetypes and instead followed a mix of instructions from the following links:

• http://joemorrison.org/blog/2008/10/23/cxf-wsdl-first/
• https://mvnwls.wordpress.com/2011/02/01/contract-first-cxf/

Anyway, CXF is awesome for the following reasons:

• It is easy to configure cxf-codegen-plugin for generating a Java webservice code from a WSDL file.
• It is easy to configure cxf-xjc-plugin for generating POJO (plain-old-java-objects) classes from a XSD (schema) file.
• Other maven extensions can be used to enhance the cxf-xjc-plugin's schema to POJO conversion process:
• Lets say you want to use something like a builder-pattern which makes your written code more beautiful. You can do that by configuring the jaxb-fluent-api extension!
• If some of your POJOs share the same methods then not being able to categorize all those POJOs under a common interface can lead to duplicate code. For example, lets say you have a method named: performCommonTaskOnIncomingObject(ClassName argument) ... now you may need to have multiple such method with different names because you'll need to change the argument's classname everytime to match the object you're passing in!
• So can we get the code-generator to implement interfaces on POJOs for us without messing with the schema? Yes!
• Just configure the jaxb2-basics's inheritance-extension as you see fit.