JPz'log

IzPack 4.3.1 is available

jponge — Wed, 17 Jun 2009 08:58:32 +0000

I’m pleased to let the world know of the availability of IzPack 4.3.1

This is a maintenance release. While it is not very spectacular by itself, upgrading is still a very good idea as you will grab a few fixes there and there.

Many thanks to our community (developers, contributors, issue reporters and users) for making this release possible, and go to http://izpack.org to get your copy today!

Support the IzPack development by making a donation!

jponge — Thu, 11 Jun 2009 10:09:56 +0000

Hi everyone,

As you can easily guess, maintaining and developing IzPack since 2001 has been a lot of fun… and also a significant time investment

I am already offering professional services for those who would need support, consulting and custom developments (see http://izpack.proservices.ponge.info/). A few companies also give back to the project in the form of patches and contributors / developers: thanks to you all!

However, the large majority of IzPack users simply download it and never give back anything. This is perfectly fine of course, but I would like to let you know that you can support my very own work on this project by making a donation

To do that, you can use the following link (note that you will receive both my gratitude AND a true invoice).

Thanks for your support!

(ps: for those who may ask, the adsense units on the website mainly cover the domain name and web hosting)

Discovering Grails Web Flows

jponge — Mon, 01 Jun 2009 14:42:33 +0000

I recently discovered Grails Web Flows. This is basically a Groovy DSL on top of Spring Web Flows.

I did a quick dirty and imperfect example which is a number guessing game. I took inspiration from another Grails Web Flows tutorial.

In this post, I will limit myself to some very quick description of web flows, and I urge you to read the documentations (from Grails and Spring). The idea behind web flows is to provide a framework for web conversations that span multiple HTTP requests, such as wizards, payment processes and such. A “web flow” is modeled as a state machine, where:

states represent either an action (i.e., some code) or a view, and
transitions are triggered based on the outcome from the state, which is a simple string.

As such, web flows free the developer from much repetitive logic when you need to control states of a web conversation.

In this example, the number to guess is 25 (we could have made it non-static, but who cares?). The user has 5 attempts. The corresponding flow is:

Grails provides web flows out of the box. All you have to do is to create a special controller closure property which ends by “Flow“:

class GuessController
{
 
  def toGuess = "25"
 
  def index = {
    redirect(action: "guess")
  }
 
  def guessFlow = { ... }
 
}

We now have to define the “guess” flow. As often in Groovy and Grails, it boils down to some intuitive builder structure:

class GuessController
{
 
  def toGuess = "25"
 
  def index = {
    redirect(action: "guess")
  }
 
  def guessFlow = {
 
    start {
      action {
        [guessLeft: 5]
      }
      on("success").to("ask")
    }
 
    ask {
      on("evaluate").to("evaluate")
    }
 
    done()
 
    fail()
 
    evaluate {
      action {
        if (params.number == toGuess)
        {
          return yes()
        }
        flow.guessLeft = flow.guessLeft - 1
        if (flow.guessLeft == 0)
        {
          return loose()
        }
        else
        {
          return no()
        }
      }
      on("yes").to("done")
      on("no").to("ask")
      on("loose").to("fail")
    }
  }
}

start is an action state, which is called first, and that puts a guessLeft variable in the flow context.
The ask state displays a web page, then delegates the logic to the evaluate action state.
The evaluate action state either pushes the flow to the final states, or loops back to the ask state if there are guesses left.
done and fail are final states that just show some web pages.

Finally there are 3 views that you need to create. Since the web flow is named “guess”, they must be in a special “guess” subfolder of the matching controller views. Also, they must be named by the state names.

ask.gsp

<%@ page contentType="text/html;charset=UTF-8" %>

  Simple GSP page
  
 
  
  
    document.observe("dom:loaded", function() {
      $("field").focus();  
    });
  
 
  Guess
  Guesses left: ${guessLeft}.

Note that the guessLeft flow context variable is available directly in the GSP. Also, note that the form action must match the web flow name and that the submit button name is the outcome of the view state.

done.gsp

<%@ page contentType="text/html;charset=UTF-8" %>

  Simple GSP page
  You won!

fail.gsp

<%@ page contentType="text/html;charset=UTF-8" %>

  Simple GSP page
  You failed...

Taking SWT/Cocoa and MigLayout for a spin

jponge — Sat, 23 May 2009 20:15:53 +0000

It’s been a while since I last had a look at SWT (the so-called “standard widget tookit”). One very good reason is probably the fact that I have switched to Mac OS X, and the Mac SWT port used to suck badly. To convince yourself, download Eclipse and play with it. I’m sure you’ll feel that it does not really look like a true Mac OS X application, and you will easily spot UI glitches there and there (tip: edit a field in a table, just for fun). This is even more critical when Swing applications like IntelliJ IDEA or Netbeans look so great while relying on a non-native toolkit…

SWT is still a very capable GUI toolkit. Although the API feels a lot more low-level than Swing, you can get some satisfying rsults by using it. It is not a Filthy Rich Clients compatible toolkit (forget the slick interfaces that you can make on top of Swing), but some stuff can become way easier in the world of SWT than in the world of Swing (e.g., embedding a web browser or getting a truly native file dialog). Another good reason for keeping SWT under the radar is that it is actively developed while one can reasonably fear that Swing is… more in a kind of maintenance mode to say the least.

The SWT team recently took the Mac OS X matters seriously and decided to port it over Cocoa, the framework upon which true Mac OS X applications should be built. Indeed, the existing port used to be made over Carbon, the now deprecated Mac APIs that endanger the future of Eclipse on Mac OS X. Although this is still work in progress, SWT/Cocoa is just great (and Eclipse is probably going to look ok on a Mac, although I am not going to switch back to it any time soon).

I took it for a spin to build a very stupid application:

If you press the button, a message box shows up to repeat the informations. It also features a label with an hyperlink that pops up a web browser.

Good layouts are both critical (otherwise your application looks like a toy) and hard to realize. I used the fantastic MigLayout libary. There is a version for both Swing and SWT. It is somehow reminiscent of the JGoodies layouts, and the extra bonus is that the library weights really nothing.

My main class is fairly standard for a SWT application:

public class Main
{
    public static void main(String[] args)
    {
        Display display = new Display();
        Shell shell = new Shell(display, SWT.SHELL_TRIM);
        shell.setText("Swt/Cocoa");
 
        new MyController(shell);
 
        shell.pack();
        shell.open();
        while (!shell.isDisposed())
        {
            if (!display.readAndDispatch())
            {
                display.sleep();
            }
        }
 
        display.dispose();
    }
}

My “controller” (which should have not be named like that since it is not a true controller…) is relatively simple too:

public class MyController
{
    private final Shell shell;
 
    public MyController(Shell shell)
    {
        this.shell = shell;
        initialize();
    }
 
    private void initialize()
    {
        final MigLayout layout = new MigLayout("fillx", "[right] rel [grow, fill]");
        shell.setLayout(layout);
 
        final Label nameLabel = new Label(shell, SWT.NONE);
        nameLabel.setText("Name:");
 
        final Text nameText = new Text(shell, SWT.SINGLE | SWT.BORDER);
        nameText.setText("Somebody");
        nameText.setLayoutData("wrap, width 300px");
 
        final Label emailLabel = new Label(shell, SWT.NONE);
        emailLabel.setText("Email:");
 
        final Text emailText = new Text(shell, SWT.SINGLE | SWT.BORDER);
        emailText.setText("foo@bar.com");
        emailText.setLayoutData("wrap");
 
        final Button displayButton = new Button(shell, SWT.PUSH);
        displayButton.setText("Display");
        displayButton.setLayoutData("span 2, tag ok, gapy unrelated, wrap");
 
        final Link urlLink = new Link(shell, SWT.NONE);
        urlLink.setText("More informations...");
        urlLink.addSelectionListener(new SelectionAdapter()
        {
            @Override
            public void widgetSelected(SelectionEvent selectionEvent)
            {
                Program.launch("http://jpz-log.info/");
            }
        });
        urlLink.setLayoutData("span 2, align left, gapy unrelated, wrap");
 
        shell.setDefaultButton(displayButton);
 
        displayButton.addSelectionListener(new SelectionAdapter()
        {
            @Override
            public void widgetSelected(SelectionEvent selectionEvent)
            {
                String normalForm = new StringBuilder()
                        .append(nameText.getText())
                        .append(" <")
                        .append(emailText.getText())
                        .append(">")
                        .toString();
 
                MessageBox box = new MessageBox(shell, SWT.ICON_INFORMATION | SWT.OK);
                box.setMessage(normalForm);
                box.open();
            }
        });
    }
}

Simple isn’t it?

Of course it could have been made even more compact by using Groovy, Scala or JRuby…

One last thing: SWT applications need a special -XstartOnFirstThread JVM flag on Mac OS X.

Two IzPack use cases (Terracotta and Sun Grid Engine)

jponge — Sun, 17 May 2009 18:27:16 +0000

I recently became aware of two new great use cases of IzPack. I thought I would share them with you

The first one is brought by Terracotta, the JVM clustering specialists. Download the cross-platform installer and you will get a nicely done IzPack-based installer.

The second one if from the friends at Sun Microsystems, as they built an impressive installer for Sun Grid Engine. That’s a truly awesome one, as it exhibits lots of customizations (e.g., custom panels).

Here are some screenshots (the Sun Grid Engine ones come from their wiki site):

Shall need be, it proves once again that highly specific needs can be served with IzPack, an open and extensible platform for making cross-platform installers. With IzPack you are not constrained within the bounds of a rigid, so classical type of installer framework (I won’t give names, but hey, there is even an installers company that tries to pretend making opensource!).

On a final note, do not forget that you can get IzPack consulting, support and custom development from me

What’s new in IzPack 4.3.0?

jponge — Thu, 07 May 2009 08:24:32 +0000

IzPack 4.3.0 was released on April 21st 2009.

The present document contains the announcement materials and some highlights on the new features in this release.

About IzPack

IzPack is a one-stop solution for packaging, distributing and deploying applications. IzPack is opensource, released under the liberal Apache Software License 2.0.

It is fully cross-platform and generates a single installer. As such, it is an alternative to native solutions such as platform-specific installers and package managers.

IzPack-generated installers only require a Java virtual machine to run.

Many companies and projects have been using IzPack over the years, including Sun Microsystems, JBoss/RedHat, the Scala language project, some ObjectWeb/OW2 projects, XWiki and many more.

Downloading IzPack

IzPack can be obtained free of charge from its website at http://izpack.org/

Getting professional services

IzPack creator and project leader Julien Ponge offers paid professional services:

one-time and subscription-based support,
consulting,
custom developments,
installer creation bootstrap.

Do not hesitate to contact Julien and get more informations from http://izpack.proservices.ponge.info/

Those services directly help in sustaining and improving IzPack.

About this release

This release is the result of a collective effort where our developers and contributors worked hand-in-hand to improve IzPack. Also, new developers have joined the project to bring further ideas and energy to the project.

About a hundred issues have been resolved in this release. The complete list along with JIRA issues can be reviewed at http://jira.codehaus.org/browse/IZPACK/fixforversion/14763

New features highlights

The release contains its usual set of bug fixes, small enhancements and documentation improvements. Each resolved issue is significant, however we cannot detail each of them. Instead, let us focus on some important new features in IzPack 4.3.0.

Scripting support through the Apache Bean Scripting Framework

IzPack provides installation, compilation and uninstallation events which can be intercepted by custom handlers. This is a common IzPack extension mechanism. As an example, IzPack itself provides such handlers for various tasks such as writing Windows registry entries during installation, and properly removing them during uninstallation.

This new feature allows such handlers to be implemented with a scripting language rather than Java classes. This makes them easier to develop, test and maintain in some contexts.

The Apache Bean Scripting Framework (see http://jakarta.apache.org/bsf/) supports a wide range of languages, including JavaScript, Groovy, Python, Ruby and more.

This feature was contributed by Matthew Inger.

See http://jira.codehaus.org/browse/IZPACK-240

Full console manual and automated installations

This is probably the most long awaited feature in IzPack!

From the start, IzPack has provided the ability to record and replay installations on other systems. This is however very different from “real” console installations, which turn out to be useful in production scenario (e.g., installing a software on a remote system through a SSH connection that does not forward X11 instructions).

Console installations can be manual (through text prompts) or even automated.

This great work was contributed by Mounir El Hajj.
See http://jira.codehaus.org/browse/IZPACK-320

Removal of NanoXML in favor of a javax.xml backend

IzPack was first created in 2001, a time when there was no standard XML parser in the Java standard runtime (actually this was the very beginning of XML being all the rage!).

IzPack chose to embed a library called NanoXML as it was efficient, very small and it came along with a sensible API. We are now in 2009: there is a standard Java API for XML parsing in every Java runtime, and NanoXML has not been maintained for years. It also started to show some limitations and bugs, such as not supporting XML namespaces and more.

This release is free of NanoXML and instead uses a javax.xml backend. The changes to the existing IzPack code base and third party developments are insignificant as an adapter has been developed, carefully mimicking the NanoXML behavior and preserving the parts of its interface that we were using.

This work was made by Anthonin Bonnefoy and David Duponchel, 2 students from a french computer engineering school called ISIMA in the beautiful city of Clermont-Ferrand.

For the record, Anthonin and David have now joined the IzPack project as developers.

See:

http://jira.codehaus.org/browse/IZPACK-280,
http://jira.codehaus.org/browse/IZPACK-306

Ability to call Java classes before and after each panel

IzPack panels have always been able to perform some custom validation. A typical example is the LicencePanel that vetoes the installation to progress as long as the user has not accepted the license agreement.

Florian Buehlmann has extended the validation mechanism so that a more generalized set of validations can be performed before and after a panel.

See http://jira.codehaus.org/browse/IZPACK-285

Privileges elevation improvements

IzPack is able to perform privileges elevation on various operating systems, as otherwise some installations can fail due to insufficient user permissions.

IzPack 4.2.1 already brought some improvements in this area by allowing the elevation mechanism to be enabled only on certain operating systems (e.g., attempt an elevation only when run on Windows Vista or Mac OS X).

The detection of the current user privileges has been improved on Windows XP and Vista. Also, the uninstaller now avoids privileges elevation when the installer did not perform one. Finally, there was an issue when the installer was started from a Windows UNC path.

See:

http://jira.codehaus.org/browse/IZPACK-217,
http://jira.codehaus.org/browse/IZPACK-347,
http://jira.codehaus.org/browse/IZPACK-308

Graphical reporting of launch-time errors

When an installer is launched, some errors can be encountered before the graphical user interface is up. This results in the end-user not seeing an error nor seeing the installer showing up, unless it was started from a terminal.

Christian d’Heureuse contributed a fix for that, so that an error message shows up graphically.

See http://jira.codehaus.org/browse/IZPACK-318

AntActionListener improvement

Up to now an AntActionListener required the build file to exist on the system to be use as the input to Ant. This limits the beforePack and beforePacks order to only those build files that preexist since at this point of the installation no files have been extracted from the installer packs. This also requires that build files exist on the system even if the Ant custom actions being executed are transient and not needed before or after the installation is performed.

The AntActionListener has been improved to reference a buildresource property that can specify an IzPack resource reference defined by the tag. This resource will be extracted to a temporary file on the system and used as the Ant build file for the AntActionListener. The temporary file will be removed when the installation completes. Using this mechanism, an embedded build file can be now used which does not need to exist on the system before or after the installation.

Note that either the buildfile or buildresource must be provided but not both.

See http://jira.codehaus.org/browse/IZPACK-158

Configuration of the uninstaller path

It was possible to define a customized name for an uninstaller, but it was not possible to customized where it was written. Florian Buehlmann fixed that.

See http://jira.codehaus.org/browse/IZPACK-263

Compile-time variable substitutions

Kjell Braden added the possibility to perform variables substitution in files at the installer compilation time.

See: http://jira.codehaus.org/browse/IZPACK-365

Greetings

The IzPack team would like to thank its developers and contributors for having made this release possible! We would also like to thank our numerous and growing users worldwide for pushing us forward!

Other thanks go to:

The Codehaus Foundation and especially Ben Walding: http://codehaus.org/
JetBrains for their amazing IntelliJ IDEA IDE: http://www.jetbrains.com/
Atlassian for the tools that power some Codehaus services: http://www.atlassian.com/
Sun Microsystems, especially the Glassfish and IPS teams: http://www.sun.com/

Further links

IzPack website: http://izpack.org/
Codehaus space: http://xircles.codehaus.org/projects/izpack/
Mailing-lists: http://xircles.codehaus.org/projects/izpack/lists
Confluence wiki: http://docs.codehaus.org/display/IZPACK
News feed: http://feeds.feedburner.com/IzPack
Subversion repository: http://svn.codehaus.org/izpack/
Git repository (synchronized from svn): http://github.com/jponge/izpack/tree/master
FishEye SVN browser: http://svn.izpack.codehaus.org/
JIRA issues tracker: http://jira.codehaus.org/browse/IZPACK

IzPack 4.3.0 is out!

jponge — Tue, 21 Apr 2009 09:27:34 +0000

I am very pleased to announce the immediate availability of IzPack 4.3.0!

About IzPack

IzPack is a one-stop solution for packaging, distributing and deploying applications. IzPack is opensource, released under the liberal Apache Software License 2.0.

It is fully cross-platform and generates a single installer. As such, it is
an alternative to native solutions such as platform-specific installers and package managers.

IzPack-generated installers only require a Java virtual machine to run.

Many companies and projects have been using IzPack over the years, including Sun Microsystems, JBoss/RedHat, the Scala language project, some ObjectWeb/OW2 projects, XWiki and many more.

Downloading IzPack

IzPack can be obtained free of charge from its website at http://izpack.org/

Getting professional services

IzPack creator and project leader Julien Ponge offers paid professional services:

one-time and subscription-based support
consulting
custom developments
installer creation bootstrap.

Do not hesitate to contact Julien and get more informations from http://izpack.proservices.ponge.info/

Those services directly help in sustaining and improving IzPack.

About this release

About a hundred issues have been resolved in this release. The complete list along with JIRA issues can be reviewed at http://jira.codehaus.org/browse/IZPACK/fixforversion/14763

New features highlights

The release contains its usual set of bug fixes, small enhancements and documentation improvements. The new features include:

Scripting support through the Apache Bean Scripting Framework
Full console manual and automated installations
Removal of NanoXML in favor of a javax.xml backend
Ability to call Java classes before and after each panel
Privileges elevation improvements
Graphical reporting of launch-time errors
AntActionListener improvement
Configuration of the uninstaller path
Compile-time variable substitutions

Greetings

The IzPack team would like to thank its developers and contributors for having made this release possible! We would also like to thank our numerous and growing users worldwide for pushing us forward!

Other thanks go to:

The Codehaus Foundation and especially Ben Walding: http://codehaus.org/
JetBrains for their amazing IntelliJ IDEA IDE: http://www.jetbrains.com/
Atlassian for the tools that power some Codehaus services: http://www.atlassian.com/
Sun Microsystems, especially the Glassfish and IPS teams: http://www.sun.com/

Further links

IzPack website: http://izpack.org/
Codehaus space: http://xircles.codehaus.org/projects/izpack/
Mailing-lists: http://xircles.codehaus.org/projects/izpack/lists
Confluence wiki: http://docs.codehaus.org/display/IZPACK
News feed: http://feeds.feedburner.com/IzPack
Subversion repository: http://svn.codehaus.org/izpack/
Git repository (synchronized from svn): http://github.com/jponge/izpack/tree/master
FishEye SVN browser: http://svn.izpack.codehaus.org/
JIRA issues tracker: http://jira.codehaus.org/browse/IZPACK

A todo list on Google App Engine… Python

jponge — Mon, 20 Apr 2009 08:20:42 +0000

It seems like everyone is getting crazy those days with the availability of Java for Google App Engine. While this is certainly a great addition to the Google cloud computing offering, I remain a bit puzzled on what it means for Java. Indeed:

lots of libraries and frameworks need to be tweaked to run on GAE
there is a whitelist for the classes that you can use, which means no threads, no static files for writing and so on
datastore entries are bound by a 1Mb limit, which means no big uploads in your applications
the effort to support specifications like JPA is great, yet I doubt it will be easy to port existing JPA-enabled applications over GAE as the persistence in GAE is not based on a relational model (which is not necessarily a bad idea by itself!).

Should you care about GAE / Java? My take is that it is a nice cloud computing offering, but if you choose to use it then you should expect to develop your applications specifically for it. Making hybrid GAE / normal webapps is probably worth too many headaches

People should not forget that GAE first appeared with Python, a great language by itself. The GAE Python framework is quite simple to use, while the view rendering part is based on the elegant Django templates.

Just to break with the massive trend toward playing with GAE / Java, I wrote a stupid todo lists manager with the Python flavor:

live at http://jpz-todolists.appspot.com/ (works with your Google account)
code at http://github.com/jponge/pyappenginetodolist/tree/master

Building the application in Python was relatively simple and painless. The only point that annoyed me a bit is the handling of URL mappings, as you need to specify it in your app.yaml and also in your controller class, which sounds like breaking the DRY principle.

The persisted model definition can’t be any simpler:

class TodoEntry(db.Model):
    user = db.UserProperty()
    text = db.StringProperty()

db.UserProperty() allows to link with a Google Account.

Fetching one user todo entries is simple:

entries = db.GqlQuery("SELECT * FROM TodoEntry WHERE user = :userid", userid=user)

Handling the authentication is also very simple:

def authenticate(self):
    user = users.get_current_user()
    if not user
        self.redirect(users.create_login_url(self.request.uri))
    else:
        return user

One last excerpt: rendering a view through a Django template:

values = {
    'userid': user.nickname(),
    'entries': entries,
    'logout_url': users.create_logout_url(self.request.uri)
}
 
tpl = os.path.join(os.path.dirname(__file__), 'todo.html')
self.response.out.write(template.render(tpl, values))

Look at the code, it is quite straightforward and easy to understand, so if you already know Python, don’t forget that GAE / Python works just great too

Scala and DSLs

jponge — Mon, 13 Apr 2009 20:15:04 +0000

Tonight I wrote something quick in Scala to make a small DSL (just for fun).

I started with a small Email class:

class Email(name:String, address:String) {
 
  def standardForm = name + " <" + address + ">"
 
  override def toString = this.standardForm
 
}

which is really stupid: it wraps a name along with an email address, and it adds a convenient textual output form.

Now I would like to be able to write something like:

val me = "Julien Ponge" is "julien" at "gmail.com"
println(me)

To do that I wrote a simple builder:

 
class EmailBuilder(name:String) {
 
  var id:String = ""
 
  def is(str:String):EmailBuilder = {
    id = str
    this
  }
 
  def at(str:String):Email = {
    new Email(name, id + "@" + str)
  }
 
}

then an implicit conversion function:

implicit def emailBuilder(name:String):EmailBuilder = new EmailBuilder(name)

And that’s it.

You should always learn new languages: they are all worth something great! Be polyglot, seriously.

By the way I heard that some of the Scala features are coming to the next major version of Groovy, which is going to be exciting!

IzPack 4.3.0-rc2 released

jponge — Fri, 10 Apr 2009 08:00:41 +0000

See the offcial news.

We need you to:

The full list of changes is available from our JIRA tracker.

Thanks for testing!