Every time I set up a new developer machine or have a new developer join the team, the time it has taken has been a constant source of frustration. Even after they have been set up, maintaining installations and ensuring that everyone is using the right versions of software can become troublesome. Everyone having to configure the different applications is also a waste of time.
Keeping an image of the disk is one solution, but it is not practical for maintaining the development software because of the time it takes to restore - and it's overkill if you just want to restore the development tools. It also doesn't allow for flexibility in configurations, or for frequent changes.
As a primitive solution to this problem, I started manually maintaining a collection of tools and distributed it as a large zip file that developers could unzip into a standard location. But I realised that the scripts I was writing could easily be generated and the maintainence significantly reduced by writing an installer program. An installer would allow the process to be more efficient and possibly automatic.
Advantages
Disadvantages
Current status (October 2005)
Future direction
A toolset is defined by an xml file and groups individual tools together.
A tool is distributed as zip or exe file which is served from a tools repository via a web server. This archive will be downloaded and cached locally by the installer.
For each toolset, a setup-env script is created which sets up environment variables which include a home variable for each tool and configures the PATH.
For each tool you can define:
Each tool can define a URL that points to the archive somewhere out on the internet. This will only be used if the archive does not exist in the repository.
The repository url for a tool is made up by concatenating:
So, given the tool definition below, and if the installer is run with -i -r http://localhost/tools-repo the installer will first try
If not found there then it will try
If that doesn't exist it will fall back to (if internet downloads are allowed via the switch -i)
<tool> <name>Tomcat</name> <id> <groupId>org.apache.jakarta.tomcat</groupId> <version>5.5.9</version> <artifactId>jakarta-tomcat</artifactId> <url>http://archive.apache.org/dist/jakarta/tomcat-5/v5.5.9/bin/jakarta-tomcat-5.5.9.zip</url> <type>zip</type> </id> <wrappers> <wrapper> <target>bin/startup.bat</target> <alias>tomcat-start</alias> <shortcut>Tomcat Start</shortcut> <changedir>true</changedir> </wrapper> <wrapper> <target>bin/shutdown.bat</target> <alias>tomcat-stop</alias> <shortcut>Tomcat Stop</shortcut> <changedir>true</changedir> </wrapper> </wrappers> <shortcuts> <shortcut url="http://localhost:8180/manager/html" name="Tomcat Manager"/> <shortcut url="http://localhost:8180/tomcat-docs" name="Tomcat Docs"/> <shortcut url="http://jakarta.apache.org/tomcat/" name="Tomcat Home"/> </shortcuts> </tool>
Toolsets can depend on other toolsets (which must be defined in the same repository) using the depends element. In this example, when installing 'common' then 'base' will be installed first.
Toolsets can also have an associated 'modification' zip file. This archive is extracted over the top of the installed toolset and is useful for adding files or modifying the original files provided by the tools. You may for example want to:
<toolset> <name>common</name> <depends>base</depends> <modification> <id> <groupId>swpr.modifications</groupId> <artifactId>common</artifactId> <version>1.0</version> </id> </modification> <tools> <tool> ... </tool> ... </tools> </toolset>
The repository can be laid out in any format you like since the urls are built up from whatever you use in the tool definitions. However, the following is a suggested example layout which uses sub directories based on the domain of the product.
repositoryroot/ tools/ org/apache/jakarta/tomcat/ jakarta-tomcat-5.5.9.zip jakarta-tomcat-4.1.31.zip org/jboss/jbossas/ jboss-4.0.2.zip com/sun/java/ j2sdk-1.5.zip j2sdk-1.4.2_04.zip j2sdk-1.3.1_09.zip com/jgoodies/jdiskreport/ jdiskreport-1.2.2.zip jdiskreport-1.1.zip toolsets/ common.xml appserver.xml development.xml utilties.xml ...
The archives must be zip or exe files. That is how most java applications seem to be distributed anyway.
For example, the apache-ant-1.6.2-bin.zip contains everything in the apache-ant-1.6.2 directory.
Note that in some cases, the providers of tools do not package them appropriately. In these cases, you can manually create the zip and put it in your repository. For example, the JDK is distributed as an exe. This can be installed manually, then zipped up and put into your repository.
You may want to add each of the installed toolsets directories to your path. This way, you can run the wrappers directly from your command prompt. This is useful for those tools that you will not be accessing through a shortcut but rather, from the command line (such as ANT and Maven).