Eclipse is an excellent IDE
with many cool plugins and features. However, it still isn't
integrated into the mainstream of free software development to the
extent that I would like. So, I thought I would do what everybody
with an idea and no free time does: write a web page about it. Here
are some Eclipse projects that would help it integrate better with
the free world.
- Support free VMs at runtime. This means, pick one (gcj of
course) as a standard platform for testing.
- Support gcj in the update manager. So, when the user installs
a plugin, it should be gcj-compiled and registered in the global
class lookup database.
- Directly support sourceforge, et al, in the cvs plugin.
Mostly this just means cleaning up and checking in the
- Let the user choose a project by its package name, and
automatically fetch the .src.rpm using yum and unpack it as an
Eclipse project. This could be a new Import option.
- Set up the documentation browser so it automatically knows
about all the documentation already available: perl, python, gtk,
etc. Perhaps interoperate with existing format translators that
know how to generate HTML; perhaps lobby distros to include more
HTML docs with indices usable by Eclipse. Ideally, update Eclipse
so it is very easy to jump from some function in the source to the
documentation (weirdly, this doesn't seem possible yet, even in the
JDT afaik). In particular all the glibc and gtk documentation
should be available via Eclipse's help.
- Integrate the update manager with RPM and dpkg already. The
current setup just isn't that useful for Linux users. At the very
least there should be a default update site in the user's home
directory, so that the update manager "just works" for ordinary
- Make it much, much simpler to generate an RPM from a plugin --
in fact, this should be mostly automatic. Specifically:
- The Eclipse releng scripts should be cleaned up a bit to make
it much simpler to build plugins and to build native code. It
should be possible to build the entire platform, including the
native code, for the current machine with a single command.
- There should be a uniform flag
across all plugins to avoid cvs checkouts during the build.
- It should be possible to build a plugin with the releng code
using an installed eclipse even if that plugin is already
installed. This is convenient for building in build roots.
- For VEP, support Gtk and java-gnome. Interoperate with
- For the CDT, write autoconf (see the
PR) and valgrind plugins. At the very least, checking out an
autotools-using package should cause the CDT to set up default
- Again for the CDT, make it very easy to write certain kinds of
projects. E.g., let the user ask for a "gtk" project and
automatically use pkg-config in the Makefile (in the managed build
or autoconf plugin scenarios), automatically make gtk-based hover
help available, etc. The
- Write a bug tracking plugin. Make it have pluggable back ends,
like the team plugin, but make sure it at least works with bugzilla, sourceforge, and Jira.
Let the project indicate its bugzilla location so that I don't need
to do any more configuration. Note that right now you can use
a bugzilla plugin.
- Make it easy for a project to specify its indentation and
warning policies, so I can check out projects and not have to
configure each one separately. Right now formatting for the JDT
appears to be a global choice. (This is fixed in Eclipse
- Incorporate the
subversion plugin and fix it up. Some important free software
projects have switched to subversion.
- Make Emacs (the
PR) and vim work as real plugins, so we don't have to give up
our powerful editors to gain Eclipse's features.
- Teach Eclipse about some common rules for development:
ChangeLog entries for commits, and generating
patches for submission; bonus points if Eclipse can let you
compose and email the patch without bringing up another
- Have a bridge between the Eclipse Quick Fix feature and the
ChangeLog plugin, so that Eclipse can automatically write
ChangeLog entries for fixes.
- Wacky idea: write a kernel developer's plugin. This could use
the CDT's view of the source to do checks that aren't easily done by
the compiler (like sparse I suppose). Ideally this would end up
looking like FindBugs
- Another wacky idea: like
provide a way to integrate pastebin and irc into Eclipse.
I wrote a few random notes along these lines a
Burnette's grand challenges.
Classpath and Eclipse
Currently it is pretty convenient to develop Classpath from
inside Eclipse. However, with a few additions it could be even
- A few of the items above would be useful, in particular the
bugzilla plugin (which actually really does work) and the things
relating to patch submission. The patch submission changes would
have an immediate impact on the ease of writing Classpath changes
- Add JDWP support to JamVM, and then teach
Eclipse how to recognize the JamVM in the workspace as a JRE. That
way users could add real java launch configurations using
- Some CDT/JDT integration revolving around JNI hacking.
- A plugin that understands
JAPI files and
will show an error if we violate binary compatibility.
- A plugin that understands
Mauve. This could
show a tree view of all Mauve tests along with pass/fail status.
Perhaps you could click on a test to re-run it; it could somehow
keep track of baseline results and show regressions; and you could
jump directly from this tree view to the corresponding Classpath
source file. Finally, it could add a command so that you could
choose "New test" from a file in Classpath, and it would make a
skeleton test in the appropriate place in Mauve.
My list used to be a bit longer. Here are the things that were
implemented. If wishing made it so ... you'd be talking about
eclipse development! :-)
- Support free VMs for development. Currently a free VM won't
show up in the JDT, since it looks for the installation layout
that the JDK uses. (Fixed by java-gcj-compat.)
- Include the tar
plugin by default. (vektor wrote this for 3.1.)