Believe it or not, Java developers don’t consider build tools to be the most interesting topic out there. They are generally not considered the most exciting segment of any developer’s overall utility belt.
After all, the majority of the dev world still chooses between just two build tools, Maven and Ant, the latter of the two having been created nearly a generation ago. At best, programmers would prefer their build tool remain invisible and stable; at worst, we hear complaints of downloading enormous libraries, scripts failing for no reason due to some invisible rule running in the background, and general annoyances.
However, build tools should still be able to rock, and it’s in the spirit of “Build Tools [Can] Rock!” that RebelLabs has set out to finalize our journey into the realm of Java’s three most popular build tools–Maven, Gradle and Ant (along with Ivy for managing dependencies). After all, if anyone was going to try to put it a little “sexy” back into Ant, it would be us ;-)
Java Build Tools: Part 1 – An Introductory Crash Course to Getting Started with Maven, Gradle and Ant + Ivy
Build tools are an integral part of what makes our lives easier between checking code in and testing your product. Love them or hate them, they’re here to stay so let’s first take a look at what they are, how they emerged and why they are both hated and revered today.
Get ready, RebelLabs is doing a technical report on Java Build Tools….
Historically, developers compiled and linked their code through running compiler commands through terminal. Most of these commands were pretty much the same at the time, so they decided to create special “build tools”, that could save developers some time typing commands. As you can probably guess, it’s not reasonable to use the command line if you have many source code modules and they should be compiled and linked in a particular order.
Introduction to Chef
In previous posts we discussed the benefits of having automated environment provisioning & virtualization and how to get started with Vagrant. We also mentioned how this topic relates deeply to the technoculture of DevOps, which focuses heavily on automation, reusability and iterative improvement with regards to building and releasing software.
So let’s get started with Chef, which helps you turn environment provisioning into an automated process, making it not only more reliable and error-proof, but saving loads of time and headaches.
Jenkins just keeps getting better. The world’s favorite build master becomes more mature with every year, and there more and more plugins to choose from–over 600 now and growing.
It’s been quite a while since the last post on our top 10 favorite Jenkins plugins/features, which was so popular that we even created a 50-page RebelLabs report on the same topic: Jenkins CI: The Origins of Butlers, Build Masters and Bowties and included an insightful interview with the man himself, Kohsuke Kawaguchi.
So it seems like a good time to revisit the myriad of plugins to see which new ones have been written and which new features have been introduced. Spoiler alert: Of all the plugins we covered, the Git plugin for SCM was the most frequently installed…
Jenkins. The build master in a bow tie that we’ve all grown to rely on. In this new report from RebelLabs, we’re all over Jenkins like brown on rice, or like JRebel on your classloaders.
In Jenkins CI: The Origins of Butlers, Build Masters and Bowties, we looks at all the angles in Jenkins, covering some history, our favorite features & plugins and even show you how to build Jenkins pipelines the ZeroTurnaround way–plus, we have top it all off with an exclusive interview with our friend Kohsuke Kawaguchi, the originator of Jenkins.
I was brainstorming in the shower the other day, and I thought “Eureka!” – I need to bootstrap and test my Java app on a dynamic cluster with 800 Tomcat servers right now! Then, breakfast.
Obviously, every now and then you need to build a dynamic cluster of 800 Tomcat machines and then run some tests. Oh, wait, you don’t? Well, lets say you do. Provisioning your machines on the cloud for testing is a great way to “exercise” your app and work on:
- Warming up: Bootstrap a clean slate, install the software, run your tests
- Checking your Processes: Smoke testing for deploying the app to production
- Ensuring success: Checking load handling before launching the application to real clientelle
- Leaving nothing behind: After you’ve got all green lights, shut it all down and watch it disappear
So I’ve been developing a Jenkins plugin for a whole week now, and the first few days were really tough for me – the turnaround time is just awful! At one point, I decided to make the effort to configure JRebel for this task (which is pretty easy for me, being on the JRebel team). What follows here is a quick guide for getting started developing Jenkins/Hudson plugins using JRebel. So let’s go!
The first step is to prepare your environment. Keep in mind that this is Jenkins/Hudson-specific, and you need to consult their Setting Up Environment page.
Once you have your environment setup you can create your plugin, but right now this is just an empty skeleton version.