git push deploy to docker

UntitledBin ziemlich zufrieden, mit dem jetzt erreichten Setup, für das automatisierte Deployment unserer Serveranwendungen. Jeder im Team kann jetzt via Jenkins eine aktuelle Version der Anwendungen deployen.

Dazu haben wir über die letzten Monate die verschiedenen bisherigen Artefakte (war, jar) in Docker Images verpackt, docker-compose Konfigurationen für die verschiedenen Installationsumgebungen erstellt (Test, Produktion, Intern, …) und zuletzt noch git repositories mit Hooks eingerichtet, die bei einem Push das Deployment anstoßen.

Ich denke ich werde dazu in einer der nächsten Podcast Episoden des Donau Tech Radios mehr erzählen und eventuell noch einen Blog Artikel verfassen.

Java ist in den letzten Monaten wieder viel populärer geworden

Laut aktuellem TIOPE Index hat Java den Vorsprung auf die am zweitmeisten verbreitete Programmiersprache C wieder stark vergrössert (um fast 6%). Das wundert mich – was hat dazu beigetragen dass Java gerade in den letzten Monaten wieder so populär geworden ist?

Screen Shot 2016-01-18 at 16.51.32

Zuerst habe ich gedacht da zählt auch Groovy und Scala mit rein, aber die werden extra gelistet.

Gut zu sehen auch, dass sich Swift verdient von Platz 25 auf 14 vorgeschoben hat. Am meisten hat Groovy dazu gewonnen – von Platz 82 vor auf 17.

JavaScript und Swift wird für heuer sogar ein Top Ten Platz vorhergesagt – kann ich mir auch gut vorstellen ;)

Grails 2.2.x and the problem with inner classes

We have been using Grails 2.2.x in some of our projects since it came out last year. Last week when I tried to upgrade another project because it was time to develop some new features I ran into a strange problem after upgrading from 2.1.3 to 2.2.1:

org.codehaus.groovy.grails.web.pages.exceptions.GroovyPagesException: Error processing GroovyPageView: Error executing tag : Error executing tag : java.lang.VerifyError: (class: com/troii/project/tags/SomeTag$Info, method: getSession signature: ()Ljavax/servlet/http/HttpSession;) Incompatible object argument for function call
	at com.googlecode.psiprobe.Tomcat70AgentValve.invoke(Tomcat70AgentValve.java:38)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:722)
Caused by: org.codehaus.groovy.grails.web.taglib.exceptions.GrailsTagException: Error executing tag : Error executing tag : java.lang.VerifyError: (class: com/troii/project/tags/SomeTag$Info, method: getSession signature: ()Ljavax/servlet/http/HttpSession;) Incompatible object argument for function call

I had never seen a java.lang.VerifyError exception before and the second strange thing was that the exception only occured when deploying the war in a tomcat not when starting the app with grails run-app.

Searching the web brought up some JIRA issues:

GRAILS-9627 inner class or enum in domain class breaks unit/integration testing
GRAILS-9784 Using an anonymous inner class in Controller causes VerifyError
GRAILS-10068 inner class in controller class breaks unit testing

and a blog post from someone who experienced the same issue.

Seems like with the update from Groovy 2.0.6 to 2.1.0 caused a compilation problem for inner classes. I had no chance to test with Grails 2.2.2 which was release three days ago but it seems the only workaround currently is to move the inner classe to external ones.

UPDATE: Seems Grails 2.2.2 improved a lot, at least for our project it works.

Java Bean Getters/Setters

Many Java developers think they know everything about Java Beans and the correct getter/setter styles, but there are some hidden traps ;-)

Let’s do a little quiz!

How should the correct and getter/setter for a property with the following field look like?

private String name;

This is an easy one:

public String getName() {
  return name;
}

public void setName(String name) {
  this.name = name;
}

Notice that the first letter of the field was made uppercase.

Here is a different one:

private String URL;

The correct getter/setter methods would look like:

public String getURL() {
  return URL;
}

public void setURL(String URL) {
  this.URL = URL;
}

In this example the field was already uppercase so nothing was changed in the getter/setter.

So what’s about a field like this:

private String iMessageId;

This one is a little bit tricky – could you guess the correct getter/setter?

public String getiMessageId() {
  return iMessageId;
}

public void setiMessageId(String iMessageId) {
  this.iMessageId = iMessageId;
}

It is important that the case was not changed – like for the URL field. This happens when the second letter of the field name is already uppercase. The reason for this is the method java.beans.Introspector.decapitalize:

/**
 * Utility method to take a string and convert it to normal Java variable
 * name capitalization.  This normally means converting the first
 * character from upper case to lower case, but in the (unusual) special
 * case when there is more than one character and both the first and
 * second characters are upper case, we leave it alone.
 * 

* Thus "FooBah" becomes "fooBah" and "X" becomes "x", but "URL" stays * as "URL". * * @param name The string to be decapitalized. * @return The decapitalized version of the string. */ public static String decapitalize(String name) { if (name == null || name.length() == 0) { return name; } if (name.length() > 1 && Character.isUpperCase(name.charAt(1)) && Character.isUpperCase(name.charAt(0))){ return name; } char chars[] = name.toCharArray(); chars[0] = Character.toLowerCase(chars[0]); return new String(chars); }

I guess this one was new to some of you, wasn’t it?

The last example applies to boolean properties. We know that the getter/setter for

private boolean active;

may look like

public boolean isActive() {
  return active;
}

public void setActive(boolean active) {
  this.active = active;
}

or

public boolean getActive() {
  return active;
}

public void setActive(boolean active) {
  this.active = active;
}

But not everybody knows that the getter/setter for a property of the type Boolean:

private Boolean closed;

must look like

public Boolean getClosed() {
  return closed;
}

public void setClosed(Boolean closed) {
  this.closed = closed;
}

the getter isClosed() would not be recognized.

Not to long ago even Eclipse code generators made mistakes with those edge cases – I checked today and both IntelliJ and Eclipse generated everything correct. If you want to look into the specification you can do this here.

What to ignore

With the latest improvements we made at troii to our development workflow, we discussed what should be committed to a source code repository and what files should be ignored. We already had the rule in place, that nothing should be put into the repository, that is generated from other sources (typically .class files, .war, .jar, …) – this rule is very common and agreed by almost every developer.

How to handle another set of files usually leads to a lot of discussion: IDE settings, e.g. Eclipse .settings, .project, .classpath or IDEA IntelliJ .iml and .idea directory). Up until a year ago we mainly used Eclipse and I used to store the IDE configuration files in the repository. With switching to IntelliJ and working more with git branches, I startet to think about this again, because I had the feeling that those settings files changed more frequently.

I read some articles and posts online and I came to the conclusion that it is better to exclude those settings files too. After looking at the dedicated github repository for git ignore templates at https://github.com/github/gitignore it became even clearer. The template for IntelliJ https://github.com/github/gitignore/blob/master/Global/IntelliJ.gitignore looks like:

*.iml
*.ipr
*.iws
.idea/

The reasons I had, for putting those IDE settings into the repository, were, that I want a new developer in the team to be able to check out the code and start developing as fast as possible. A new project member should not have to configure his IDE in a very specific way to get the project running or even compiling. With using maven, gradle and Grails in nearly every project this has gotten a lot easier because most IDE’s have import features, that can interprete those build systems and configure the project.

After deciding to stick with those rules, I looked for an easy way to use those git ignore templates and found gitignore-boilerplates – or short gibo. This is a nice little shell script that allows you put the right templates for your project together into the .gitignore file, for example the line

gibo Eclipse IntelliJ Windows OSX Maven Java > .gitignore

creates a gitignore file for a Java project that uses Maven and is developed with IntelliJ or Eclipse under Windows or OS X. You could put the Eclipse, IntellIJ, Windows and OSX ignore rules into your global gitignore file on your machine but I like to put them into the project to make sure that all the other developers of the project use those rules too.

I made a fork of each of those projects because there are configuration files I want to add to the repository:

  • code style settings – so that every developer on the team formats the code in the same way
  • encoding settings – important when working on different operating systems

You can find those forks under https://github.com/troii/gitignore and https://github.com/troii/gitignore-boilerplates