How to patch a subcomponent in a maven-managed framework?

Question

I need to patch the mule-transport-jms subcomponent of mule for this bug (http://www.mulesoft.org/jira/browse/MULE-3983). The "fix" is straightforward but what is vexing me is deploying the patched component to my local maven repo (managed by Nexus) and having it continue to play nicely with all the other components of mule.

What I want is to label my newly patched mule-transport-jms as version number 2.2.1-patched, and have my esb components depend on that as well as the other mule components (eg mule-core) which are still set at version 2.2.1. Because the mule-transport-jms pom reads (in part) like this:

<parent>
    <groupId>org.mule.transports</groupId>
    <artifactId>mule-transports</artifactId>
    <version>2.2.1</version>
</parent>
<artifactId>mule-transport-jms</artifactId>
<packaging>bundle</packaging>
<name>JMS Transport</name>
<description>A Mule transport for Jms Connectivity.</description>

there are many interdependencies that rely on the version being 2.2.1. Changing the parent version (as shown above) to 2.2.1-patched breaks everything, adding a version tag so that it looks like this:

<parent>
    <groupId>org.mule.transports</groupId>
    <artifactId>mule-transports</artifactId>
    <version>2.2.1</version>
</parent>
<artifactId>mule-transport-jms</artifactId>
<version>2.2.1-patched</version>
<packaging>bundle</packaging>
<name>JMS Transport (ZFP patched)</name>
<description>A Mule transport for Jms Connectivity.</description>

breaks a number of dependencies that are presumably declared in the parent's pom (no mention of those failing dependencies anywhere in this project).

I can probably hack Nexus to always retrieve my patched version when mule-transport-jms v2.2.1 is requested, but that's dirty. I'd really like to be able to just specify exactly which GAV to use in my client pom, and when it's time to upgrade (assuming the bug gets properly fixed in v3.0, say) just update my client pom to point to version 3.0.0 and my patched, 2.2.1 jar just gets ignored, and no hacking of nexus is required. Obviously I'd also like to avoid checking out every mule component and updating their poms and redeploying them all as 2.2.1-patched.

Any thoughts?

Answer 1

You should be able to set the dependency on the patched version of mule-transport-jms in your pom explicitly. Because it is closer than the standard version it will override the standard version and yours will be used. You might have to add the dependency into a plugin declaration. This blog post describes how to configure a plugin with a dependency.

If this doesn't work, could you provide a little more information on how you need to use the patched version?

Answer 2

Applying your patch and rebuilding the whole mule-transport as version 2.2.1-patched is probably the best solution. But I have no idea on how much effort (I mean build time) this represents.

The other option would be indeed to build a patched version of the mule-transport-jms module and the projects that depends on it only. To easily find those projects, you could use the reactor to identify the dependent projects:

• if you are using maven 2.0.x

  $ mvn reactor:make-dependents -Dmake.folders=mule-transport-jms
  

• if you are using maven 2.1+

  $ mvn -amd -pl mule-transport-jms
  

Then update the pom of those projects to point on the patched version of mule-transport-jms and repeat the maven command to build them.

I just don't know if this will be less time-consuming than an entire build or not.

Answer 3

This is really just a maven question, not Mule's. The correct approach is not to have a 'hacked' version, but rather another version in the repo with a qualifier (just like you did with 'patched'). Next, inspect maven's transitive dependencies (use mvn dependency:tree & dependency:list goals) and ensure that:

1. The patched dependency is declared and used, and
2. The original non-patched dependency is excluded from the dependency graph.