Free Eclipse

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.

  1. Support free VMs at runtime. This means, pick one (gcj of course) as a standard platform for testing.
  2. 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.
  3. Directly support sourceforge, et al, in the cvs plugin. Mostly this just means cleaning up and checking in the existing patch.
  4. 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.
  5. 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.
  6. 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 users.
  7. Make it much, much simpler to generate an RPM from a plugin -- in fact, this should be mostly automatic. Specifically:
  8. For VEP, support Gtk and java-gnome. Interoperate with Glade.
  9. 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 build options.
  10. 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 PR.
  11. 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.
  12. 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 3.1.)
  13. Incorporate the subversion plugin and fix it up. Some important free software projects have switched to subversion.
  14. 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.
  15. Teach Eclipse about some common rules for development: using 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 application.
  16. Have a bridge between the Eclipse Quick Fix feature and the ChangeLog plugin, so that Eclipse can automatically write ChangeLog entries for fixes.
  17. 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 for C.
  18. Another wacky idea: like PIDA, provide a way to integrate pastebin and irc into Eclipse. I wrote a few random notes along these lines a while back.
  19. vektor's list.
  20. Ed 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 better.

  1. 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 in Eclipse...
  2. 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 jamvm.
  3. Some CDT/JDT integration revolving around JNI hacking. The PR.
  4. A plugin that understands JAPI files and will show an error if we violate binary compatibility.
  5. 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.

Done

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! :-)