In a previous article we demonstrated how to setup a Linux server to use Maven, the primary Java build tool. Now we’ll look at how to use Hudson to provide continuous integration to your build environment. Just what is continuous integration? Think of it this way: you have a team of developers who are all busily committing code to your source code repository. Each developer is focused on his or her role, or area of functionality, for the system being developed. A continuous integration (CI) engine is an automated build system that checks out the most current code from the source code repository, builds it, and makes the resulting artifacts available for download and/or review. It’s also a great way to see if the entire system is, in fact, compilable. More often than we’d like to admit, developers check in their code without checking for compile errors – creating a problem for others in the team who update their local sources to the trunk, only to find the system no longer compiles! The Continuous Integration Engine can be linked to a mailing list to notify developers that the build has failed. Additionally, it can show a “diff” of what has changed since the previous build, so users can see exactly who the culprit is – and follow up with merciless ridicule.

So why use Hudson to create a continuous integration server? There are certainly other CI engines out there, such as the primary open source rivals to Hudson: Apache Continuum and CruiseControl.  Some good commercial CI engines are also available, but those are beyond the scope of this article.

We’ve worked with both Continuum and CruiseControl in the past, and consider them to be functional – in an adequate sort of way. Continuum’s web-based front-end isn’t bad, and for the most part it does what it’s designed to do. We’ve found CruiseControl to be more competent than Continuum when it comes to stability, although we must admit that we have not tried any of Continuum’s newer builds. But when it comes to ease of configuration Hudson wins, hands down. If, like us, you’re visually-oriented, and if you find it painful to edit an XML file to configure CI (as is the case with CruiseControl), Hudson’s graphical user interface just makes perfect sense.

Interested readers should be able to find more detailed comparisons of CI engines (like this one) with a quick search, but our conclusion – based on a combination of first-hand experience and other people’s opinions – is that Hudson is the current front-runner among open source CI engines.

Before You Start

You’ll need to be proficient in  Maven and Subversion before you continue. The principle here is to have a mock application hosted in a Subversion repository. We’ll then download and configure Hudson to access the Subversion repository, and perform continuous integration builds from there. We’ll assume you already have Maven configured. If not, have a look at the tutorial titled Creating a Maven-Based Development Environment on Linux. You’ll also need to have an accessible Subversion server set up somewhere.  If you don’t, a good place to get started is at http://subversion.tigris.org/faq.html#repository.

Meat & Potatoes

Creating a Test Project

Let’s start with a software project for illustration purposes. For this, we’ll use Maven to generate a project with one simple command:

mvn archetype:generate

You’ll be asked to select an application type to generate. Let’s go with a simple web application. Choose option 18. Then enter the following information into the prompts:

Define value for groupId: : com.example
Define value for artifactId: : testWebApp
Define value for version:  1.0-SNAPSHOT: : [Press Enter]
Define value for package:  com.example: : [Press Enter]
Define value for package:  com.example: :
Confirm properties configuration:
groupId: com.example
artifactId: testWebApp
version: 1.0-SNAPSHOT
package: com.example
 Y: : [Press Enter]

Good job. You now have a fully functional web application that does very, very little indeed. You can compile and execute it for test purposes like this:

cd testWebApp/

mvn -Djetty.port=9999 org.mortbay.jetty:maven-jetty-plugin:6.1.18:run

The reason we use port 9999 is because we have other web applications already running on our machine. Point your favorite web browser to http://localhost:9999/testWebApp and you’ll be greeted by the now famous “Hello World!” greeting. Excited yet?

Importing the Test Project into Subversion

Next we need to import our new project into Subversion. We don’t want to import any generated artifacts so we first perform an mvn clean operation.

mvn clean

cd ..

su

# svnadmin create /var/lib/svn/repositories/testWebApp

# cd ..

# svn import testWebApp file:///var/lib/svn/repositories/testWebApp -m "initial import"

Now remove your existing webapp directory, and check it out from Subversion.

rm -rf testWebApp

svn checkout svn://armor.osdcorp.com/testWebApp

Your Subversion repository will obviously be different. Substitute the svn://armor.osdcorp.com part with your configuration.

In a normal team development environment, your team would now joyfully check out the source from Subversion, make changes, and check them back in. Let’s shift our focus to the role of Hudson, our continuous integration engine of choice.

Downloading and Installing Hudson

To download Hudson:

wget http://hudson-ci.org/latest/hudson.war

Simple as that. Now, to execute it you have two options. You can either drop it into a Servlet container like Tomcat, or you can simply start it up like this:

java -jar hudson.war --httpPort=8075

Again, due to our system already running certain web applications, we can specify an alternate port. Point your browser to http://localhost:8075 and you should be rewarded with the following:

We’ll need to do some basic configuration first. Essentially, we need to tell Hudson where the JDK and Maven reside. Click on “Manage Hudson”, then “Configure System”. In the resulting screen, configure the locations respectively. This is what it looks like on our server:

Next, make sure you have configured the “Hudson URL” at the bottom of this configuration screen. You need to change it from “localhost” to the actual hostname of your server. Something like this:

Excellent. Now click “Save”, and then click on the “New Job” link in top left corner of the page and fill out the resulting form as we have below:

Continuing from here, a more detailed page of your project is available:

Continued…

Some explanation is required here. Hudson has various methods of deciding when to perform a build. These are called build triggers. The method we have chosen here is to poll Subversion every minute. If anything has changed, we perform a build. Other trigger mechanisms exist internally to Hudson. We say internally because there is one other important method to trigger a build. An HTTP GET on http://localhost:8075/job/testWebApp/build will trigger a build from an external source. How is that useful? You could use the Wget utility to trigger that URL from the command line or a shell. It’s particularly handy if you use the Wget command on the URL from within a Subversion post-commit hook. So: every time someone commits a change to your source code repository, a build will be performed automatically. In this way we eliminate the wasteful polling of the Subversion repository by Hudson itself.

Let’s go ahead and set up the post-commit hook now. But first, go back into the testWebapp Hudson job configuration and uncheck the “Poll SCM” checkbox. Then click “Save”. Now we’re ready to configure the post commit hook. Our repository resides in /var/lib/svn/repositories/testWebApp (see above):

cd /var/lib/svn/repositories/testWebApp/hooks
cp post-commit.tmpl post-commit
chmod 755 post-commit

Now edit post-commit and ensure that the last three lines look like this:

REPOS="$1"
REV="$2"

wget http://localhost:8075/job/testWebApp/build

That’s it! From now on, every time someone commits code, the build is triggered.

Finishing Up

There’s a lot more you can do with Hudson. It supports multiple other source code control repositories, build triggers, build notifiers… even Twitter and IRC interfaces! It uses plugins to perform much of this functionality. Take a look here for the current list of plugins available. We hope this has been a useful introduction to Hudson. If you’re keen for more, there’s detailed information at the Hudson Website.

Maven is quickly becoming the de facto standard for Java project builds, as more developers realize its benefits and choose to migrate from Ant. Gone are the days when external project dependencies clogged up valuable space in source code control repositories. Once programmers become familiar with Maven, discovering all its advantages along the way, development proceeds as if they couldn’t get the job done without it. But there is one aspect of Maven-based development that’s potentially troublesome: the reliance on a remote central repository somewhere on the Internet. When a new developer joins a team, every single dependency is copied from the remote repository to his or her local repository cache. On Linux, this resides in the $HOME/.m2/repository and is usually a substantially large directory — especially if the developer has multiple projects under Maven control. This places an unnecessarily large load on the company’s or individual’s Internet link for the duration of the dependency download. Even worse, should the Internet link go down, the developer is unable to work.

So what’s the answer to all that wasted Internet bandwidth? A local Maven proxy. The first time a developer requests a dependency, it is copied from the central repository to the local repository, which resides on the machine running the proxy. Subsequent requests by developers in the team are then fed the copy from the local repository, typically on the same local area network (LAN). That translates to quicker builds and — as long as no new dependencies are needed — no reliance on the corporate Internet link for builds.

Before You Start

This tutorial covers the setup of Maven on a Linux server, as well as the best free local proxy available today, Nexus. Nexus is available in both a GPL-licensed version (Nexus Community) and a commercially-licensed version (Nexus Pro) that provides additional functionality. We will, of course, focus on the open source version as it is sufficient for most requirements. Well, OK… also because we dig open source and free stuff!

Meat & Potatoes

Maven Setup

Let’s start off with Maven. Maven runs as a Java process, so we’ll need to make sure we have Java installed first. Download the latest JDK from OpenLogic Exchange (OLEX) or http://java.sun.com/javase/downloads/index.jsp.

You’ll be asked to select the platform and type of installation. We always download the .bin self-extracting archive, and extract it to /usr/local on the Linux host:

# cp <download_location>/jdk-6u16-linux-x64.bin /usr/local
# cd /usr/local
# sh ./jdk-6u16-linux-x64.bin

Follow the prompts and install the Java SDK. You’ll see that at the time of writing, the version of the SDK was 6u16, which will obviously change. Once everything has extracted, a browser window will open and nag you to register. This is optional — the SDK will function just fine, even if you choose not to register. Close the browser and look at the new directory under /usr/local. The JDK will be installed in a directory containing the name of the version of the software, in this instance /usr/local/jdk1.6.0_16. A good trick is to make a symbolic link for this directory to /usr/local/java. That way you can keep your $JAVA_HOME environment variable set to the symbolic link. Every time you upgrade Java, simply remove the old symlink and then relink to the new location:

# rm -f /usr/local/java

# ln -fs /usr/local/jdk1.6.0_16 /usr/local/java

If you don’t already have $JAVA_HOME set up, let’s do it now. Use your favorite editor to open /etc/profile, and add the following line near the top:

export JAVA_HOME=/usr/local/java

While we’re here, let’s also add a needed variable for Maven:

export MAVEN_HOME=/usr/local/maven

Now look a little further down in the file. You should see a line configuring the $PATH variable. We need to add to the $PATH to include the ./bin directories of both Java and Maven. It should end up looking something like this:

export PATH="$JAVA_HOME/bin:$PATH\
$MAVEN_HOME/bin:\
$SOME_OTHER_STUFF/bin"

Save /etc/profile and exit the editor. Now it’s time to install Maven. Download it from OpenLogic Exchange (OLEX) or http://maven.apache.org/download.html.

Get the latest .tar.gz distribution. In our case it was apache-maven-2.2.1-bin.tar.gz:

# cp <download_location>/apache-maven-2.2.1-bin.tar.gz /usr/local
# cd /usr/local
# tar xvzf ./apache-maven-2.2.1-bin.tar.gz

Now log out and back in again for the contents of /etc/profile to be read and for the environment variables and PATH to be updated. Verify both installations:

# java -version

java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)

#mvn -version
Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
Java version: 1.6.0_16
Java home: /usr/local/jdk1.6.0_16/jre
Default locale: en_US, platform encoding: ISO-8859-1
OS name: "linux" version: "2.6.27.2" arch: "amd64" Family: "unix"

Good Job! Now on to the final part of our puzzle, the Nexus repository manager.

Nexus Setup

Nexus is deployed as a standard J2EE web archive or .war, as it is affectionately known. There are two download options: one as a .war, which you can install into a J2EE compliant server; or a standalone version which contains an embedded Jetty server. We’re going to focus on the standalone deployment.

Let’s start off by downloading and installing Nexus:

# cd /usr/local

# wget http://nexus.sonatype.org/downloads/nexus-webapp-1.3.6-bundle.tar.gz

# tar xvzf nexus-webapp-1.3.6-bundle.tar.gz

# ln -fs nexus-webapp-1.3.6 nexus

# cd nexus

# ls ./bin/jsw/

This will show you a list of directories for the supported architectures. In this case we’re running Linux x86-64, so to start the server we type:

#  ./bin/jsw/linux-x86-64/nexus start

You can install Nexus as a Linux service, too. Look for the link to the official documentation at the end of this article for details. To follow the log of the starting up server:

# tail -f logs/wrapper.log

If all runs correctly and you see no ominous-looking error messages, you should now have the proxy up and running. But we still have to tell Maven to look at the repository, instead of at the default central Maven servers. We do this by editing settings.xml, which resides in the .m2 directory under your home directory.

<settings>
  <mirrors>
    <mirror>
      <id>nexus</id>
      <mirrorOf>*</mirrorOf>
      <url>http://localhost:8081/nexus/content/groups/public</url>
    </mirror>
  </mirrors>
  <profiles>
    <profile>
      <id>nexus</id>
      <!--Enable snapshots for the built in central repo to direct -->
      <!--all requests to nexus via the mirror -->
      <repositories>
        <repository>
          <id>central</id>
          <url>http://central</url>
          <releases><enabled>true</enabled></releases>
          <snapshots><enabled>true</enabled></snapshots>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>central</id>
          <url>http://central</url>
          <releases><enabled>true</enabled></releases>
          <snapshots><enabled>true</enabled></snapshots>
        </pluginRepository>
      </pluginRepositories>
    </profile>
  </profiles>
  <activeProfiles>
    <!--make the profile active all the time -->
    <activeProfile>nexus</activeProfile>
  </activeProfiles>
</settings>

Remember that each of the developers in your organization will have to do this on their local machines, but replace localhost in http://localhost:8081/nexus/content/groups/public with the name or IP address of your repository server.

We’re almost there. We still have to tell the repository proxy exactly what it has to proxy! For this task, Nexus has a really cool web-based interface for us to use. Fire up a browser on the machine and point it to http://localhost:8081/nexus.

Above: The Nexus Welcome Screen

Click on the Log In link at the top right hand side, and log in as admin with the password you configured during the setup process.

Above: The Repository View

Your screen may look slightly different. The Repository Path column will reflect either localhost, or the name of your server if you are administering from a remote machine. The next step is to download the Lucene indexes for all of the “proxy” pre-configured repositories. For example, click on the “Maven Central” proxy and select the Configuration tab below. Change “Download Remote Indexes” to True, and then click Save.

Above: Enabling Download of Remote Indexes

Then right-click on the same proxy, and select Re-Index. Repeat the process for each of the proxies.

Finishing Up

Well done! You now have a functioning proxy that will start building a repository as you use it from your Maven project builds. If something doesn’t work, or you’re confused about some of the Nexus functionality, Sonatype has extremely good online documentation at http://www.sonatype.com/books/nexus-book/reference/index.html, including instructions on how to install Nexus as a service. This is definitely worth doing. You can also add periodic tasks to download and re-index the proxies.

At this point, you should aim to become more familiar with the administration interface and understand all of its functionality. Reference the documentation and examine the system logs for any potential problems.

Poor planning is one of the top reasons why software projects are delivered late, over budget, or not at all, so it’s important to get organized before you start coding. For decades programmers tried all manner of flow charts, elaborate diagrams, and volumes of specifications in an attempt to fully understand the code they planned to write, but these methods often proved to be ineffective and time consuming. Fortunately, programmers today can choose from a wide range of modeling tools that make it relatively easy to lay out the functionality and use cases for a new project.

In this article we’ll survey some of the modeling tools available to help you streamline the development planning process. All of the modeling tools covered in this survey are open source applications. The modeling tools addressed in this survey are:

• Acceleo
• AndroMDA
• ArgoUML
• BOUML
• Dia
• Fujaba
• Gaphor
• Kivio
• NetBeans
• Papyrus
• PyUML
• StarUML
• Taylor
• Umbrello
• UniMod
• Violet

Background

As modeling tools have evolved, they’ve blurred the boundaries of traditional software development planning. For example, some modeling tools can analyze and reverse engineer source code in order to produce UML diagrams. Similarly, most modeling tools support model-driven architecture (MDA), which means they can generate code from the models. Whether or not you use those features — and to what extent — is up to you. One option is to use the generated code as a skeleton and add in technology of your choice further down the road.

Most of the modeling tools covered in this survey use the Unified Modeling Language (UML), so you may wish to become proficient in UML to maximize your understanding of these tools. In addition to UML compliance, some of the other factors we’ll examine for these modeling tools include:

• Code generation capabilities
• Ease of use
• Documentation

We’ll start by taking a look at “contenders” that have unique strengths or benefits but lack some of the features we feel are most desirable. Then, we’ll move on to our list of “primary candidates” that offer the strongest combination of capabilities, documentation, and ease of use.

Condenders

AndroMDA

If you’re serious about taking the MDA approach to software development, AndroMDA is candidate worthy of consideration. While it does not have UML diagramming tools of it’s own, AndroMDA integrates with others to do the code generation. What we love about it is that it integrates with Maven, which is quickly becoming the standard build tool for Java development.

Dia

Dia is an application for creating technical diagrams. Its interface and features are loosely patterned after the Windows program Visio, so many users will find it easy to get started. Features of Dia include multiple-page printing, export to many formats (including EPS, SVG, CGM, and PNG), and the ability to use custom shapes created by the user as simple XML descriptions. Dia is useful for drawing UML diagrams, network maps, and flowcharts, but it does not support code generation. It runs on Linux, Unix and Windows and is released under the GPL License.

Fujaba

Fujaba is a UML modeling tool that generates code in Java and vice-versa. Most of the documentation is is German, but there is great tutorial in English that demonstrates how to create a networked game using Fujaba exclusively. It is distinguished from other CASE-Tools by the fact that it performs Story Driven Modeling (SDM). Fujaba seems to be popular among German academic institutions and is used as a teaching aid for software development.

Gaphor

Gaphor is a simple UML 2.0 modeling environment, and simplicity seems to be its primary aim — it is easy to install, use and extend. Gaphor is cross-platform, running on multiple flavors of Unix and Windows. No code generation is supported. However the models can be exported to XMI, and SVG, PNG and PDF format exports are supported for the diagrams.

Kivio

Kivio is the KOffice flowchart and diagram creation tool. It allows you to create accurate scale diagrams by arranging pre-drawn shapes and stencils on a page. The stencils might represent stages of a process, office furniture, or components on an electronic circuit. Kivio comes with a large collection of different stencils, which are grouped into collections — known as stencil sets — by subject area. Kivio features script-able stencils using Python, support for Dia stencils, and a plugin framework for adding more functionality. No code generation is supported.

PyUML

PyUML is described as a fully functional UML-Roundtrip-Tool for Python. It is implemented as an Eclipse plugin based on the plugins PyDev and Eclipse Uml2Tools. Unfortunately, the user guide is only available in German, and as such we were not able to thoroughly evaluate its features. It appears to support code generation for Python only, and as of publication of this survey it did not support the latest version of Eclipse (Ganymede).

StarUML

StarUML is a Windows-only code generator and UML editor. The documentation is reasonably good, but it’s obvious that it was directly translated from Korean or written by a non-native English speaker. Documentation is available in Korean, Russian and Japanese, too. The product itself is very powerful; generation is not limited at all, so you can generate Word documents and spreadsheets as well as source code. Although it is touted as open source, several commercial dependencies are required to build from source.

The last release of StarUML was in 2005, so it seems the product is either completely stable or development has stalled. A recent discussion on the forum page indicates that the project may have been abandoned, and some developers have started a fork called SunUML.

Umbrello

Umbrello is a nice KDE-based UML modeler and code generator with a wealth of code generation options. In fact, it supports more languages out of the box than all of the other generators included in this survey. Most new Linux distributions with KDE4 include Umbrello as part of the kdesdk package. Umbrello is not yet available for Windows, but it looks as though this may soon change — there’s a screenshot of Umbrello running on Windows in an experimental capacity on the project website.

UniMod

One approach to software development is to concentrate on defining and implementing application behavior using SWITCH-technology with the help of Structural Finite State Machines (FSM), and UniMod falls within this methodology. However, UniMod is different from other projects using FSMs for describing application logic in that it uses UML and is not focused on embedded systems. UniMod generates Java code exclusively and is another plugin for the Eclipse platform.

Violet

Violet is a simple UML diagram editor and is not intended as an industrial strength modeling tool. No code generation or reverse engineering capabilities are provided, and it does not support XMI export or perform semantic checking of models (in other words, you can draw contradictory diagrams). Violet can be run as an applet, via Java Web Start or as an Eclipse plugin. Violet’s strength lies in its simplicity and easy of use.

Primary Candidates

ArgoUML

ArgoUML is another mature code generating CASE tool, supporting diagram editing for all 9 UML 1.4 diagrams. It boasts a rich set of features including code generation for Java, C++, C#, PHP4 and PHP5, and it’s platform independent and available in ten languages. Diagrams can be exported in as GIF, PNG, PS, EPS, PGML and SVG. Another nice feature is that it supports reverse engineering with Jar/class file importing. Even though we found the user documentation to be lacking in some areas, the documentation seems to be an active work in progress.

ArgoUML is very easy to install, as it has no dependencies other than Java. In most cases it can be installed with a single click using Java Web Start. ArgiUML supports XMI, which is an XML based exchange format between UML tools, so interchange between XMI-compliant tools should be a snap. Other cool features include to-do lists, design critics, OCL support, checklists and multiple overlapping views.

It’s worth mentioning that there is a commercial product called Poseidon, which uses the ArgoUML code base and presents a more complete, rounded product. Having used both, we can live with some of the rough edges in ArgoUML in order to gain some of the other benefits of using an open source solution.

BOUML

BOUML is a very promising project. Running under Linux, Solaris, MacOS X and Windows, it provides UML diagram editing and code generation for C++, Java, Python, PHP and IDL. The generated code is achieved through what the author calls “plug-outs” (named because they execute outside of the BOUML environment), which can be developed in C++ or Java to support other languages. Considering the author is a non-native English speaker, the documentation is excellent. This is a great example of useful open source.

Netbeans

The popular Netbeans IDE has a great UML plugin, which is easily installed via the Plugin Manager. Designers and analysts design applications using the UML modeling language, then developers generate Java code from the UML model. You can also update the model from changes made in the source code. Generated source code can be saved into new source files or merged into existing source code files, thereby providing full round-trip engineering capability. Your collection types are preserved during Forward and Reverse Engineering and may be set and changed. The Netbeans documentation is very good, and there are tutorial trails covering UML based development. However, code generation is currently Java only.

Papyrus / Acceleo

Another tool based on the Eclipse environment, Papyrus models within UML 2.0 and supports multiple code generation possibilities. It supports the DI (Diagram Interchange) standard, an extensible architecture that allows users to add new diagrams and new code generators as well as profile development support facilities for UML2 profiles, nested profiles, and OCL constraints in profile descriptions. Code generation is supported through interfacing with Acceleo.

Acceleo, built as an Eclipse plugin and utilizing the Eclipse EMF (Eclipse Modeling Framework), is a mature MDA environment. With syntax highlighting, real-time error detection, meta-model and scripts-based completion, and real-time preview of generated code, this is certainly an extremely useful product. Acceleo lets you insert custom coding into the generated code by defining coding zones, which are preserved in future iterations of generation. What this means is that you can use Acceleo throughout your development process and seamlessly evolve your project without losing any customization code. It uses custom templates to generate many commonly used programming artifacts, using wizards and a special syntax defined as a result of many years of experience in code generation. In addition, Acceleo uses “services” to extend templates to implement complex operations — basically allowing unlimited extensibility while keeping the templates clean and easy to read. Acceleo can be used to generate C, Fortran, Java, Smalltalk, XML, VB.Net, and virtually any markup language. This is accomplished by the use of Modules, which are basically groups of several templates that describe the information required to generate source code.

A large number of commercial and open source UML Case tools are compatible with Acceleo, and it runs on any Eclipse-compatible operating system. And if this all sounds way too technical, don’t despair — the online documentation and tutorials are superb. The website features a support forum for both English and French language users. Additionally, there is a wiki, an IRC channel, a mailing list and an RSS feed.

Taylor

Implemented as a set of Eclipse plugins and targeted towards JEE development, Taylor aims to make creating JEE applications as easy as Ruby-on-Rails, but with the power of JEE and UML. We were very pleased to see that Taylor can generate JSF and JBoss Seam code, as well as EJB3 Entity and Session Beans. Equally exciting is the fact it can generate Maven pom.xml files and APT documentation from the UML comments. This merely scratches the surface of its feature list — Java Enterprise developers won’t be disappointed with the direction of this project. The documentation is excellent and includes a cool Flash-based demo.

Conclusion

From the perspective of a reviewer with no specific software development project in mind, the most feature-laden option is the Papyrus / Acceleo combination. If your primary IDE is Eclipse, you will benefit from having your modeling software running in the same environment as your active code editor. For Java programmers using Netbeans, the same can said of its modeling tool. BOUML, while superb in its own right, is the vision of a single author and, as such, enterprise development institutions may be hesitant to adopt it. If you don’t mind breaking away from your IDE, give Taylor a test drive.

As we’ve seen, there are many good open source choices for project conception and planning tools, but the best tool for the job is not easily defined. Your unique programming language requirements, environment, operating system, and IDE will guide your decision making process.