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!
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)
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("<a>More informations...</a>"); 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.
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
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.
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.
IzPack can be obtained free of charge from its website at http://izpack.org/
IzPack creator and project leader Julien Ponge offers paid professional services:
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.
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
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.
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
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).
This great work was contributed by Mounir El Hajj.
See http://jira.codehaus.org/browse/IZPACK-320
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
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
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
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
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
Note that either the buildfile or buildresource must be provided but not both.
See http://jira.codehaus.org/browse/IZPACK-158
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
Kjell Braden added the possibility to perform variables substitution in files at the installer compilation time.
See: http://jira.codehaus.org/browse/IZPACK-365
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:
