Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

This page describes the Groovy-Eclipse projects for UCOSP (the undergraduate capstone open source projects).  This list does not describe the projects in detail, but is meant as a place to start.  Details can only be filled in as the projects move along.

Project 1: Code formatter

The Groovy-Eclipse code formatter has historically been one of the messiest parts of the code base.  In the last couple of years, though we have patched together things so that it works much better than before. However, we have gotten ourselves into a state where the existing code is too tangled and fixing bugs becomes increasingly more difficult.  There are many open formatting bugs, but we have not had the resources to fix them.  

With this project, there are two possibilities:

  1. Work with the existing formatter and incrementally improve, fixing one bug at a time.  The risk here is that some bugs cannot be fixed without starting from scratch 
  2. Start from scratch with an entirely new formatter and a new approach.  The risk with this approach is that it could be difficult to build a new formatter and there is no guarantee that the new formatter would behave better than the original.

This is a large project and quite difficult.  But, it is also very important.  Fixing formatting-related bugs is highly requested.  Since this project is more complicated, it may be worthwhile that two students work on this together.

See here for a list of open formatter issues:

Project 2: Quick fixes and quick assists

With Groovy-Eclipse, we strive to have the same level of functionality as you get from the JDT.  We are not there yet.  Part of what we need is good quick-fixes and quick assists.  Quick fixes are small code manipulations that are associated with errors.  For example, classes that do not implement all methods of an interface have a quick fix associated with the error marker.  Quick assists however, are associated with syntax.  Pressing Ctrl-1 or Cmd-1 will bring up a panel that shows all available quick assists at the given location.

Groovy-Eclipse already implements several quick fixes and quick assists, but it would be great to have more.  The nice thing about this project is that each quick assist/fix is largely self-contained and you can look at existing implementations to see how to build new ones.  Quick fixes/assists are nice to have and provide a bit of polish on Groovy-Eclipse that is currently missing.

See here for a list of open quick assist issues:

Project 3: Refactoring

Groovy-Eclipse implements some of the basic refactorings: rename, extract local variable, extract constant, and extract method.  The latter has some particular problems, but works in basic cases.  This lack of refactorings is one of Groovy-Eclipse's weaknesses.  To be a full fledged language IDE, we should be offering a wider range of refactorings, including: introduce parameter, change method signature, convert local variable to field, extract to category, and convert to explicit typing.

This project is more difficult than implementing quick fixes/assists since each refactoring requires significant custom work, but there are existing refactorings on which to base the new work.

Project 4: New AST Viewer

The AST viewer in Groovy-Eclipse displays the entire AST of a file in tree form.  Users can navigate the tree and this is helpful for people writing AST transforms and people who just want to learn about how Groovy works.  This implementation is loosely based on the AST viewer that ships with the Groovy console.  However, the viewer in Eclipse is messier and provides less functionality.  This is a partial list of required improvements:

  1. Filtering of tree nodes that are uninteresting.
  2. Tree collapses after every edit of the file
  3. Selecting a node in the tree should select the appropriate location in the file (and vice versa)

This is a low priority project since this feature is really only useful to a small set of users.  However, this project may be interesting as a backup project.

  • No labels