Sunday, June 30, 2013

About Java Software Installers and Launchers

1 Introduction

In the early stages of your software projects, it's a good practice to think about the distribution aspect. It doesn't matter how good a product is, if no one can perform the installation or run the application.

Generating software installers is not always easy, regardless of the installer product used.

If you're lucky enough to have a good commercial software installer, you can generate quickly packages without too much pain:

  • Easy generation of application launchers.
  • Good default settings with flexibility for splash screens, installer icons, pre-installation/post-installation actions, etc.
  • Generation of software packages for a variety of platforms (OSX, Unix, Linux, Windows, etc.).

2 Application launchers

Now that your application development phase is complete, you may be worried about writing couple of launchers.

Writing a Java application launcher can become fairly complicated depending on :

  • The amount of libraries dependencies used by the program.
  • The configurations and properties to resolve or create in order to run the application properly.
  • Any tasks that need to be executed prior to launching the application.

For Java based applications, below are the common steps performed by launchers scripts:

  • Find the Java executable (JAVA_HOME detection if needed, common locations depending on the Operating System).
  • Validate the Java version requirements as well as potential optional settings.
  • Setup any environment variables or system properties needed by the application.
  • Construct the Java classpath from the application dependencies.
  • Perform any actions need prior to launching the program.
  • Invoke the Java command with the classpath and JVM arguments to start the application.

ClassWorlds is a simple Java application launcher framework that has been around for a while. It superseeded the forehead framework launcher. Forehead was used by many tools such as Maven (now using ClassWorlds).

What makes ClassWorlds compelling is that it's really easy to bootstrap an application launcher without much effort. All that Classworlds needs is a simple java command that references a boot jar file and your application configuration file(to load libraries).

3 Software Installers and packaging

Depending on the application's type, target audience and operating systems, many options are available. Commercial Software package generators usually provide good results without too much work. Decent to really good products for Java software packaging include InstallAnywhere and Install4j.

Some free Java-oriented installers generators can be found on java-source.net. A popular choice is IzPack.

Generating software packages by hand still gives you an overall better user's installation experience at the expense of time and potential bugs (typos, logic errors, etc.).

When your installation packages are ready, you then need to test them on all supported platforms, just to be safe.

Zip distributions are very convenient for many users:

  • No administration rights needed most of the time, which is useful when you don't have administrative rights on a machine.
  • One step installation, just a matter of extracting a software archive.
  • Easy uninstallation which is a simple folder deletion.

When generating software packages, don't forget the simple way of distributing files via zip archives.

Saturday, June 22, 2013

A good dev Linux Distribution - Fast with many packages

Fast with many packages is not the only selection criteria for a Linux distribution, but it's important. "Click and wait... Download manually packages on a regular basis??" -> "no thanks".

I've used many Linux Distributions over the years: Redhat, Mandriva(previously Mandrake), Debian, Gentoo, Slackware, CentOS, Fedora, Knoppix, Suse, Zenwalk, Ubuntu, etc.

My main machine at work usually runs some Linux variant. I was lucky enough to always have that luxury since I started to work "As long as you don't need support and you can work with it, you can run Linux on your PC".

Linux distributions perceived speed
Redhat based distributions have to be the slowest around, so I tend not to use them, unless I have to. Among the fastest Linux distros(non minimalistic), I would count in Slackware, Gentoo and few others.

Today I tried Arch Linux for the first time. I must say that I'm very much impressed with the raw speed. I would even dare to say that it feels faster than Gentoo or Slackware, without any additional optimization or custom kernel compiled.

Linux distributions with nice package managers
Couple of years ago, RPM based distributions were annoying. It was a real dependency hell depending on where you grabbed your RPM package... Nowadays things are better(yum, etc.), but RPM dependency resolution traumatized me for good...

As soon as I was introduced to Debian, I never looked back. For a quick install in few minutes Ubuntu will do and for a server a pure Debian distro is nice. Once in a while, I try couple of Linux distributions just for fun.

Having a nice set of packages available is cool especially when your distribution has a "reliable and powerful" package manager.

What a dev like me wants from a Linux distro
These days, I only need few things from a Linux distro:
  • It has to be fast, as I like to multitask but I also have couple of GB of RAM to spare.
  • No RPM based distro, Debian or something else. I've always preferred Debian for its apt-get super powers. apt-get has been around for a while and I like it a LOT.
  • I don't need a graphical installer but I also don't want to a full installation from chroot with tons of steps, unless I have time to kill...
  • Many packages should be available via the package manager of the distribution, as I try to avoid compiling too many applications.
  • Flexible installation options (base system vs full desktop/server system). When I have time, I build a system with only what I need...



Saturday, June 01, 2013

Maven wrapper project - from Jar library to Maven plugin

Last month, the maven-wrapper project caught my attention on Github.

This morning, I had time to kill and I decided to take a closer look at it. I eventually played with it, forked it and added a quick and dirty feature "basic Maven plugin support".

The maven-wrapper project is a port of the Gradle wrapper to Maven.
It will download a Maven distribution automatically for you and set it up. Currently the project is just a library, more or less a work in progress at this time.

Again, I can't emphasize enough on the importance of build tools wrappers, especially on build machines. The release management folks doesn't need to follow any detailed setup guide, nor do they need to worry about managing multiple versions of the same build tools.

"Plugin-ifying" the maven-wrapper project
I did a very quick and dirty implementation of a Maven plugin, so that the code could be reused as a plugin in new or existing Maven project.

It was just a matter of adding few dependencies and writing a simple Mojo.
I eventually renamed the artifactId to have auto-mapping enabled in terms of namespace and goals.

Nowadays, it's possible to write Mojo descriptors with Java annotations instead of xdoclet-like comments.

I opened a pull request to merge the code in the original project few hours ago.

Maven wrapper plugin usage
Checkout the maven-wrapper forked project and run the Maven install goal.
mvn install

In another Maven project, add the following to your build->plugins section

    <build>
 ..
 
         <plugins>
   ..
      <plugin>
        <groupId>org.apache.maven</groupId>
        <artifactId>wrapper-maven-plugin</artifactId>
        <version>0.0.1-SNAPSHOT</version>
      </plugin>
   ..
    </plugins>
 ...
    </build>
    
Maven version compatibility
In terms of compilation, it should work with Maven 3.0.2 dependencies and above. The default distribution URL contains some maven versions from 2.0.9 to 3.0.5.
The distribution URL is not customizable automatically at this point (when generating the wrapper supporting files).


What would be nice to have in terms of configuration

  • POM driven customization of the default settings (launcher names and location, distribution URL). It's currently possible to do it manually though.
  • Token substitution inside the plugin when generating wrapper artifacts.