Triona Weblog

Problem:
You want to create a build number in the web front end of your application (e.g. to have it on screenshots appended to bug reports during user acceptance test).
You are using maven for your builds and your code is under source control (e.g. using subversion).

Solution:
All you need is some maven plugins and a place to write the build number to.
In this case I’d like to have the maven version number followed by the subversion revision number and a timestamp of the build date like this:

Version: 1.0-SNAPSHOT r1 Built on: 2012-02-19 13:41

First I create a version.html in src/main/resources or src/main/templates or something like that:

<div class="version">Version: @VERSION@</div>
<div class="builton">Built on: @BUILTON@</div>

As you can see there are two placeholders (@VERSION@ and @BUILTON@)
Next I insert and configure the plugins to create the version info and the timestamp and to replace the placeholders with them in my pom.xml:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>maven-buildnumber-plugin</artifactId>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
</execution>
</executions>
<configuration>
<doCheck>true</doCheck>
<doUpdate>false</doUpdate>
</configuration>
</plugin>

This creates a property named buildNumber with the revision number of the checked out code. The configuration doCheck=true causes a check whether there are any uncommitted changes. If there were any, the build would fail. With doUpdate you could instruct the build to execute a svn update prior to execution of the build.
For more info about this plugin see here:
http://mojo.codehaus.org/buildnumber-maven-plugin/
We could also use this plugins goal “create-timestamp” to create the timestamp, but since maven itself provides a property for that we just need to set that properties format in the properties section of our pom:

<properties>
<maven.build.timestamp.format>yyyy-MM-dd HH:mm</maven.build.timestamp.format>
</properties>

Now having all we need, we need to replace the placeholders in our html and copy the replacement to our target folder.

<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>maven-replacer-plugin</artifactId>
<version>1.4.0</version>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>replace</goal>
</goals>
</execution>
</executions>
<configuration>
<file>src/main/templates/version.html</file>
<outputFile>target/version.html</outputFile>
<regex>false</regex>
<replacements>
<replacement>
<token>@VERSION@</token>
<value>${version} r${buildNumber}</value>
</replacement>
<replacement>
<token>@BUILTON@</token>
<value>${maven.build.timestamp}</value>
</replacement>
</replacements>
</configuration>
</plugin>

This replaces the placeholders in src/main/templates/version.html with the values and writes the result into the specified target folder.
More info about this plugin is provided here:
http://code.google.com/p/maven-replacer-plugin/
Having that, you just need to include that into your pages. That’s it.

Conclusion:
We now have a build number on our pages.
There for sure is room to improve this solution and it is for sure not the only solution. But it did the job for me and I hope it will help you.
If I should have forgotten something in this description, do not hesitate to give me feedback via the comments form.

In my current project we develop a web application using JSF (1.2) / Facelets with RichFaces in the front end and EJB3/Hibernate in the back end. Deployment target is a JBoss 5 application server.
We defined some hibernate entities and some backing beens for our Facelets. Nothing special so far.

We defined the numeric fields of our entities using the wrapper objects with the goal to store NULL (instead of zero) in the database if nothing was entered in the form.

@Entity
public class MyEntity{
...
   @Column(name="NUMERICFIELD")
   private Integer numericField;
...
    //getters and setters
...
}

We access the entities through the backing beans and access their fields directly using their getters and setters using EL (Expression Language) in the Facelets.

public MyEntity getMyEntity(){
    return myEntity;
}
public void setMyEntity(MyEntity myEntity){
    this.myEntity = myEntity;
}

<h:inputText id=”myInputText0″ value=”${myBackingBean.myEntity.numericField}”/>

Due to lack of deeper knowledge of the JSF specifications we were quite surprised seeing zeros instead of nulls in the database after submitting an empty inputText.

After googling around a bit I found some blog and forum posts stating that setting the system property

org.apache.el.parser.COERCE_TO_ZERO=false

– which is a system property of the embedded Tomcat web container – would solve our problem. And it actually did. After setting the system property in the jboss’ startup script null values were stored instead of zeros.

But why? What was the story?
So I started searching in the tomcats documentation where I found:

org.apache.el.parser. COERCE_TO_ZERO

If true, when coercing EL expressions to numbers “” and null will be coerced to zero as required by the specification. If not specified, the default value of true will be used.

Oh,

… as required by the specification.

Ok, so I took a look into the EL’s spec and really, the conversion rules for numbers on page 17 in that document say:

1.18.3 Coerce A to Number type N

• If A is null or “”, return 0.
• …

So, by setting the stated system property we made Tomcat behave differing from the standard EL.
Our team discussed a little bit and then decided to document it and live with it, because we

• have full control over the production server,
• have a dedicated app server instance for our application and
• would have had much effort to change our design as we found problem.

Conclusion:
If you designed your application the way we did and face the same problems like we did, you could use the system property as described in this article.
But if you might have to share your production unit with other applications, I strongly recommend a change of your design.
In that case you should imho think about explicit type conversion in your controller / backing bean instead of directly using your entity there.
Further suggestions are appreciated.

You may have some recurring development tasks while your daily work with java in different projects. For example you again and again write some small code that capitalizes a given String. Or you write an application with a command line interface and write code that defines and parses your command line options. Or you need some little helpers for your database handling. Or …
These are only some examples and if you don’t have already written and built your own little libraries for those tasks, you may want to have a look at Apache Commons, formerly known as Jakarta Commons. There are libraries for everyday use in different packages.
I will provide you a short overview over Apache Commons here and write some more articles about some of their libraries in the next weeks.
So, Apache Commons assign their libraries to three repositories depending on their development stage and usage (list taken from their site):

• The Commons Proper – A repository of reusable Java components.
• The Commons Sandbox – A workspace for Java component development.
• The Commons Dormant – A repository of Sandbox components that are currently inactive.

I will focus on Commons Proper in this and my following articles since the contained components are ready to use and stable.

Currently, Commons Proper contains 39 components. You can categorize them into web, xml, utilities, converters and Java API extension.
The following table is taken and translated from german Wikipedia:

I’m working with Excel and Word documents in my latest java project. On Windows plattforms Eclipse opens those documents with its own OLE editor by default. But I feel much more comfortable in using the Office apps to edit them. This can be done by right clicking on the file icon and choose “open with -> system editor” for example. But you will have to do this for each new or moved file in your workspace the first time you open it.
Thus Eclipse opens these files with Excel or Word by default you need to navigate to “Window -> Preferences -> General -> Editors -> File Associations”. You will notice, that there are no file associations for Excel nor Word. You have to explicitly add the file types (*.xls and *.doc for example) and add the desired applications as associated (external) editors.

Es gibt einige schöne Tools und Plugins um sich das Leben mit WordPress etwas leichter zu machen.

So ist es zwar schön, dass WordPress Code-Schnipsel etwas absetzt, aber noch schöner wäre doch, wenn es auch Syntax-Highlighting bieten würde.
Genau dafür gibt es unter anderem das Plugin WP-Syntax, das unter http://www.blog-experiment.de/2009-05/syntax-highlighting-in-wordpress-wp-syntax/ beschrieben wird.

Ein weiteres “nice-to-have” wäre doch, wenn man sein in (Open-) Office erstelltes Word-/Writer-Dokument direkt aus der Applikation im Blog veröffentlichen könnte.
Auch das ist möglich. Dazu muss in WordPress lediglich XML-RPC aktiviert werden und in OpenOffice die Sun-Weblog-Publisher-Erweiterung installiert und konfiguriert werden.