Developers of the InstallAnywhere community would be very much familiar with the terminology "Developer Installation Manifest" commonly refereed as DIM.
InstallAnywhere provides the installation developer add addition pay load to their projects without adding any rework or hassle. The use of DIM proves to be of great importance if the application is developed by a large team across multiple sites. The process of packaging and requirement gathering proves to be very tedious and error prone. Due to lack of communication or insufficient knowledge many a times small bugs are introduced to the application package in the form of extra files/files missing/non registration of OCX etc.
Now imagine if theres a way the application developers who are writing the actual software do not require to communicate the list of file to be shipped in the required directory structure :) , imagine if the developer can test his standalone package while debugging or testing his application in stand alone mode. That to the developer does not require to this into an xml with any common text editor, all he/she has to do is to use his frequently used dev IDE eclipse or .NET editor! Seems cool ..... But how????
InstallAnyewhere allows to install plugins to commonly used development IDE's currently Eclipse and .NET IDE, these plugins allow the application software engineer to author to create DIM's which contain source and target locations of the file needed to run his component . All he needs to do is to identify the files and folder source location and needs to provide the target location on the end machine where it is going to be installed. This DIM can be plugged into the main project owned by the installation author or the Build/Release engineer. This gives the development team the sense of ownership of the application files owned by them and reduces the cost of maintenance and authoring to a large extent.
If will be asked to rate features and benefits of DIM over the traditional benefit of adding the files and folder into the main project I would give it a 10 on 10.
I am listing down some of the key benefits of the DIM below
1. DIM's allows the flexibility to be updated and owned by individual developers
2. It creates sufficient data encapsulation to the rest of members of the project
3. Developers can add files and folders inside the DIM
4. They will have option to register the ocx and dll if required wihin the DIM
5. Environment variables can be created inside the DIM
6. Group functions can be assigned inside the DIM
7. DIM's can be build and tested in a stand alone mode there by reducing the build time and ease for the developer to test his/her application
Above all features are definitely a great boon for the developer and build engineers of distributed and gigantic applications
I have also observers some of the major issues with InstallAnyhwere collaboration plugin in Eclipse. They are big issues but still can be lived with, here are some of them.
1. If the folder addition feature in the DIM is given some filters to add the contents of the DIM, it cannot be build and gives some weired exception. The possible workaround for this issue is to add the folder as a speed folder inside the main project and then give constraints or filters
2. Files need to be physically present at the source location if you are trying it to add in the DIM. The possible work around for this issue is to create a dummy file at the specified source location using touch utility or its equivalent on any OS
3. The installer output of the DIM can not be used in a stand alone mode for the customer purpose as it shows a warning message that "This installer has been built using a collaboration tool and hence should not be used to production"
4. The most big issue is that all the plugins that are installed and used has to be compulsorily have a valid license for its use(i.e if you have a team of 100 people who will be writing DIM's for their small software piece you need to actually have 100 licenses). The only available workaround for this problem is to install IA collaboration tool on a common machine where all the developers are going to have access and each of them will be authoring their individual DIM at different point of time :(
All of the above pros and cons have taken me to the conclusion that DIM's are of great use if used efficiently and with proper planning.
