Programming principles for Java methods

Topics I want to cover in the future about Java methods:

  • Minimalistic coding style [1] [2] [3] [4]
  • “Fail early” (or “fail fast”) principle [1] [2]
  • “Return early” principle [1] [2] [3]
  • Object creation methods (to allow final)
  • Type generic methods (process a T vs create a T)
  • Functional style: stateless static methods vs interfaces
  • Javadoc: On interface not implementation
  • Method naming guidelines
  • Strategy parameters (often anonymous interface implementations)
  • Exception handling methods (try-catch-finally, throwing exceptions)
  • How to avoid setter/getter madness
  • Method chaining API style (static factory method, builder methods)

Jenkins on minimalistic Debian Virtualbox VM (64bit)

Update 14/Aug/2018: I no longer maintain the package mentioned and the download links below are most likely broken.

A Jenkins build server (LTS release) can now be easily installed on the minimalistic Debian VM:

  1. Download and install Virtualbox
  2. Download debian-stable-amd64-minimal.ova and import it into Virtualbox
  3. Start the “debian-stable-amd64-minimal” VM in Virtualbox
  4. If you are outside Nova Scotia, please review debian-stable-amd64-minimal.txt and adjust locale, timezone and Debian mirror based on your location
  5. Start an ssh session to localhost, port 1111 (using PuTTY, for example)
  6. Log in as user (default password is “user”)
  7. Issue “sudo install.sh jenkins” (default root password is “root”)
  8. Press enter for any questions during installation
  9. Open http://localhost:8888/ in a browser on the host OS for Jenkins web ui

You can go to “Manage Jenkins” – “Configure System” and see that JDK, Ant and Maven entries are already configured for you.

Both OpenJDK 6 and OpenJDK 7 are installed automatically for you in the VM. Please note that openjdk-6 is the Debian stable system default, while openjdk-7 is configured as the default for Jenkins build jobs.

Important: Make sure to change root and user passwords to something secure, as mentioned in debian-stable-amd64-minimal.txt.

Lightweight Eclipse package for web development

Update 14/Aug/2018: I no longer maintain the package mentioned and the download links below are most likely broken.

I uploaded a lightweight Eclipse package (based on Helios 3.6.1) for web development (includes Maven, SVN and basic Spring integration, JEE / web tools plugins, but no Mylyn or other non-essential stuff) … This is currently only for Windows. It requires a JDK and is completely free / open source software.

See the txt file for quick installation steps.

Generate and display Maven Build timestamp in WAR

On all the pages of my webapp I want to see when the WAR was built (i.e. a build timestamp). Here is how I did it:

Add this to the pom.xml of your webapp module:

<build>
  <resources>
    <resource>
      <directory>src/main/resources</directory>
      <filtering>true</filtering>
    </resource>
  </resources>
</build> 

<properties>
  <mavenBuildTimestamp>${maven.build.timestamp}</mavenBuildTimestamp>
</properties>

Create a file src/main/resources/build.properties in  in your webapp module with the following content:

# Build Time Information
build.timestamp=${mavenBuildTimestamp}

The Maven build will replace the Maven property and the resulting file WEB-INF/classes/build.properties will look like this:

# Build Time Information
build.timestamp=20101016-0303

Now we just need a Spring PropertiesFactoryBean definition to make properties available at runtime:

<bean id="appProperties" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
  <property name="locations">
    <list>
      <value>classpath:build.properties</value>
    </list>
  </property>
</bean>

I used a simple Spring bean to make the timestamp easily available in Spring Web Flow / Spring Faces EL expressions:

@Component
public class ViewUtil {

  private Properties appProperties;

  /**
   * @param appProperties Global Application properties
   */
  @Resource
  public void setAppProperties(Properties appProperties) {
    this.appProperties = appProperties;
  }

  /**
   * @return The Build Timestamp as generated by Maven
   */
  public String getBuildTimestamp() {
    return appProperties.getProperty("build.timestamp", "UNKNOWN");
  }
}

The EL expression code in the JSF page is then something like this:

Build timestamp: #{viewUtil.buildTimestamp} 

And this is what the result looks like on the page:

Build Timestamp screenshot

If you want to be able to refer to properties directly by name in your Spring configuration you can define a Spring PropertyPlaceholderConfigurer:

<bean id="propertyConfigurer"
      class="org.springframework.web.context.support.ServletContextPropertyPlaceholderConfigurer">
  <property name="properties" ref="appProperties" />
</bean>

Maven ‘skip tests’ & test-jar dependency errors

If you use test-jar dependencies in a multi-module Maven project (see my previous posting) you will run into a problem when you run Maven install with the maven.test.skip option turned on.

Problem

Maven looks for dependencies on test-jars even when maven.test.skip is turned on. This posting on the Maven issue tracker site perfectly summarizes the problem.

The maven.test.skip option (which is equivalent to the ‘Skip tests’ checkbox in IntelliJ’s Maven Runner options) prevents test code compilation, packaging and execution.

Hence no test-jars are built and that leads to the dependency error described above.

Solution

Disable the ‘Skip Tests’ checkbox in IntelliJ and INSTEAD add a property skipTests with value true.

This causes all test code to be built (and packaged as test-jars – when configured as described in my last posting) and only disables the execution of the tests.

Maven test execution options

maven.test.skip
Disables both running the tests and compiling the tests.

skipTests
Set this to true to skip running tests, but still compile them

Maven test-jar and test code reuse

In a multi module Maven project you might want to reuse test-related code (in src/test) across modules.

The recommended way is described here:
http://maven.apache.org/guides/mini/guide-attached-tests.html

You might want to exclude test classes from test-jar, to prevent that they run multiple times. Add this to your maven-jar-plugin definition (right after the <goals>..</goals> section) :

<configuration>
    <excludes>
        <exclude>**/*Test.class</exclude>
    </excludes>
</configuration>

This assumes that your test classes and only your test classes are named “…Test”.

More info on maven-jar-plugin configuration options for the test-jar goal:
http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html