Mule : How to share the same mule project between a JBoss AS and a CE runtime? - eclipse

Question

The objective I have is to develop a bus with Mule, to run it into a JBoss.
My IDE is eclipse kepler, I have the Anypoint Studio plugin installed, a JBoss 7.1.1, a 3.5 CE runtime, Maven etc etc.
I took a look a this page : Deploy War into Mule Standalone server but I don't see haw it could help.
Context :
- Jboss is an imposed choice. I know it exists an EE version of the runtime, specially for the HA ability (that I need), but it's not an option for my client.
As it's "easier" to test my flows on the standalone (CE) runtime, I wanted to find a way to develop one Mule project to execute it on a CE runtime during the developing phase, and on a JBoss AS during the integration phase.
To do that, I tried to define :
- a jar maven project which contains all the flow
- a "mule" maven project, with the previous jar as the dependency
- a war maven project which athe previous jar and all the module/transport mule jars as dependencies
When I build the mule zip, my jar is included inside, but when it's executed none of ny flew is registered. So it doesn't work.
When I execute the war on JBoss, everything looks fine for the "first" flow (the input one), but I have a crash when the second one is called using a VM connector (other issue, I'll make another request)
Is there a way to do something working with this approach?
I tried to define 2 pom for the same mule project (one pom which generate a war, and a standalone-pom which generate the mule zip), but this is not very "easy to use" for my team, as the eclipse integration of this kind of project is not very friendly.
The last thing I can try is to keep the mule project pom with a mule packaging, and add a maven assembly to build the jar I could include in my war, but I'd prefer a nicer solution...
Thanks for all of your ideas!
Ah, the test flew I'm trying to integrate.
I have 3 flew :
- The first one stands for the HTTP request (to call my CE runtime)
- The second one stands for the Servlet request (to call my JBoss)
- The third one is called by both my CE runtime and my JBoss input flow, throw the VM connector. I'm thinking replace the VM connector by a Flow Call, as the VM inbound-endpoint is not registered when it's embedded into my war (but it works when executed in a CE runtime...)
main file :
<flow name="muleFlow1" doc:name="muleFlow1">
<http:inbound-endpoint exchange-pattern="request-response"
host="localhost" port="8081" doc:name="HTTP" />
<echo-component doc:name="Echo" />
<vm:outbound-endpoint path="receiver"
exchange-pattern="request-response" responseTimeout="10000" doc:name="VM" />
</flow>
<flow name="muleFlow2" doc:name="muleFlow2">
<servlet:inbound-endpoint path="servlet"
responseTimeout="10000" doc:name="Servlet" />
<echo-component doc:name="Echo" />
<vm:outbound-endpoint path="receiver"
exchange-pattern="request-response" responseTimeout="10000" doc:name="VM" />
</flow>
second file :
<flow name="otroFlow1" doc:name="otroFlow1">
<vm:inbound-endpoint path="receiver"
exchange-pattern="request-response" responseTimeout="10000" doc:name="VM" />
<set-payload value="it works" doc:name="Set Payload" />
<echo-component doc:name="Echo" />
</flow>
Thanks !

Answer 1

I didn't find anything else, so I opted for an assembly descriptor...
<assembly
xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd">
<id>mule</id>
<formats>
<format>zip</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<fileSets>
<fileSet>
<directory>${project.build.directory}/classes</directory>
<outputDirectory>/</outputDirectory>
<includes>
<include>*.xml</include>
</includes>
</fileSet>
<fileSet>
<directory>${project.build.directory}</directory>
<outputDirectory>/</outputDirectory>
<includes>
<include>classes/**/*.class</include>
</includes>
</fileSet>
</fileSets>
<dependencySets>
<dependencySet>
<outputDirectory>/lib</outputDirectory>
<useProjectArtifact>false</useProjectArtifact>
<useTransitiveDependencies>true</useTransitiveDependencies>
<excludes>
<exclude>org.mule:mule-core</exclude>
<exclude>commons-cli:commons-cli</exclude>
<exclude>log4j:log4j</exclude>
<exclude>org.mule.mvel:mule-mvel2</exclude>
<exclude>org.mule.common:mule-common</exclude>
<exclude>org.mule.modules:mule-module-client</exclude>
<exclude>org.mule.modules:mule-module-spring-config</exclude>
<exclude>org.mule.modules:mule-module-annotations</exclude>
<exclude>org.mule.modules:mule-module-xml</exclude>
<exclude>org.mule.modules:mule-module-cxf</exclude>
<exclude>org.mule.modules:mule-module-spring-security</exclude>
<exclude>org.mule.transports:mule-transport-http</exclude>
<exclude>org.mule.transports:mule-transport-ssl</exclude>
<exclude>org.mule.transports:mule-transport-tcp</exclude>
<exclude>commons-codec:commons-codec</exclude>
<exclude>org.mule.modules:mule-module-spring-extras</exclude>
<exclude>org.mule.modules:mule-module-builders</exclude>
<exclude>org.mule.modules:mule-module-management</exclude>
<exclude>org.mule.modules:mule-module-scripting</exclude>
<exclude>org.mule.modules:mule-module-sxc</exclude>
<exclude>org.mule.tests:mule-tests-functional</exclude>
<exclude>org.mule:mule-core</exclude>
<exclude>org.mule.transports:mule-transport-file</exclude>
<exclude>org.mule.transports:mule-transport-jdbc</exclude>
<exclude>org.mule.transports:mule-transport-jms</exclude>
<exclude>org.mule.transports:mule-transport-servlet</exclude>
<exclude>org.mule.transports:mule-transport-vm</exclude>
</excludes>
</dependencySet>
</dependencySets>
</assembly>
My mule project is now a jar, which generate a jar file (for my webapp) and a zip file (for my runtime CE)
One important thing :
To realize the spring imports of each flow, we need to specify when mule is deployed in a web app, but the runtime expects to work. It can be done by creating a maven profile and enabling the resources filtering to determine when add "classpath:"...