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