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:
After doing that, you will need to add the following to the build->plugin section of your pom.xml file:
You probably heard we have been moving into a faster release cadence with the new mountain ranges releases in this post and this one. For many Product Managers or Business Owners releasing faster could be the difference between success and failure. Being able to shorten the cycle between an idea and valuable user feedback enables new companies to understand better market needs and improve based on it. Releasing valuable software earlier is the sweet spot for Agile and Lean methodologies.
Mule is already running on premise and in the cloud and is soon bound to run virtually everywhere thanks to a new project called Anypoint Edge. This initiative not only focuses on allowing Mule to run on lightweight platforms, like the Raspberry Pi, but also to support protocols and devices relevant to the embedded world, like MQTT and Zigbee. The “Internet of things” had its rabbit, it’s now going to have its Mule!
If you follow this blog, you may remember that we’ve already discussed MQTT before. We’ve introduced the Mule connector for this lightweight publish/subscribe protocol with an example where MQTT was used in the context of conference booth QR Code scanners. In this post, we’re circling back to this example but we add a new twist to it: we’re taking it to the Edge!
In the original architecture, Mule was running on a laptop, using its webcam to scan QR Codes but now that Mule is able to run on the Raspberry Pi, we will revisit the example to run on this tiny device. We will also use the brand new blink(1) connector, which will allow us to use this smart USB RGB LED to flash a visual confirmation when the scan correctly happened.
So let’s start by reviewing our architecture diagram and let’s unroll the example from there.
When we started thinking about the August 2013 release we decided to take it one step forward and make it easier than ever. And now that Mule 3.5-andes is available on CloudHub, you’ll be able to leverage all these improvements into your integrations. On Premise users will also be able to use when the final version of Mule 3.5.0 is released as GA.
In the Internet of things no device is an island. And while Raspberry Pi devices are pretty cool on their own adding an API makes them a lot more interesting. We have been playing around with Raspberry for a while now and have a small distribution of Mule, called ‘Anypoint Edge’ that happily runs on small embeddable devices like the Raspberry Pi. These ARM-based devices are taking the world by storm since they are lower powered, low cost and can be embedded into small hubs to control other things like lightbulbs, or be used inside anything from PoS kiosks to gas pumps to cars to medical devices.
I just read yet another amazing achievement in the world of 3D printing: directly printing sand-grain-sized rechargeable batteries. It’s not that manufacturing things at that scale is revolutionary any more, it’s that we can see the path to mass accessibility: anyone will soon be able to do this. Just like desktop publishing, and later the web, and later any of a slew of self-expression and DIY-distribution possibilities like Facebook and YouTube and Twitter, that accessibility and enablement will surely create Yet Another Revolution (TM). No doubt.
There’s a saying that goes something like: to err is human, to really screw up big time takes a computer. But if you really want to have some fun, connect that computer to another computer, and you soon have a veritable nuclear chain reaction. The key to unlocking this energy? The lowly API, a programmer’s best friend, the little enabler that placed Google Maps in the center of mashup mania, drove the Ajax revolution, and is now generating over half of SalesForce.com’s revenues.
In a recent post, James outlined how MuleSoft is using Lean Startup principles to build Enterprise Software. We have been doing this for a while in our cloud platforms – CloudHub, Anypoint Service Registry and Dataloader.io; however, our core enterprise tools and products – Mule ESB, Mule Studio, Anypoint DataMapper, and Mule Management Console have always been on a much longer release cadence. Mule ESB Enterprise is the core platform on which many of our customers build hundreds if not thousands of services and integration processes on, so frequent releases and updates can be expensive for them to consume. Typically we release new Mule ESB enterprise versions every 9 months. As a hybrid product company with multiple products, we need to manage the demands of both the cloud and on-premise. Recently, we decided to make some changes to our development cycles and team orientation. We’re using names of famous mountain ranges for these new releases, the first is named Andes after the iconic mountain range in South America (relatively) close to our development labs in Buenos Aires, Argentina. The next is Big Horn, Cascade and then Dolomite.