Summary
.is that they either try to do too much (but end up doing very little of what you actually want), or theyre 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. Im 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 isnt it? In fact the concept of the Registry was so great (the reality of registering 1000s of components and DLLs wasnt 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 cant take anything for granted. The biggest being the operating system itself, and then theres 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 its 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 dont 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.
Ive 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. Swithins day, (not the twenty nights following St. Swithins day, I hasten to add), I just dont feel its really what end-users want.
To me theres 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 developers machine knows where everything is that the program needs, otherwise it wouldnt 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. Thats 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 its 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.
Ive been working on something like this, and it has been a real eye-opener for me, as its been fun (flexed quite a bit with the swing API, and got a chance to look at HttpClient), and although I dont 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, theres a couple of other goodies in there A Jini configuration editor, so if youre 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-users Jini installation directory is?
The five degrees of separation mentioned was excellent. I beg to differ in that fact that some installations are made too simple; There might be instances where you assume certain things, so that the end user is not bothered much. In fact one of the products I worked on (back in 2000)single button installation was a marketing feature where I had to assume certain things to make it possible. IMO, the target user defines the level of assumptions for the install creator.
>There might be instances where you assume > certain things, so that the end user is not bothered much.
I agree, there are instances, where you can make a number of assumptions and are then able to take the responsibility for knowing what to do away from the user. This is what the regsvr32 and GAC allow on Windows, but Java doesn't even have those central repositories, which is why I think that AIO installation for Java deployment is more difficult than Windows.
> In fact one of the products I worked on (back in > 2000)single button installation was a marketing feature > where I had to assume certain things to make it possible. > IMO, the target user defines the level of assumptions for > the install creator.
But in many cases, installer systems only define one type of end-user.
The problem comes that the more complex and larger the project, the more difficult it is to provide a slick all-in-one installation.
I mean perhaps the goal of all-in-one installation is a worthy one, but most of the current systems don't fulfil that dream.
> 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
Hmmm.... true only if I want my software to fail in strange ways later ! Why ? Because of inherent problems with this approach. My program is referring to ../blah/blah_1.2.jar. User uninstalls (read as deletes) blah application. Boom.... there goes my application along with it - sure to fail with "ClassNotFound" exception. Want more trouble ? User upgrades to blah_2.0.jar and new jar is not compatible with earlier jar. Again, Boom ... I am in trouble. Result : Increased cost of customer support on the least expensive side and losing customers on the more expensive side :(
> Either we put all the stuff that our applications depend > upon into the installer and let it do its thing
Good choice. Anything else is inviting serious trouble later. Users curse my app, my installer and me. Again, same result ... increase customer support cost and/or lose your customers !
> a couple of clicks will start an > automatic download, and install (or copy) to
Don't forget resuming partially downloaded stuff ... least painful way is the path to take :)
> > 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 > > Hmmm.... true only if I want my software to fail in > strange ways later ! Why ? Because of inherent problems > with this approach. My program is referring to > ../blah/blah_1.2.jar. User uninstalls (read as > deletes) blah application. Boom.... there goes my > application along with it - sure to fail with > "ClassNotFound" exception. Want more trouble ? User > upgrades to blah_2.0.jar and new jar is not > compatible with earlier jar. Again, Boom ... I am in > trouble. Result : Increased cost of customer support on > the least expensive side and losing customers on the more > expensive side :( > > > Either we put all the stuff that our applications > depend > > upon into the installer and let it do its thing > > Good choice. Anything else is inviting serious trouble > later. Users curse my app, my installer and me. Again, > same result ... increase customer support cost and/or lose > your customers ! > > > a couple of clicks will start an > > automatic download, and install (or copy) to > > Don't forget resuming partially downloaded stuff > ... least painful way is the path to take :)
Think I agree with this post. If the users are savvy enough to be tweaking dependencies & classpaths, they can do it via a route other than the installer. They can just figure it out, or you could provide them instructions or another tool.
Seems better to keep the installation simple & fail-safe (because you've packed everything required ), even at the cost of flexibility.
> > Either we put all the stuff that our applications > depend > > upon into the installer and let it do its thing > > Good choice. Anything else is inviting serious trouble > later. Users curse my app, my installer and me. Again, > same result ... increase customer support cost and/or lose > your customers !
I agree in some ways, if some or all of these are true a) You have unlimited bandwidth and diskspace on your servers and thus large singular downloads are not a problem b) You are producing a commercial product and thus can create CD's etc of your product c) You have redistribution rights/license to any software your product uses, and can thus package it
But I don't believe, especially in the arena of open source, that this is always the case.
My point is if only a single file in your product changes between upgrades and your product is 2MB in a package of 20MB, do your users really want to download another 20MB
> > a couple of clicks will start an > > automatic download, and install (or copy) to > > Don't forget resuming partially downloaded stuff > ... least painful way is the path to take :)
Previous Topic
