TWiki . Dev . NewEclipsePlugin

As I am just starting to develop a new Eclipse Plugin for Nice, I wanted to share my first ideas and goals concerning features and their realization with the community. Everyone reading this is very welcome to comment on everything that is said here! If you have ideas, feature requests, problems, you think I'm wrong, you think someone else is wrong, you know a better way to do something (maybe because you already have experience in that domain), really whatever comes into your mind concerning the nice-eclipse plugin! Don't be shy, post it here!

General Approach

One thing I have to say right away is that my general approach to writing this plugin may look a bit "conservative" to some of you, as I do not really plan to rush things and add feature after feature as fast as possible. Instead I'm planning to focus on a solid design that integrates smoothly into eclipse and is flexible enough to handle advanced IDE tasks . Therefore I still need to do extensive studies of eclipse to get more insight into how things are done. I know that it would be hesitating to start implementing cool editor features right away, but I think that without a solid architecture, a project of the size this one will probably have in the end, will be a pain to deal with.

One consequence of this approach is, that it may take some time until the first "true features" will be available (as building and running are too basic to be considered true features :-) . True Features are probably those that make editing Nice source easier. Another consequence is, that once the underlying architecture is reliable, it should generally be easier and faster to add features. I hope this will work out and provide a nice piece of software. Same as with everything here, comments welcome!

Goals

The following is by no means a complete list of goals for this project. These are just the ones that came into my mind so far (minus a few I just can't think of right now)

Long term goals

Long term goals haven't been defined exactly yet, but it is definitely an overall goal to provide a full fledged Nice IDE that supports everything programmers coming from java are used to. The general rule should be that if some operation is possible in the (Eclipse) Java IDE, it should be possible to do it in the Nice IDE as well, along with features we come across that are unique to Nice. This is a brave goal, it will take time to achieve it!

Short term goals

As said on page 18 of the german edition of the book "Contributing to Eclipse: Principles, Patterns and Plugins" by Erich Gamma and Kent Beck (maybe suffering from my poor translation abilities):

"Entering the world of Eclipse, you will spend more time reading code, than writing code. You first have to get used to those incredibly productive days, where you spend 6 hours on reading and 1 hour on writing code."

You probably guessed right, I own this book :-) Anyway, the following is what I will read a lot about, and hopefully also will write enough to make it work. Sections marked as DONE are still subject to refactoring or even rewrite from scratch, as I gain more understanding of the eclipse platform. So if you think almost everything is marked as DONE, why are these still goals? Think of the current implementation as a prototype that anyway will be rewritten in Nice very soon.

User Interface

Building

Launching

Design

This is actually the most important goal for now: get an understanding of the eclipse architecture to be able to extend it correctly and get the most out of it. It is very likely that the plugin will be developed in a few subprojects (that map to plugins) to separate logically independent parts from another. Here are two of them I can think of at the moment.

JVM Based Language Launching

As Nice compiles to java bytecode, Nice apps are run like normal Java apps. However, the eclipse code that realizes this functionality depends on the JDT's JavaModel? (a set of classes that model java source and - i think to a certain extent - bytecode as well). This leads to the restriction that plugins that want to launch programs using the JVM need always be JavaProjects? (working with a JavaModel?) in order to make use of the Java launching capabilities.

The goal of this subproject should be to provide a way for jvm-based languages to plugin their own type of project, along with their own model, and still use all the functionality and UI that Java programmers use when launching their applications. I think this makes perfect sense, as when it comes to launching, there is really no difference between java and nice (and probably most other jvm-based language). This idea came to my mind when looking at http://eclipsefp.sourceforge.net/ . Those people try to provide a common framework for functional languages (not especially targeted at launching) that should make life easier for plugin writers. Why not try to get something reusable out of a problem we anyway have to tackle?

A Model for Nice Source Code

To do advanced source code editing we need a model that represents Nice sources inside the plugin. This could be a model of source code that is constructed during a compilation, with a precise API to read and modify from the plugin, that can be sent back to the compiler for further (incremental) compilation. IMO advanced operations like refactoring, error correction proposals, searching, navigating, ... justify the additional complexity of such a model (and the changes/additions to the compiler that are needed), as they would be a pain to implement with no reliable infrastructure. This model (or API used by the model) could be implemented as a library using Nice AST. This is definitely one of the integral parts of the plugin and will need a lot of discussion, especially with core developers. Although it is no main goal for me at the moment to start implementing this, we should use the time to discuss an architecture both inside and outside the Nice compiler, that would be able to handle these issues.

-- MartinGamsjaeger - 03 Dec 2004

----- Revision r1.1 - 03 Dec 2004 - 18:03 GMT - MartinGamsjaeger
Copyright © 1999-2003 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.