[Nice-eclipse] The new Nice Eclipse Plugin

[Martin G. <ga...@ab...>]

Hi Everyone!

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!


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


2) 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)

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

2.1) 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.

2.1.1) User Interface

+ Nice Perspective DONE
+ Navigator View showing Nice Project with Resources DONE
+ Problem View showing Nicec compilation errors DONE
+ Project Properties Dialog DONE
+ Add/Remove Java Nature for a Nice Project (current workaround to 
launch Nice apps) DONE
+ Add Nice Projects Wizard DONE
+ Add Nice Packages Wizard DONE
+ Add Nice Source Files Wizard DONE

+ Source Outline View TODO
+ ...
+ ...


2.1.2) Building

+ Build Nice Project DONE
+ Error/Warning reporting in the Eclipse Taskbar DONE
+ Configure Nicec Sourcepath DONE
+ Configure Nicec Classpath DONE
+ Configure Nicec Destination Directory DONE
+ Configure Nicec Distribution Directory DONE
+ Configure Nicec Main Package DONE
+ Configure Nicec Target Jar File DONE

+ Build Nice Projects depending on other Nice Projects TODO (currently 
strange behaviour)
+ Configure Nicec Compilation Flags TODO (GUI is ready)
+ Error/Warning reporting in the Editor TODO


2.1.3) Launching

+ Launch Properties using eclipse wizards for configuring Java Project 
launches with minor modifications WORKING
+ Launch Nice Applications using eclipse built-in java launching 
capabilities WORKING


3) 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.

3.1) 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?


3.2) 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.


I hope this gives you all a little overview of what I'm planning to do. 
As mentioned above, feel free to comment on everything! I also added a 
new page to the eclipse wiki where ongoing discussions that are better 
made accessible for easier reviewing, can be copied from this list, or 
started right on the page. Access it at 
http://nice.sourceforge.net/cgi-bin/twiki/view/Dev/NewEclipsePlugin As a 
start I will copy this message on the page. Unfortunately sourceforge 
doesn't provide an option to be notified of wiki changes, so just surf 
by from time to time to see if something has changed. An idea would be 
to make it a convention that everyone who posts something on the wiki, 
should write a short notification to this mailing-list?

Looking forward to exciting discussions!
Martin Gamsjaeger