Ozibug - web based bug tracking


  1. Introduction
  2. Advantages & Disadvantages
  3. Software
  4. Configuration
  5. Conclusion
  6. About the author
 

The demand for cross platform development and test environments has increased dramatically in recent times. This is due directly to the influence that Java has had on the software development process. Where once an internationalized, multi-platform application was complicated and expensive to develop, Java and the technology available today (and perhaps its cost) has simplified the process.

Indeed the cross platform environment has now become the holy grail of environments for the professional Java software engineer, providing them the means to design, code and test a very robust application. While this methodology has been a must for startup companies allowing them the maximum target audience (and customers) it is also becoming popular for established companies wishing to increase their existing applications marketshare.

So just what is a cross platform development environment ? Exactly that - a development environment that allows users to login and work on the same project using different platforms. So someone can compile on Windows, develop and debug under the Netbeans IDE on Solaris and test and deploy on Mac OS X.

 
Back to top
 

Before getting too involved and swept away on the hype, the following sections outline the advantages and disadvantages of the cross platform development environment.

Advantages

  • Flexibility

    A cross platform development environment allows you to maximize the use of all your resources. This can include everything from your workstations and servers to their disk space and cpu cycles.

  • Strength

    Developing with a cross platform development environment allows you to choose the development strategy to suit your needs. This strategy may be carrying out the bulk of the development on a single platform and then testing against multiple platforms once development is complete; Or it may be developing and testing on different platforms concurrently.

    Once configured correctly you can easily test with different versions of the JVM, J2EE Container and support applications and libraries such as log4j and jdom.

    Either way the end result is a much more robust product that is guaranteed to work across the range of environments.

  • Staff

    When you can offer a developer their choice of development platform you end up with a happy developer. This is important in attracting and retaining staff and also keeps ramp-up costs to a minimum. Some staff may even learn to develop across multiple platforms advancing their own knowledge and making them a key staff member.

    Xtreme programming has the focus on the person, not the software, this methodology is validated when the developer is free to choose a platform rather than being dictated to by out-of-touch management and their procedures.

  • Location

    One of todays requirements is that the location of staff and resources does not hinder the development process. A cross platform development environment helps achieve this goal by not only organizing the resources but also the access to them in an independent manner.

  • Operations

    Certain operations such as system and data backup become simpler as resources are often grouped together. Upgrade of applications or libraries then becomes much simpler too.

Disadvantages

  • Not everyone knows everything

    You will still come across problems where no-one knows the answer. An example of this is when something works on one platform but not another. Windowing or Look and Feel problems fall into this category.

  • Common resources are still required

    If your application uses a database - then you'll still need a database. If your application uses a specific piece of hardware, then you'll still need this piece of hardware (or a simulation of it.)

    If you organise the databases, schemas and tables properly (or rather the configuration and access to them) then the common resources will be easier to manage.

  • Platform ignorance (well it works for me syndrome !)

    Some developers will not come out of their platform shell. If it works for them then thats just fine and everyone else has a broken platform !

  • Additional Configuration Management (eg, line terminators)

    More care and thought must be taken about file types, line termination and keyword expansion. A binary file is only a binary file when it can be checked into and out of your CM system as a binary file. Once multiple, different platforms are involved a little extra thought about the CM system must be carried out.

    Developers that have been confined to one platform will suffer from this.

  • Additional build and boot scripting

    Not only will you need shell scripts to setup your environment, you'll also need .bat files ! You'll also need scripts to mount directories, configure packages, set properties, variables and flags all based on the platform type.

Back to top
 

The following sections describe the software tools you'll need to make your development environment work smoothly. It is by no means a full or complete list of software (there's always one more application you need!) but does include the most major pieces or types of software.

  • NFS/Samba

    This is the backbone of the environment. The file server should be a Unix System running both NFS and Samba. The exported file systems can then be mounted or mapped with any type of client. The filesystems can be backed up to tape and will hold all common areas, such as the user homes, project directories and common tools and libraries.

  • CVS (jCVS, WinCVS, TkCVS, jCVSlet)

    CVS is your friend, it has been around for years, is stable, tried and tested. There are so many client, extension and addon software packages it is sometimes confusing. I'm sure that every platform known to mankind must be supported though so this is a sensible choice. There are also CM systems being developed now which use CVS as the base CM system !

  • JDK/JVM

    Sun is also your friend, they have jdks and jres to suit everyone. These should be downloaded and installed in a common fashion to make maintenance easier. You can also find variants such as IBM's jikes which is often used when speed is important.

  • JUnit/HttpUnit

    These packages supply the test infrastructure.

  • ANT

    ANT is the ultimate build tool which can also do a whole lot more. From compiling java to starting up a J2EE container this is a necessary piece of the environment.

  • Continuous Integration (CruiseControl, Anthill)

    If you're doing Xtreme Programming then this tool is necessary to carry out the continuous integration of code and tests from each and every developer.

    Don't be mistaken though, you can also use this tool to carry out a nightly build during the standard development period of your project (what have you forgotten your basic software engineering principles already ?)

  • Bug Tracking (Ozibug, Jitterbug, Bugzilla)

    Perhaps one of the most forgotten aspects of software development is bug and issue tracking. You must be able to track issues and problems, not just the ones that your customers have but the ones that your developers encounter during development.

    A good bug tracking tool can also be used for capturing and sharing ideas. This promotes a much better environment that can help anything from design ideas to ramp up of new staff.

  • Mailing list software, Webmail

    To integrate applications you can use mailing list or forum software. For example you can plumb CVS into a mailing list so that each time a change is committed to the repository the developers are informed and can check its validity.

  • Editors (Vim, Emacs, Netbeans, JBuilder)

    There are more arguments are over editors than any other piece of software. This is because most developers spent most of their time in this type of application. It is essential to be able to supply the favourite editor of a developer to maximise their productivity.

    With a little forethought a coding standard (or pretty printer) can make the mandate of a specific editor redundant.

  • Web Browsers (Mozilla, Netscape, Opera, IE)

    Any web development usually means that a full range of browsers should be employed for testing. How many times have you come across a web site that doesn't work with your combination of browser and operating system ? This problem is much more common than you would think, simply use a browser other than Microsoft Internet Explorer and visit some E-Commerce shopping or banking sites !

  • VMWare

    This application can relieve the problems of resource poor development departments. It allows you to run a whole operating system inside of itself making the need for additional hardware redundant. This opens up a whole load of possibilities that I wont go into here. It can resolve issues, or rather its user can resolve issues of multiple versions of the same browser not working on the same platform, multiple outdated operating systems not being supported and much, much more.

  • Resources Page

    Every project should have a web site where the relevant documentation is available to everyone. This doesn't even have to be served from a web server, it could be a collection of flat files on one of the shared drives which is available to everyone.

    This resource page should include the Javadoc of the developed product (perhaps doxygen output if not a Java project.) The Home pages and associated web-sites of tools and APIs being used, as well as relevant web-sites (such as standards bodies.) It should also include procedures that you develop as you go such as testing, bug fixing and perhaps general knowledge base types of things.

Back to top
 

This section gives general tips on setup and configuration of the computers and software. Again this is not a complete guide as one configuration cannot suit everyone.

  • Servers, filesystems and clients

    The trick to the configuration is to get everything loaded on the servers and nothing loaded on the clients. The clients can then map or mount the common drives and directories which contain the necessary packages such as CVS, Java, etc. The secret is making sure each client uses the correct package for its architecture, ie. a Sun Sparc machine can't run Intel Linux executables !

    Create the largest possible partition on your Unix server. You may have to reload the OS to do this or you may want to add another disk. (As a preference you may want to create several partitions, one for each major area.) You can now export these partitions with major common areas on them such as projects, packages and homes.

    Client machines can now mount or map these shared filesystems automatically on boot. On Unix systems you have a script which will create an architecture dependent string such as linux-2.4.18-unknown or freebsd-4.5-i386 and then use this variable to mount the target directory to a common location. A Bourne shell example of how to create such a string is given below.

    OS="`uname -s | tr '[A-Z]' '[a-z]'`"
    REL="`uname -r | sed 's/[^0-9]*\([0-9][.0-9]*\)[^0-9]*.*/\1/'`"
    ARCH="`uname -p`"
    ID="${OS}-${REL}-${ARCH}"
    export ID
                              

    The scripts can now use the ${ID} variable to reference the correct architecture. Win32 machines can have their architecture variable configured to the value win32 but will only usually need this variable in the build bat files.

    So now you have common filesystems being shared by all clients. Each user can access the same directory structure and files no matter what client machine they login to.

  • CVS

    You should export your cvs data through the CVS pserver method. This involves setting up the CVS software as a service on one of your designated servers. To do this you'll need to create a cvs user and group, configure the cvs repository and then plumb in the CVS pserver into the Unix inetd daemon.

    Once configured all clients should be able to access and checkout the project data to a common drive. Note: some CVS clients are filebased and need to see the CVS repository as a filesystem. In this case you might want to share the repository as a filesystem.

    It cannot be stated strongly enough that the CVS repository must be backed up regularly !

  • Java packages

    You install the software packages into a common directory which includes the version number in the directory name. So you would install the JUnit package into the following directory.

    /packages/junit-3.7
                              

    You then install a symbolic link to the version numbered directory so now you have.

    /packages/junit-3.7
    /packages/junit -> junit-3.7
                              

    This then allows project build and property files to reference the package without the version number. Projects that need a specific version can use the versioned package name. Upgrading from one version to another becomes as easy as installing the new package in its versioned directory and then updating the symbolic link.

    /packages/junit-3.7
    /packages/junit-3.8
    /packages/junit -> junit-3.8
                              
  • JDK configuration

    While the above section deals with Java software packages that can be referenced identically on different platforms a slightly different approach is needed for architecture dependent packages such as a JDK.

    With this style of package an architecture specific string should be included in the installed directory.

    /packages/jdk-1.2.2_014-linux-2.4.18-i386
                              

    You then install a symbolic link to the version numbered directory so now you have.

    /packages/jdk-1.2.2_014-linux-2.4.18-i386
    /packages/jdk-1.2-linux-2.4.18-i386 -> jdk-1.2.2_014-linux-2.4.18-i386
    /packages/jdk-linux-2.4.18-i386 -> jdk-1.2-linux-2.4.18-i386
                              

    This then allows project build and property files to reference the correct package package for its architecture (by using the its architecture string - see above.)

    To add different versions of jdk such as 1.3 and 1.4 install into a versioned directory and simply add the correct symbolic links.

    /packages/jdk-1.2.2_014-linux-2.4.18-i386
    /packages/jdk-1.3.1-linux-2.4.18-i386
    /packages/jdk-1.4.0-linux-2.4.18-i386
    /packages/jdk-1.2-linux-2.4.18-i386 -> jdk-1.2.2_014-linux-2.4.18-i386
    /packages/jdk-1.3-linux-2.4.18-i386 -> jdk-1.3.1-linux-2.4.18-i386
    /packages/jdk-1.4-linux-2.4.18-i386 -> jdk-1.4.0-linux-2.4.18-i386
    /packages/jdk-linux-2.4.18-i386 -> jdk-1.2-linux-2.4.18-i386
                              

    The project files can now be set to the correct platform architecture and jdk version. Note: these examples have the linux kernel revision number in them. This may not be appropriate for your situation.

    To quickly flip between versions of the JDK (on Unix anyway) you can set all references of the jdk to a local directory such as ${HOME}/local/java and then make this a symbolic link to the shared directory. You can then setup a macro or shell script to change the local symbolic link to the desired jdk, version and platform architecture.

    When these symbolic links are exported through Samba they appear as directories and thus the win32 clients are able to access them.

    /packages/jdk-1.2.2_014-win32
    /packages/jdk-1.3.1-win32
    /packages/jdk-1.4.0-win32
    /packages/jdk-1.2-win32 -> jdk-1.2.2_014-win32
    /packages/jdk-1.3-win32 -> jdk-1.3.1-win32
    /packages/jdk-1.4-win32 -> jdk-1.4.0-win32
    /packages/jdk-win32 -> jdk-1.2-win32
                              

    So assuming that the /packages directory is mapped on the p drive you can reference the jdk by setting environment variables similar to the following in build scripts, etc.

    set JAVA_HOME=p:\jdk-win32
    set PATH=%JAVA_HOME%\bin;%PATH%
                              
  • Other packages

    If the packages contain platform specific executables then they can be handled in the same was as the JDK described above. If they contain simple Javadoc documentation then they can be handled in the same way as the java packages described above.

Back to top
 

While there are many configuration possibilities, only the basics are described here, allowing you to use this as a starting point for your implementation.

Variations of the configuration that I have worked with have included ones where a whole tool set (jdk, ant, junit, etc) has been checked into CVS. Different versions (and combinations) of the tool set could be checked out and used by each client. The advantages of this configuration was to have the toolset installed (and running) locally to each client, while reducing the upgrade complexity as well as controlling the whole environment while allowing full access to the packages. The disadvantages included the time to checkout the toolset, and the disk space necessary for each client.

Many software tools and libraries have not been included in this document as the tool set necessary will depend on the software being developed and the development process and practices in place.

There is no doubt in the advantages of a Cross Platform Development Environment, the configuration best suited must be learnt through implementation and use, the disadvantages being mitigated through experience.

 
Back to top
 

Graham Crawford is one of the founders of Tortuga Technologies, a software development company based in Brisbane, Australia. He has over 20 years experience across a wide range of companies in the UK, USA and Australia.

He is currently involved in the development of Ozibug, a web based bug tracking system. Ozibug is implemented as a Java servlet allowing it to be run on any platform for which a JVM and servlet container is available. In keeping with the spirit of quality software development, each version of Ozibug is tested on over 50 Servlet Container/JVM/Operating System combinations before release.

 
Back to top
 
Back