Summary
….is that they either try to do too much (but end up doing very little of what you actually want), or they’re so miniscule there isn't one.

---

Advertisement

If you take a look at the state of play in general installer products, you find they are the one last bastion of the ‘take care of everything so you just have to click it’ mentality that survives outside of Microsoft. I’m not saying that taking care of things in order to support the smooth installation of a product for your users is always a bad thing, just that sometimes it misses the mark.

The big problem with recent installer systems is that they were traditionally founded on Windows platforms, where nearly everything was a known factor – the registry, environment variables, etc, etc. So if you wanted to install a COM component, you used regsvr32 or whatever your chosen dose of binary hell happened to be at the time. And all though everybody eventually crosses the line and begins to despise the registry, whether you know it or not (Does Add/Remove programs, showing applications you uninstalled three months ago, sound familiar?), the point is that the registry was a known point of intersection between the end system and the product developers – Windows developers just know you have a registry. Spooky how they know that isn’t it? In fact the concept of the Registry was so great (the reality of registering 1000’s of components and DLL’s wasn’t so great, though) that Microsoft decided to use the concept again for the .NET GAC (Global Assembly Cache, in this context, kind of similar to the HKEY_CLASSES with versioning)

With Java, the general concepts and ideas used in installers have replicated from the Microsoft world. However, you can’t take anything for granted. The biggest being the operating system itself, and then there’s the file systems, etc, etc. Java has nothing like the GAC, sure we have the endorsed directories, but those are the sanctity of ‘things that do special stuff’ and are not to be messed with by us mere mortals. In fact, the classpath allows us to specify any jar or directory for use with our programs. Which is good because we can have different versions of the same library in different files or directories, and we only have to specify what we need; the difficulty comes from that we have to know what we need. And this brings me back to my point about installers.

Either we put all the stuff that our applications depend upon into the installer and let it do it’s thing, however we run the risk, especially in the open-source enabled, internet savvy world we live in today, that we make our installations bloated and that people will already have the files that we bundle anyway, or that the installation systems we use to build the installers don’t actually provide the low-level configuration we need; or we provide intricate step-by-step instructions about where to download files and how to change batch scripts that we think people can follow, but if they're not developers themselves, they nearly always get mixed up.

So either we make things too simple for people, but find we have to make compromises because of the installer architecture, or we think the user to be a programmer ‘like us’ and assume too much of them.

I’ve messed around with installers, and as much as I would really love to put nice little installation pages that allow me to nicely enforce my restrictive license scheme that I myself thought up, that only allows you to run my product if you happen to be called Zebedee and your trial will only work for the twenty days following St. Swithin’s day, (not the twenty nights following St. Swithin’s day, I hasten to add), I just don’t feel it’s really what end-users want.

To me there’s five degrees of separation between the developer and the end-user, and at each stage the developer knows less and less about the target platform, and some mechanism has to take the responsibility instead.

• Build – The developer’s machine knows where everything is that the program needs, otherwise it wouldn’t compile, run and be tested properly. Your IDE will probably be running your code, or you will have batch or ant scripts, tailored to your particular environment.
• Release – The developer uses a product like Ant, Maven or CVS to build a binary snapshot (jar) of the product bubble i.e. ignoring any outside libraries, abstracting away dependencies on outside files.
• Package & Post – The installation medium is created. Often the release and package steps can be merged together, although here more thought is given to the end-user system, creating Windows EXEs, Executable Jars, etc. Generally, any ancillary files, such as configuration are added with the binary snapshot, and, possibly, bundling of JREs.
• Installation – The end-user downloads the code, and installs it onto their machine. That’s it. Installation is about unpacking the product and getting it onto the machine.
• Configuration – The final part of the release cycle, should be the software being configured to sit correctly within the end-users environment, and informing the user of any prerequisite libraries they may need in order for the software to complete it’s function properly.

You see, to me the problem with do-it-all installers is that configuration is not a part of installation. If we presume to make configuration part of installation, we over-simplify it and make too many assumptions, like bundling libraries in, and not allowing users to specify locations of libraries that, dare I say it, they wish to use with our products. Combining installation and configuration seeks to maintain control with the product developer, not the actual person installing it.

I would argue that the better of the two ways is the ‘Script Instruction’ route, where we inform users how to change the classpath etc, and the dependencies of our products, but the danger here, as I mentioned above is that we can assume too much of the person installing the code.

What is needed is not a program that leads the way for the user, not letting them make the important decisions that they actually want to make, but something that actually helps the end user get the product onto the system (installation) and, as a separate phase, guides them in configuring the product the way they want to, but also takes away the hassle of getting these other libraries and dependencies.

I’ve been working on something like this, and it has been a real eye-opener for me, as it’s been fun (flexed quite a bit with the swing API, and got a chance to look at HttpClient), and although I don’t think it not nearly easy enough to use yet, it can build an executable Jar installer in about three seconds, and allows you to set specific pre requisite locations and if the user discovers they need these libraries a couple of clicks will start an automatic download, and install (or copy) to a user-specified location, even handling multiple concurrent downloads, updating the classpath for the batch scripts automatically as each file is downloaded and unpacked. Of course, there’s a couple of other goodies in there – A Jini configuration editor, so if you’re installing a Jini service, you can specify things like your codebase, policy and JAAS files, and manage a set of Jini configuration files. Then, when you click on the ‘Generate’ button, it automatically merges all your .bat or .sh files, customises the classpath to fit your environment, and sets up your configuration files.

And all of this came out of one simple problem for Jini project installations, “Just how do I know where the end-user’s Jini installation directory is?”

Talk Back!

Have an opinion? Readers have already posted 6 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Calum Shaw-Mackay adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Calum Shaw-Mackay is an architect on Java and Jini systems, working in the UK. His interests lie in distributed computing, adaptability, and abstraction. Calum has been using Jini for longer than he would care to mention. His main area for taking the blame (some people would call it 'expertise') is systems integration and distributed frameworks, and is an advocate of using Jini's unique strengths to build adaptable enterprise systems. His opinions are his own. He's tried to get other people to take his opinions off him, but they just won't.