Jenkins installation – tips

Tonight, I had to install a brand new Jenkins from scratch (Jenkins ver. 1.606) and I encountered quite a few problems which, I hope, could be useful for somebody:

  1. Maven project: avoid it like the plague!:
    For now, I think the Jenkins’ job template for Build a Maven2 project is not mature enough. Not a big deal, but I spent nearly half an hour on internet, trying to figure out why I couldn’t Publish my JUnit test results (basic feature, one can say) and it was only because I choosed Jenkin’s Maven job instead of the “from scratch” one. So even if you have a Maven project, do not choose this option, it seems buggy.
  2. Email notifications: do not forget anything:
    I use the “Email Extension Plugin“, which is really handy, but requires some basic configuration. Once I finished this mere formality, I tried to send an email by making the build fail. Surprise, it didn’t work! I saw an error in the console log:

    Error sending to the following INVALID addresses: xxx@xxx.xx

    Email addresses were correct and smtp server was properly configured, so I wondered what might be the problem? I search over the internet and found only dead end about people who just did not correctly configured the recipient emails or the email server.
    Right after that, I realized the problem was the from address, I didn’t set a default email sender neither in sendmail nor Jenkins, hence chances were the email was kindly declined. I finally found this option in “Global configuration > Jenkins Location”. How intuitive is that?

  3. Maven: do not try to be a special hero:
    Not a Jenkins flaw, but a Maven one with “non standard” projects. Let me explain:
    I had a project with two sources directory: src and generated (which contains generated sources, but we will be back on this in a while :)). So the question was: How could I possibly declare two sources directories in Maven? One might think that it is as simple as adding a second <sourceDirectory /> in the pom.xml, and I couldn’t blame him because I thought the same at the first time, but after a while, I realized that it would be a little but more difficult. So I went through a lot of discussions on some forums and found a solution pretty quickly: adding those lines into my <project><build><plugins>:

    <plugin>
    	<groupId>org.codehaus.mojo</groupId>
    	<artifactId>build-helper-maven-plugin</artifactId>
    	<version>1.9.1</version>
    	<executions>
    		<execution>
    			<id>add-generated-source</id>
    			<phase>generate-sources</phase>
    			<goals>
    				<goal>add-source</goal>
    			</goals>
    			<configuration>
    				<sources>
    					<source>${basedir}/generated</source>
    				</sources>
    			</configuration>
    		</execution>
    	</executions>
    </plugin>
    

    Which I did, but didn’t test on Jenkins, because Eclipse complained about the generate-sources phase which Eclipse doesn’t seem to handle. Again, I was perky to find a solution very quickly, which consists in putting the <plugins> into a <pluginManagement> tag. It seemed reasonable to me so I did move the tags.
    Oh my..! you silly person, never do that! Eclipse stopped complaining but the consequences were worst than the disease, the sources weren’t included in the build and I started to think that the problem was somewhere else, which was absolutely not the case. I just had to move those <plugins> back where they belong to, in the <build> tag.
    And that was it, problem was solved just by ignoring the Eclipse error.

Cordova for Android + Crosswalk

If you target old Android devices, chances are you will have to work a lot on compatibility issues and spend time understanding why some code works on some browsers and not on some old Android’s WebViews.

Then stop, Crosswalk is for you! You will be able to use Chromium WebView instead of the stock one.

If you do not use Cordova, follow the documentation and it will be just fine. But, if you are in a Cordova project, Crosswalk integration could be slightly more painful. Hence, I recommend that you use a small helper available on npm:

npm install -g cordova-android-crosswalk

And then simply invoke it to install crosswalk :

cordova-android-crosswalk [-t android-ANDROIDAPIVERSION] [-r CROSSWALKVERSION]

Where CROSSWALKVERSION could be “canary”, “beta”, or “stable”.

Chromium should be available by now!

More informations here: https://www.npmjs.com/package/cordova-android-crosswalk

Export Linux’s display toward your Windows’ display

Recently, I had to install a Windows tool (InnoSetup) on our ubuntu server in order to call it from some batch tasks. Wine can do this very well, but the setup requires user interaction, which is a problem since we have no display.

What I did is called X11 forwarding. It is a simple configuration option in the Connection > SSH > X11 section of Putty which, once activated, redirects your Unix’s display to your local Windows’ display.

Actually, it won’t work if you do nothing more, but if you install the magic  freeware named XMing, you will be able to display your Unix’s GUIs on your Windows machine.

Handy, isn’t it ?

Testing architecture

The app I’m working on includes:

  • ongoing Android & iPhone client apps
  • a Java Swing client
  • a Grails based web application

Before my hiring, all tests were done manually, which means several persons had to launch both the Java app and the web application, and test each screen individually. It was a considerable loss of time, and we had a very poor time to regression detection. That’s why I decided to set up continous integration with some tests.

Jenkins – The continuous integration tool

To start, I needed a continuous integration tool, able to build our projects periodically, and after each commit. In the Java ecosystem, Jenkins is one of the most famous open source tool to perform this task. You just have to configure your source control, your email informations, optionally some security & backups modules, and this will do the trick.

Then I created one build, the continuous integration one, building every project after each commit and executing / publishing the standard JUnit tests for those projects.

Once this was done, I started to feel a little better. For me it is a minimum basis. At least we were able to know when somebody committed something who does not even compile and fix it quickly.

Selenium – Web UI Tests

In order to test the web application, we used a Java framework (available in .NET) named Selenium. It aims to emulates user’s interactions with known browsers. It is very handy because you can code your tests and execute them against all your target browsers.

I already used this framework before, and I know that it is really good, so, no hesitations.

So we coded some JUnit test using the Selenium framework, covering some basic features. An important thing to know is that we followed the Page Object Pattern which promotes reusability and maintenability. In my opinion, writing UI tests without this pattern could lead to serious code duplication and decreased maintenability.

Once the web UI tests written, the challenge was to integrate them in a build in order to detect high level regression. Since UI tests could run for a long time, I choosed to execute this build only once every night.

The problem is that Selenium need to actually launch a browser and start clicking with the mouse, which is obviously difficult in a headless environment. Hopefully, I found a magic tool named XVFB. It emulates a graphic server so it is possible to successfully launch browsers.

Once this daemon and the browsers were installed, everything gone fine.

FEST – Swing UI Tests

The last thing I wanted to do was to automate Swing UI tests but I did not know any framework to do this. After a few searches, I came out with several tools, to accomplish this task. I choosed FEST because the project is still active (quite a miracle, for a swing project…), has a community, is an open-source project and the API is pretty cool.

Since I already installed XVFB, it should not have been a problem to include FEST tests into a build, but in fact, it was.

Indeed, FEST worked fine on our workstations but did not under the server’s virtual graphical environment, there was many little bugs which I had to handle one by one. I don’t know if it were Swing bugs or FEST bugs, but we I had to change the code in order to make it work everywhere.

 

Builds and tests run every day, detect regression when there are. The problematic now, is how we grow the amount of test.

 

Web image editor API

We recently came across the need to add a feature on our web app so users could be able to digitally sign some kind of form. Basically, the user should be able to draw something freehand.

I never did this in JS and didn’t know any suitable library to do this kind of job, so I started to search around the Internet and returned with two things:
1) RaphaelJS: API for creating vector graphics
2) svg-edit: A full API for drawing a SVG image freehand, based on RaphaelJS

Indeed, I found everything I need. svg-edit does exactly what our users want. Just assign a container on the web page to svg-edit, add some fancy drawing controls and display animations, and that’s it! It just works.

The only con of svg-edit is the lack of documentation (whereas Raphael has a comprehensive API doc). Even though svg-edit seems to be widely used and still active, I did not found any full documentation.

Have fun with this lib!

Groovy / Grails

Whereas my previous job was fully Microsoft with C#, IIS, MS SQL Server etc… I now daily use the Grails / Groovy technologies and wanted to do a short review about it.
For those who used JEE, there is nothing you can do not to love Grails, it includes natively a MVC pattern and the whole configuration is handled automatically. No more XML-Hell or useless declarations, you only focus on the three essential parts: (i) domain (ii) services and (iii) controllers / views
Grails adopts a layered architecture, and more specifically, a 3 tier architecture. All you have to do is to put your classes in some convention-defined directories. It is very convenient and you really can have a running app in a few seconds! Of course, if you want to fine tune the configuration, it is possible through the Config.groovy file.
Another convenient tool is the Bootstrap file, where you can put any code which will be run right after the server booted up.
Grails is highly extensible because of its plugin system. There is a very active community which provides very useful extensions, such as Quartz integration, or Mail. It is as simple as add a line in a file, and it uses Maven behind the scene so it is pretty robust.
To interact with grails app server, there is a very simple command line. Basically, I only use three of them, create-app (initializes the project), run-app & stop-app.

Let’s come to the dark side of Grails: Groovy. Grails is tightly tied to Groovy because most of the Grails’ classes are groovy class as well.
Actually, at every moment, you are kindly invited to enjoy the wonderful world of Groovy. The problem is when you do not share this idyllic vision. For some components, it is possible to fallback to plain old Java, but the whole Grails architecture is designed for groovy classes integration.
Now, what is so bad about Groovy will you tell me?
Initially, the idea behind Groovy was really great, which is provide a high level language over Java in order to simplify it and make usually verbose operations shorter.

For instance:

Collection left = new ArrayList(3);
left.add("bla");
left.add("blu");
left.add("blou");
Collection right = new ArrayList(left.size());
for (String s : left) {
right.add(s + ", that's my word");
}

would become:

def left = ["bla", "blu", "blou"]
def right = left.collect { it + ", that's my word" }

Yeah, right, really nice, that’s perfect. This actually makes the language better.
But there are some cons to take in account: First, Groovy is not directly compiled, but only “traduced” into Java, then compiled. The result is you have a time to compile/error feedback that is really too long. Secondly, Groovy is supposed to be a dynamic language, so you can call methods that virtually does not exist and dynamically create method extensions at runtime. The problem is that the Groovy compiler makes intensive use of reflection to do that and, for my mind, you loose all the advantage of a strongly typed language. In practice, Groovy is barely able to notice any compilation error, has a poor completion, very sensitive to modifications and does not support correctly refactorings. In addition, it will slowdown the execution of your code because of this reflection. At the end of the experience, you will start to think that it is better to type all your variables and use standard Java language structures. What is very disappointing is that the syntax is very nice and takes the best from some other languages but the backing system is not perfectly implemented so I think it is better to use pure Java, most of the time.
I did not try other high level / over Java languages such as Scala and Xtend but I bet they are much more intuitive and robust.

So to recap a little, Grails is a really cool app server, proposing a fast and efficient architecture to create web app, but the omnipresence of Groovy impairs the quality of the product. Still, if you know Groovy like the back of your hand and that you perfectly know what to do and what not to do, it could be a good development tool !