In My Toolbox: NetBeans

My favourite Java IDE, NetBeans, is not disappointing (again): it has the simplest and most effective integration with Gradle. To understand this, I’ll tell how the other IDEs fare with Gradle - according to my recent experience.

Eclipse

I could not make the Gradle plugin for Eclipse to work reliably. It may be that the project I was working on had strange features, I don’t know. But I expected to point Eclipse to the build.gradle file and the IDE to do the rest. To be sure, it did load the file but I could see no project content.

The solution that other Eclipse users employed? Using the eclipse plugin of Gradle to generate an Eclipse project. Fine, as long as you don’t have custom build steps. If you do, then you have to tweak mess up with the cleanEclipse and eclipse tasks to handle the peculiarities.

In other words, to develop a plugin. Hurray, back to Maven in Gradle clothing!

In addition, Eclipse was slow.

IntelliJ IDEA Community Edition

For a while, I could not setup the main runtime class for modules imported from a Gradle super-project (containing about 60 sub-projects). The reason: IntelliJ IDEA 16.1 changed behaviour (compared to version 15) and now it creates separate modules for the main and test directories of each sub-project. Thus I ended up with 201 modules instead of about 60 – with no possibility to run my apps because they could not find the main class. Obviously, this was a special case. I trust that in majority of situations the Gradle support for IntelliJ does work. But it didn’t work for me.

How do I know that was the cause? Switching to version 15 eliminated this strange effect and I could run my app. What remains of keeping with the latest version?

In addition, it seems that IntelliJ doesn’t use the Gradle files except at the beginning – when it generates an IDEA project behind the scenes and then it continues on its own. Also, IntelliJ was slow. 

NetBeans

In its good tradition, the NetBeans Gradle plugin just worked – even though it’s provided by the community. No fuss, no huss. I loaded the build.gradle file and it loaded the project with no problems – and it was fast, too. Very much like the most excellent NetBeans support for Maven.

As a result, I stopped struggling and I just switched to NetBeans to work on my Gradle projects. I still keep Eclipse and IntelliJ around, but the main tool remains NetBeans.

The Day

These details relate to the fact that the NetBeans Day 2016 is just around the corner. I am looking forward to take part to this nice conference and see what’s new in the NetBeans landscape since the 2015 edition.

Aux bons entendeurs, salut!

In My Toolbox: Ansible

I’ve recently put my hands on a powerful tool: Ansible, the secret weapon that can greatly simplify a developer’s life.

What is Ansible?

It is a tool for Linux automation. It is heralded as a serious contender for Puppet or Chef but its capabilities go well beyond server configuration and/or DevOps. Its special characteristics are:

• easy to use and understand: just .ini files, YAML and Python
• well integrated with Linux: works over SSH, no daemons necessary
• follows a common-sense philosophy: idempotency, aiming towards a prescribed goal
• versatility: nice programmability and great combinatorial power

The last two qualities make Ansible a tool as valuable for a development team as it is for an admin/DevOps team.

To Build or Not To Build …

It is well known how hard is to design a good build system. I would dare say that, for the Java world, producing a good configuration system is even harder. But there is hope: a good build system combined with the power of Ansible makes life easy again.

Configuration … what?

Distributed systems in general, and Java distributed systems in particular, use configurations. Lots of them. It is a necessity, if we want to keep our distributed systems flexible.

But configurations are costly to manage. There are lots of duplications: tens of services may have configuration elements like my_secret_port=35400 repeated over and over again. Should a change occur, it becomes a burden to propagate on more than a handful of services or servers.

Gradle + Ansible

Here is where the combined power of two great platforms, Gradle and Ansible, comes to the rescue:

1. The product does not (primarily) store information in config files; it stores them within a dedicated set of text files listing the assets of the system
2. The build system, by the power of Gradle, generates the config files in the right place. Duplication (virtually) eliminated!
3. The build system, by the power of Gradle, generates the playbooks (recipes) that Ansible will use. Repetitive manual work (virtually) eliminated!
4. The deployment system, by the power of Ansible, deploys the modules by running the playbooks generated by Gradle onto the nodes that come from the asset files mentioned above

Easy, safe and sound.

Templates, maybe

The generation of the Ansible playbooks and Java config files may come directly via Gradle (some plug-in development in order) or, much easier and safer, via a template-ing system like Apache FreeMarker. But, about that, I will write in a future article.