Message-ID: <1285339555.91.1430216982868.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_90_1678504821.1430216982867" ------=_Part_90_1678504821.1430216982867 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This page describes the Groovy-Eclipse projects for UCOSP (the un= dergraduate capstone open source projects). This list does not descri= be the projects in detail, but is meant as a place to start. Details = can only be filled in as the projects move along.
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 b= efore. However, we have gotten ourselves into a state where the existing co= de is too tangled and fixing bugs becomes increasingly more difficult. &nbs= p;There are many open formatting bugs, but we have not had the resources to= fix them.
With this project, there are two possibilities:
This is a large project and quite difficult. But, it = is also very important. Fixing formatting-related bugs is highly requ= ested. Since this project is more complicated, it may be worthwhile t= hat two students work on this together.
With Groovy-Eclipse, we strive to have the same level of fu= nctionality 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 a= re small code manipulations that are associated with errors. For exam= ple, classes that do not implement all methods of an interface have a quick= fix associated with the error marker. Quick assists however, are ass= ociated with syntax. Pressing Ctrl-1 or Cmd-1 will bring up a panel t= hat shows all available quick assists at the given location.
Groovy-Eclipse already implements several quick fixes and q= uick assists, but it would be great to have more. The nice thing abou= t 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. &nbs= p;Quick fixes/assists are nice to have and provide a bit of polish on Groov= y-Eclipse that is currently missing.
Groovy-Eclipse implements some of the basic refactorings: r= ename, extract local variable, extract constant, and extract method. = To be a full fledged language IDE, we should be offering a wider range of r= efactorings, including (but not limited to): introduce parameter, change me= thod signature and convert local variable to field. Also, some Groovy= -specific refactorings like extract to category, push from category, and co= nvert to explicit typing.
This project is more difficult than implementing quick fixe= s/assists since each refactoring requires significant custom work, but ther= e are existing refactorings on which to base the new work. See here for a list of open refactoring issues.
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 vie= wer that ships with the Groovy console. However, the viewer in Eclips= e is messier and provides less functionality. This is a partial list = of required improvements:
This is a low priority project since this feature is really= only useful to a small set of users. However, this project may be in= teresting as a backup project.