United States (change)
Shortcuts: Downloads Fedora Red Hat Network
Issue #18 April 2006
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]
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.
First, it's important to understand the way Eclipse is packaged by eclipse.org 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 Eclipse.org 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.
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.
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.
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.
Fedora ships extra add-on plug-ins that expand the range of tools available to developers using Eclipse.
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 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.
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.
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.
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.
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.
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 fedoraproject.org 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].
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.
[1] http://gcc.gnu.org/java/
[2] http://www.gnu.org/software/classpath/
[3] http://www.linuxjournal.com/article/7413
[4] http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_2.html
[5] http://sourceware.org/eclipse/autotools/
[6] http://kde-eclipse.pwsp.net/
[7] http://sourceware.org/eclipse/