Issue #18 April 2006

Introduction to Eclipse on Fedora

by Igor Foox

Eclipse™ is a very popular open source, application-rich platform that is written in Java. The beauty of Eclipse is its extensibility and cross-platform compatibility. The Eclipse Software Development Kit (SDK) includes an extremely well-built Java® Integrated Development Environment (IDE) as well as a Plug-in Development Environment (PDE). "Plug-ins" are special-purpose software packages that can be installed into the Eclipse framework. For example, Red Hat's Eclipse Bugzilla plug-in integrates a Bugzilla interface into Eclipse.

Through plug-ins, the Eclipse framework can be extended to almost any possible area of computing. Plug-ins exist for anything from J2EE development to embedded development to an office application suite.

Eclipse is developed largely on and for the Microsoft® Windows® platform, and even though other platforms--including GNU/Linux--are supported, there is no tight integration between Eclipse and those platforms. Moreover, Eclipse does not have integrated support for traditional open source development practices, and instead focuses mostly on Java development. Fortunately, Fedora Core 5 ships with an integrated Eclipse development environment based on Eclipse 3.1.2, making it possible for Eclipse to run smoothly on Linux.

This article describes the history of this effort, the current state of the platform, and some future plans.


Eclipse is an open source framework distributed under the Eclipse Public License (EPL). Eclipse requires a Java environment to run, and in the past there was no fully-featured, open source Java Virtual Machine (JVM) and class library available. This precluded Eclipse from being included in most Linux distributions. GCJ[1], the GNU Compiler for Java which is part of GCC, has been making big strides toward providing a free and open source compiler and virtual machine for Java. GCJ uses the GNU Classpath project[2] as a runtime class library. However, GCJ is not yet as optimized as other proprietary virtual machines at running Java bytecode, so running a large application like Eclipse would have been unacceptably slow. Thankfully, to bypass this problem, GCJ can turn Java source files as well as .class files into native machine code that can then run without a virtual machine.

In 2002, Red Hat engineers began natively compiling Eclipse using Eclipse 2.x. However, this did not turn out to be a successful route and the project was abandoned. In 2003, the Eclipse team tried natively compiling Eclipse again, this time with version 3.0, which had recently been released. This proved to be a harder task than it first seemed, but after many changes of direction and patches to GCJ, the Classpath runtime, and to Eclipse itself, the team was able to natively compile Eclipse and run it on a completely free stack. In June 2005, a natively compiled version of Eclipse 3.1 shipped with Fedora Core 4. More information about the challenges of getting Eclipse natively running can be found in the Linux Journal article "Eclipse Goes Native."[3]

Current state

Eclipse IDE screenshot
Figure 1. The Eclipse IDE running natively compiled

The release of Fedora Core 5 continues to build on the previous efforts of the Red Hat Eclipse group, bringing an even more stable version of Eclipse in a natively compiled format.

Package breakdown

First, it's important to understand the way Eclipse is packaged by and how that differs from the way it's packaged in Fedora.

Everything in Eclipse is a plug-in, and even the Eclipse IDE itself is built from a multitude of plug-ins carved up into Eclipse sub-projects. These include the Rich Client Platform (RCP), Platform (the main Eclipse framework), the Java Development Toolkit (JDT), and the PDE among others.

Users of operating systems other than Linux usually download Eclipse from as a single archive file containing the Eclipse SDK, which includes all of the sub-projects mentioned above. Other Eclipse projects, such as the C/C++ Development Environment (CDT), are provided as add-ons and can be installed later using Eclipse's Update Manager.

In Fedora, however, you can install only the packages that you want to use or those that are needed by other software you install, while safely ignoring the other packages. Because Eclipse is such a large application--the combined size requirements for all Eclipse packages in Fedora total over 215 MB--it is useful to break it down. Package selection is managed by Yum through RPM dependencies.

The following diagram describes all of the Eclipse packages (RPMs) that ship in Fedora Core and their relationships. Arrows indicate dependence, so that A->B means that A depends on B.

Eclipse RPM heirarchy
Figure 2: Fedora Eclipse RPM hierarchy

As you can see from Figure 2, Fedora ships with the full Eclipse SDK, breaking it into 5 sub-packages, enabling users to do Java development and plug-in development. It also ships the CDT for C/C++ development as well as add-on plug-ins such as PyDev, the Bugzilla plug-in, and the ChangeLog plug-in. A short description of all the packages and the status for each is given below.

Eclipse Base Platform RPMs

Fedora currently ships version 3.1.2 of the Eclipse SDK, which is the latest stable release. It does not ship 3.2 milestone builds because they are regarded as development snapshots and are not suitable for general public use.

RPM descriptions

  • libswt3-gtk2:M
    The Standard Widget Toolkit (SWT) is a cross-platform basic UI toolkit in Java; the Eclipse UI is built using SWT.
  • Eclipse-rcp:
    The Eclipse Rich Client Platform (RCP) provides a base platform that developers can use to develop generic applications. It does not include any IDE-specific components; these are provided higher up the stack.
  • eclipse-platform:
    The Eclipse Platform provides basic components that are used by Eclipse, such as the "Workbench" metaphor.

Development Tools RPMs

Fedora ships the Eclipse tools for developing Java and C/C++ applications as well as the plug-in development tools. The JDT and PDE versions that are shipped match those of the 3.1.2 SDK, whereas the CDT is version 3.0.2.

RPM descriptions

  • eclipse-jdt:
    The Java Development Tools (JDT) provides the Eclipse Java IDE.
  • Eclipse-pde:
    The Plug-in Development Environment (PDE) provides tooling to develop Eclipse plug-ins.
  • eclipse-cdt:
    C/C++ Development Tools (CDT) adds tooling for developing C/C++ applications.

Add-on plugins

Fedora ships extra add-on plug-ins that expand the range of tools available to developers using Eclipse.

RPM descriptions

  • eclipse-bugzilla:
    The Bugzilla plug-in provides an interface to Bugzilla from within Eclipse.
  • eclipse-changelog:
    The ChangeLog plug-in provides tools for working with ChangeLog files conveniently.
  • eclipse-pydev:
    The PyDev plug-in provides tools for building and debugging Python applications.

The Bugzilla and ChangeLog plug-ins are maintained by Red Hat engineers and are designed to make life easier for open source developers using the Eclipse platform. These plug-ins are also available to users on other platforms through an Eclipse update site, but are developed on and integrated into Fedora.

  • The Bugzilla plug-in allows developers to view bug reports from multiple Bugzilla installations from within Eclipse. It also provides an interface for querying, saving queries, and grouping bug reports in hierarchical folders.
  • The ChangeLog plug-in adds functionality similar to the Emacs ChangeLog extension. A developer can invoke a command from within a changed file or function and the plug-in will automatically find the appropriate ChangeLog file and add an appropriate entry stub.
  • The PyDev plug-in is the de-facto standard for Python development within Eclipse, consisting of a full development editor as well as debugging support. Unfortunately, it is impossible to include the latest versions of this plug-in in Fedora due to its use of Java 1.5 language features, which are not yet supported in GCC 4.1.

Current issues

The single-most difficult problem with Eclipse on Fedora is plug-in packaging. The standards of distribution that have been developed by the OSS community over the past two decades are not commonly used by Eclipse plug-in developers. Specifically, the source code for a particular version of a plug-in is usually not available as a traditional tarball, it is only available through the version control system, usually CVS. Additionally, plug-in developers often do not tag their CVS repository before making a release. This makes it close to impossible to replicate a particular binary plug-in release. If source code is distributed at all, it usually contains only enough build machinery to build a binary plug-in manually from within the Eclipse UI. It is very difficult to use these source distributions to build plug-ins in an automated fashion, as is done in the process of creating an RPM.

Another major potential sticking point for open source developers is the weak integration of Eclipse with C and C++ and even weaker integration with the GNU Autotools. The CDT provides the ability to work with C and C++ projects from within Eclipse, but it is still difficult to work with an existing OSS project out of the box. This usually involves configuring Eclipse for the specifics of the project, which should not be required, especially for projects that use standard build tools such as GNU Autotools.

These problems remain unsolved, but there are efforts to make the situation much better on all fronts.

Future plans

We hope that this glimpse of Eclipse on Fedora will encourage you to give it a try. Here are some of the improvements that are planned for the near future.

Eclipse 3.2 is the next version of the Eclipse platform, and it is nearing release. It brings many new features and updates over 3.1[4]. We are experimenting with builds of Eclipse 3.2 and plan to deliver it as an RPM once it is finally released.

There are also plans for deeper integration of Eclipse and Fedora. Specifically, increased development of plug-ins that will help developers work seamlessly with their tools of choice within Eclipse.

Plug-in building

There is an effort to resolve the problems associated with plug-in building by making it trivial for Eclipse developers to provide full, buildable source distributions of their plug-ins along with binary distributions. These fixes should also make building and packaging plug-ins from these source distributions significantly easier to automate in the future. The Red Hat eclipse team hopes that this will help the community join the effort to provide many more great Eclipse plug-ins as part of Fedora.

Autotools integration

Work is also being done to improve the integration between the CDT and GNU Autotools[5]. This work is based on a Google Summer of Code project[6] done by Alexander Dymo. This should take the guesswork out of working with existing Autotools-managed C/C++ projects from within Eclipse.

Bugzilla plug-in

The Bugzilla plug-in for Eclipse also continues to improve. There are plans to include full bug manipulation functionality that will allow users to create, change, and respond to Bugzilla bug reports without leaving Eclipse. There are also plans for speed optimizations and many UI enhancements to this plug-in.

No login required. Want to see your comments in print? Send a letter to the editor.

Community project

There are many more ideas for integrating Eclipse with OSS development tools and practices. Unfortunately, not all changes can be implemented at once. We hope that this brief introduction will inspire others to try out the existing tools, and perhaps even help out by contributing to one of the plug-ins that are currently under development or by packaging your favorite Eclipse plug-ins for Fedora. The Fedora Eclipse community project is an effort to make this easier and more transparent. The website and CVS repositories will be slowly transitioned to as resources permit. Mailing lists are also being created for the project, and the most up-to-date information is always available on the current Fedora Eclipse website[7].

About the author

Igor Foox is a student at the University of Toronto, he is currently completing a 16 month internship with Red Hat in the Toronto office. Igor has been using Eclipse and Linux, separately, for over 2 years. Igor is part of the Eclipse group in Red Hat, working on the Bugzilla plug-in, general packaging, and bug fixing.