Introduction

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

  • Easy installation and re-installation of collections of tools
  • Standardised setups within and across teams
  • Repeatable and consistent

Disadvantages

  • Does not handle programs that need to be run through an installer (which add entries to the Windows registry etc)

Current status (October 2005)

  • Basic features - enough to be useable
  • Only supports Windows (Linux will come later if there is interest)
  • Basic command line interface

Future direction

  • At the moment it is basically functional enough to be useful to me. If other people find it useful then there would be scope for:
    • Providing Linux/Unix support
    • Swing user interface and WebStart installation
    • Provide more control and feedback in the UI
    • More features to make configuration of the toolsets easier and flexible

Note

  • This application requires Java 1.5 or higher.
  • Currently it only supports windows targets, but if there is interest it can be easily extended to Linux

Basic principals

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:

  • wrapper scripts which first call the setup environment then run another command - usually a script inside the tool itself.
  • directories to be added to the path in the setup environment script.
  • shortcuts to be added to the tools shortcut directory.

Tool Definition

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:

  • the repository url provided when running the install client
  • groupId (substituting . for /)
  • [artifactId]-[version]
  • the artifact type (i.e. zip)

So, given the tool definition below, and if the installer is run with -i -r http://localhost/tools-repo the installer will first try

  • its local repository (user.home/.toolsinstaller/tools/org/apache/jakarta/tomcat/jakarta-tomcat-5.5.9.zip)

If not found there then it will try

  • http://localhost/tools-repo/tools/org/apache/jakarta/tomcat/jakarta-tomcat-5.5.9.zip

If that doesn't exist it will fall back to (if internet downloads are allowed via the switch -i)

  • http://archive.apache.org/dist/jakarta/tomcat-5/v5.5.9/bin/jakarta-tomcat-5.5.9.zip
    <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>

ToolSet Definition

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:

  • add web applications to Tomcat
  • change the JBoss log4j.xml
  • provide a ready configured database for Apache Directory Server
  • ...
    <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 and the archives

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.

After installation

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).