Shared java project that depends on mule libaries

[gilbertg]

Hi, we have multiple Mule projects, and have created a shared project that contains utilities - some of which are dependent on Mule libraries. The Gradle file for this shared project look like this:

dependencies {
    compile project(':Shared')

    compile group: 'org.apache.commons', name: 'commons-lang3', version: '3.3.2'
    compile group: 'javax.activation', name: 'activation', version: '1.1'
    compile group: 'javax.xml.stream', name: 'stax-api', version: '1.0-2'
    compile group: 'log4j', name: 'apache-log4j-extras', version: '1.2.17'
    compile group: 'org.apache.httpcomponents', name: 'httpclient', version: '4.5'
    compile group: 'commons-httpclient', name: 'commons-httpclient', version: '3.1'
}

eclipse.classpath.file {
    withXml { provider ->
        def root = provider.asNode()
        root.appendNode('classpathentry', [kind: 'con', path: 'MULE_RUNTIME', exported: 'true'])
    }
}

As you can see, I've forced Anypoint Studio to reference the MULE_RUNTIME container. This is 100% - the projects are referenced as expected, and Anypoint does not try to treat the common project as a Mule app. This also runs and deploys 100% through Anypoint Studio.
Below is the project structure;

• esb is a mule project
• ESBCommon is our shared project with Mule-enhancing utilities
• Shared is a normal java project with no Mule dependencies

Problem comes in when we try to build through Gradle, the project (understandably) can't find any of the Mule dependencies. Can you suggest a way to include the Mule dependencies for the gradle build?

I'm trawling through your Gradle plugin, code, but suspect it will be some time before i understand enough of Gradle plugins, and the mechanisms of this project.

Thanks...

[juancavallotti]

hi! I was thinking on configuring it like a mule embedded project, however this will make your dependencies compile time, and you don't want that. So the only option I can think of, is to use the provided compile scope.

Having all mule dependencies as provided would actually be a good idea to build a project type to build mule patches or core extensions, however this is not something I officially plan to do.

Take a look at how I create the provided compile scope and you may get some inspiration.

Here:
https://github.com/mulesoft-labs/mule-gradle-plugin/blob/master/src/main/groovy/com/mulesoft/build/MulePlugin.groovy#L72

And here:
https://github.com/mulesoft-labs/mule-gradle-plugin/blob/master/src/main/groovy/com/mulesoft/build/MulePlugin.groovy#L96

[gilbertg]

hi Juan, thanks for the very quick response. So i just tried this:

configurations {
    providedCompile
    providedCompile
    providedCompile.visible = false
    compile.extendsFrom providedCompile
}

apply plugin: 'mule-dependencies'

Since your mule-dependencies plugin does use the providedCompile configuration when available.
This gets the Gradle build working (as in, i can compileJava on ESBCommon now), but breaks running the master mule app through - i.e. when i re-gen my .project and .classpath with gradle cleanEclipse eclipse, and try to run my app.

My problem is, i don't know how to tell gradle about explicit mule dependencies, since it was always hidden behind the mule plugin. Maybe inspiration i need it your mechanism for resolving Mule dependencies.

A nasty jack would be to use gradle-dependencies, and manipulate the .classpath thereafter, so Studio is not confused.

Included Studio's breakage log, incase you're interested.
Anypoint Studio Run App.zip