This is second in series of how to DevOps articles, and is a follow-up to the MUnit blog – HowTo(DevOps) – Leveraging MUnit For Test Automation.
A core component of the continuous integration process, that includes the previously discussed test automation framework, is the build process. As soon as the developer commits the code to version control repository, the build tool compiles the source code runs unit and integration tests and generates feedback for the developers.
Interested in learning more about how to use Anypoint Platform? It’s time to get that dust off your running shoes because we’re going to get you in top MuleSoft shape. There’s nothing like having something extra to add to your learning routine, whether it’s helpful tips from our forum or challenges from the Champions Program, we’re growing the number of resources for you to become an Anypoint Platform expert.
For a while now there have been maven archetypes for creating mule apps and domains. Such archetypes make getting started with development easier by automatically generating the basic core structure and files of mule projects (think configuration files, test classes, pom). This is especially interesting since the introduction in 3.5.0 of shared resources through mule domains which could make your app depend on another external project (a domain) and using Maven to manage dependencies makes perfect sense. We will see how to use these archetypes to create a domain and an application that uses it.
If you’re a Mule user, there’s a good chance that you’re using Maven to automate building and testing of your applications. We’re happy to announce Mule Maven Plugin 2.0, to help you automate your deployment and integration tests. This plugin will help you no matter where do you want it to run: CloudHub, a local Standalone server, Anypoint Runtime Manager, a local cluster or using the Mule Agent.
I get the awesome opportunity to work with lots of MuleSoft developers. Today, many are venturing into the brave new world of connector development. I find a new connector developer’s first steps into this realm can be challenging. My hope, with this blog post, is to identify some of those common gotchas in connector development with Anypoint Connector DevKit. I won’t spend much time on implementation here. Let’s instead ensure the pieces are in place to make your implementing smooth.
Gradle is gaining more and more popularity as a build system. It combines the power of scripting with the simplicity of conventions. Declarative builds are very straightforward, where customizations do not end up in tons of messy configurations.
Currently, Mule has two ways of building projects:
- Apps can be built through Mule Studio, which is simple by nature but not very friendly with continuous integration, source control management and related tools.
- The recommended way to manage your build is with Maven and the Mule Maven plugin. This plugin is integrated with Mule Studio and has a lot of power on its own.
Now the open source community has presented a brand new way of building Mule apps with Gradle. The project aims to provide a very simple way to build Mule apps that is friendly with continuous integration and can work easily with Mule Studio. One of the interesting things about Gradle is that it can reduce over 90% the complexity of the build if we compare it with the same build based on Maven.
Suppose that you have a Maven project and you want to download Node.js modules previously uploaded to NPM. One way of doing that without running node is by using the npm-maven-plugin. It allows the user to download the required Node modules without running node.js: It is completely implemented on the JVM.
First of all you will need to add the Mule Maven repo to you pom.xml file:
As you probably already heard we launched Mule iON this week. If you ask one of our marketing guys what iON is, he will tell you that is the first cloud-based integration platform. iON will enable you to integrate popular SaaS applications, cloud services, social media, and a lot more without requiring any infrastructure.
Of course, I’m not a marketing guy, I’m a software developer. So my description is: “iON is awesome. It’s Mule on the cloud, and you are totally going to dig it”. Also, since I’m a software developer, I will put my money were my mouth is and I will show you how to build something incredible in a couple of minutes. Thats right! A few minutes and thats taking into account your learning curve of Mule iON.
In order to use the hot deployment feature that was introduced with Mule 3 you need to package your application as a zip file.
If you are using Maven to build your Mule applications then packaging zip files for hot deployment is very easy. All you need is to declare your packaging to be Mule: