Nice TWiki > Dev > EclipsePlugin (r1.1 vs. r1.34) TWiki webs:
Dev | Doc | Main | TWiki | Sandbox
Dev . { Changes | Index | Search | Go }
 <<O>>  Difference Topic EclipsePlugin (r1.34 - 19 Feb 2004 - IsaacGouy)
Added:
>
>

Would it be possible to use the default colours used by the Java Editor (until we implement a Window / Preferences / Nice / Syntax notecard for selecting colours -- IsaacGouy - 19 Feb 2004


 <<O>>  Difference Topic EclipsePlugin (r1.33 - 17 Dec 2003 - DanielBonniot)
Changed:
<
<

A distributable zipped archive version is available here.

>
>

A distributable zipped archive version is available here.

Changed:
<
<

If you downloaded the zipped plugin from http://sf.net/projects/nice then all you have to do is to extract the zip archive and move the plugin folder in the eclipsehome/plugins folder.

>
>

If you downloaded the zipped plugin then all you have to do is to extract the zip archive and move the plugin folder in the eclipsehome/plugins folder.


 <<O>>  Difference Topic EclipsePlugin (r1.32 - 10 Sep 2003 - AlexGreif)
Added:
>
>

Installation

If you downloaded the zipped plugin from http://sf.net/projects/nice then all you have to do is to extract the zip archive and move the plugin folder in the eclipsehome/plugins folder.

If you got the CVS version, then type:

ant install
This will build the plugin sources and and install the plugin folder in the eclipsehome/plugins folder. Older versions will be removed.

 <<O>>  Difference Topic EclipsePlugin (r1.31 - 10 Sep 2003 - AlexGreif)
Changed:
<
<

The plugin sources are accessible by CVS in the module "eclipse"

>
>

The plugin sources are accessible by CVS in the module "eclipse".
A distributable zipped archive version is available here.


 <<O>>  Difference Topic EclipsePlugin (r1.30 - 10 Sep 2003 - AlexGreif)
Changed:
<
<

    • opening Nice files in a simple editor
>
>

    • opening Nice files in a Nice editor that uses Syntax highlighting
Added:
>
>

    • design of basic icons
Deleted:
<
<

    • design basic icons
Deleted:
<
<

    • syntax highlighting
    • design icons
Changed:
<
<

the downloadable tarball contains plugin. you can download here:
nice_plugin

>
>

The plugin sources are accessible by CVS in the module "eclipse"

Deleted:
<
<

In near future the plugin sources will be accessible by CVS.

Added:
>
>

Build

Use jakarta Ant to build the plugin. In the file nice_plugin_build.properties you have to adjust the following properties:
  • nice.runtime - path to the nice.jar file
  • eclipse.home - path to the eclipse home folder

The following targets are available:

  • compile - compiles all nice sources and creates a "niceplugin.jar" in the build folder
  • dist - creates distributable versions of the plugin (.tar, .tgz, .zip) in the dist folder
  • install - deletes old plugin version s from the %eclipse_home%/plugins folder and installs there the latest one
Deleted:
<
<

Install

Put the nice plugins in the %eclipse_home%/plugins folder and restart eclipse.
Changed:
<
<

  • download the plugin tarball
  • expand the tarball into eclipse/plugins
>
>

  • install the plugin with Ant as described before

 <<O>>  Difference Topic EclipsePlugin (r1.29 - 01 Aug 2003 - AlexGreif)
Added:
>
>

What is it?

The "Nice Eclipse Plugin" is a plugin for the open source Eclipse IDE. It is possible to extend the platforms functionality by new third-party plugins. This plugin enables developers to manage and compile nice project in Ecpilse. Every Eclipse plugin has a unique ID, the ID of the Nice plugin is "net.sf.nice".

The funny thing is that the plugin itself is written completely in Nice.

enjoy!

Changed:
<
<

    • design basic icons
    • Nice general Preferences: panels are there, and a sample editor pref. is finished
    • the nice.jar is integrated in a plugin
    • projectProperties implemented (only a dummy and skeleton) invokable only in resources persp.
    • niceBuilder installed that knows how to build the project (just the skeleton)
>
>

    • the nice.jar is integrated in the plugin lib/ folder
    • projectProperties implemented, invokable only in resources perspective
    • niceBuilder implemented that knows how to build the project
    • compiled binaries a re stored in a jar file. If no jar file name is specified in the project properties panel, then the name of the jar file is by default "project.jar"
Changed:
<
<

    • compilation progress is implemented, messages are shown too
    • project properties contains name of compiled jar and classpath edit possibility
    • display errors in double-clickable way, in the problems view
>
>

    • compilation progress is implemented
    • compilation errors and warnings are listed in the "Problems View"
Added:
>
>

    • design basic icons
    • Nice general Preferences
Changed:
<
<

The plug-in consists of three plugins:

  • net.sf.nice.core
  • net.sf.nice.ui
  • net.sf.nice.compile

the downloadable jar (v0.0.7) contains the two folders. you can download here:

>
>

the downloadable tarball contains plugin. you can download here:

Added:
>
>

In near future the plugin sources will be accessible by CVS.

Added:
>
>

Usage

  • download the plugin tarball
  • expand the tarball into eclipse/plugins
  • start/restart eclipse
  • create a project of type "Nice Project" with the name "nice1"
  • change to the "Resources Perspective"
  • create a new Folder for the main package like "test"
  • click on the "nice1" folder
  • Menu "Project"->"Properties"
  • select "Nice Project Properties"
  • set main package: test
  • leave classpath empty
  • set jar name: nice1.jar
  • create a new file "test.nice" in the "test" package
  • type VALID code in "test.nice"
  • save the file

now compilation should be started
a file nice1.jar is created in the "eclipse/workspace/nice1" folder

  • make the code invalid
  • save again

the error is reported to the console for debugging reasons
a "Problems" view should be opened with the error/errors

if the view is still empty then click on the black triangle on the right of the problems view title bar

Added:
>
>

select "Filters..."
check "Nice Problem"

  • doubleclick on the problem entry -> select the line in the nice code
Changed:
<
<

-- AlexGreif - 08 Jun 2003

>
>

or look at the logfiles

  • eclipsehome/workspace/.log
  • eclipsehome/runtime-workspace/.log
Deleted:
<
<

I just tried the plugin. Installation was very easy! I could create a new project, a new folder hello, and a file hello.nice. To go farther, I would need to be able to compile my project! :-)

Question:
If I understand well, a perspective is a set of windows that fill the screen at some point. The Nice perspective has "Nice resources" and the text editor. Note that when I created a Nice project, it did not switch automatically to the Nice perspective. Is this normal? -- DanielBonniot - 10 Jun 2003

Answer:
I will investigate how to set the default perspective. -- AlexGreif - 12 Jun 2003

Question:
In the "resource" perspective, there is a "task" window. That's where compilation errors will go in the future, right? -- DanielBonniot - 10 Jun 2003

Answer:
In the first drop we will present all compiler output in a console window. But later, yes the task view will list all errors and warnings... and the user can then double-click the error and lands in the appropriate line. -- AlexGreif - 12 Jun 2003

Deleted:
<
<

The compilation listener is already implemented. So maybe you can skip the console step. --Daniel


 <<O>>  Difference Topic EclipsePlugin (r1.28 - 19 Jun 2003 - AlexGreif)
Added:
>
>

    • display errors in double-clickable way, in the problems view
Deleted:
<
<

    • display errors in double-clickable way
Changed:
<
<

the downloadable jar (v0.0.6) contains the two folders. you can download here:

>
>

the downloadable jar (v0.0.7) contains the two folders. you can download here:


 <<O>>  Difference Topic EclipsePlugin (r1.27 - 18 Jun 2003 - DanielBonniot)
Added:
>
>

Changed:
<
<

CompilationListener

One improvement I want to make to the compiler interface is to create a CompilationListener interface. It would receive messages that describe how the compilation is going. Incidentally, I will completely separate the console compiler in nice.tools.compiler.console. The package nice.tools.compiler will only hold the high-level, java/nice compilation api.

A first idea for the listener is:

interface CompilationListener
{
  error  (Location location, String message);
  warning(Location location, String message);

  /** Reports the progress of compilation.
      phase can be: parsing, type-checking, generating code, ...
      the package can be null if the phase applies to the whole program (testing dispatch, creating the archive, compiling to native code, ...).
  */
  progress(?String package, String phase);
}
Comments?

I might work on this today.

-- DanielBonniot - 11 Jun 2003

I would add a method "message(String)" for general messages.

All messages should be identified by a precise kind, I think. --Daniel

ASAIK other compilers go the other way:

interface CompilationListener {
  message(CompilationMessage);
}

class CompilationMessage {
  String getText()
}

class Error extends CompilationMessage {
  int getLine();
}

class Warning extends CompilationMessage {
 int getLine()
}

class Progress extends CompilationMessage {
  String getPackage();
}

-- AlexGreif - 12 Jun 2003

Is this better? One drawback is that it encourages to catch the generic message, thus losing information. I think a listener will take different actions depending on the kind of message, so we might as well call different methods for that. --Daniel

>
>

Interfacing with the compiler

Changed:
<
<

I dont know it this is better, Pizza did it this way and I think javac too. I was quite happy with this solution. There are only some types of Information that the compiler returns, so may be both are good. We schould start with yours and see how it involvs. -- AlexGreif - 12 Jun 2003

>
>

See CompilationAPI.


 <<O>>  Difference Topic EclipsePlugin (r1.26 - 18 Jun 2003 - AlexGreif)
Added:
>
>

    • project properties contains name of compiled jar and classpath edit possibility
Changed:
<
<

the downloadable jar (v0.0.5) contains the two folders. you can download here:

>
>

the downloadable jar (v0.0.6) contains the two folders. you can download here:


 <<O>>  Difference Topic EclipsePlugin (r1.25 - 15 Jun 2003 - AlexGreif)
Changed:
<
<

with Nice Project I mean a special eclipse project Type, that was created by menu =File > new... > Project... > Nice =. A Nice-Project knows which filetypes how to handle and how to invoke the compiler ... -- AlexGreif - 12 Jun 2003

>
>

with Nice Project I mean a special eclipse project Type, that was created by menu File > new... > Project... > Nice =. A Nice-Project knows which filetypes how to handle and how to invoke the compiler. In eclipse the terminus =Nature makes it possible that projects behave differently -- AlexGreif - 15 Jun 2003

Deleted:
<
<

Added:
>
>


 <<O>>  Difference Topic EclipsePlugin (r1.24 - 14 Jun 2003 - AlexGreif)
Added:
>
>

Added:
>
>

Added:
>
>

Added:
>
>

Added:
>
>

Eclipse Naming Conventions


 <<O>>  Difference Topic EclipsePlugin (r1.23 - 14 Jun 2003 - AlexGreif)
Changed:
<
<

    • invoking the compiler. Only on projects that's root package is "test"!
>
>

    • the main package can be set on the projects property page
    • invoking the compiler.
    • compilation progress is implemented, messages are shown too
Deleted:
<
<

    • project preferences
    • activate compiler
    • display compiler output in console
Changed:
<
<

the downloadable jar (v0.0.4) contains the two folders. you can download here:

>
>

the downloadable jar (v0.0.5) contains the two folders. you can download here:


 <<O>>  Difference Topic EclipsePlugin (r1.22 - 14 Jun 2003 - AlexGreif)
Added:
>
>

    • invoking the compiler. Only on projects that's root package is "test"!
Added:
>
>

    • project preferences
Changed:
<
<

the downloadable jar (v0.0.3) contains the two folders. you can download here:

>
>

the downloadable jar (v0.0.4) contains the two folders. you can download here:


 <<O>>  Difference Topic EclipsePlugin (r1.21 - 13 Jun 2003 - AlexGreif)
Added:
>
>

    • projectProperties implemented (only a dummy and skeleton) invokable only in resources persp.
    • niceBuilder installed that knows how to build the project (just the skeleton)
Changed:
<
<

the downloadable jar (v0.0.2) contains the two folders. you can download here:

>
>

the downloadable jar (v0.0.3) contains the two folders. you can download here:

Changed:
<
<

You can find a fast intro on the exclipse workbench at worbench_userguide.pdf

>
>

You can find a fast intro on the exclipse workbench at Worbench Userguide (pdf)

Plugin development guide: Plug-in Developer Guide (pdf)


 <<O>>  Difference Topic EclipsePlugin (r1.20 - 12 Jun 2003 - AlexGreif)
Changed:
<
<

Would it be easy to do the highlighting in the text editor, given this info?

>
>

Would it be easy to do the highlighting in the text editor, given this info? -- DanielBonniot

Changed:
<
<

It should probably be started in a low-priority thread, so it does not slow-down the system when writing.

>
>

That ist my third suggestion. Isnt'it? -- AlexGreif - 12 Jun 2003

It should probably be started in a low-priority thread, so it does not slow-down the system when writing. -- DanielBonniot

I have to examine how to start threads in eclipse. I think eclipse hast its own way to handle threads. -- AlexGreif - 12 Jun 2003

Changed:
<
<

If we think, in the long term, about refactoring, showing the definition of a class and automatic completion, which basically mean parsing the whole program, this could be seen as duplicating effort. On the other hand, it could be nice to have syntax highlighting on syntactically incorrect programs (when you are writing a method, and it is not finished yet), and then SyntaxHighlighter? needs to be quite different from a normal parser anyway.

>
>

If we think, in the long term, about refactoring, showing the definition of a class and automatic completion, which basically mean parsing the whole program, this could be seen as duplicating effort. On the other hand, it could be nice to have syntax highlighting on syntactically incorrect programs (when you are writing a method, and it is not finished yet), and then SyntaxHighlighter? needs to be quite different from a normal parser anyway. -- DanielBonniot

Changed:
<
<

Do we know how code completion works in eclipse plugins?

>
>

Maybe thats the way they have siple word matcher for syntax Highlighting -- AlexGreif - 12 Jun 2003

Changed:
<
<

Thoughts?

>
>

Do we know how code completion works in eclipse plugins? -- DanielBonniot

Changed:
<
<

-- DanielBonniot

>
>

not yet :)) -- AlexGreif - 12 Jun 2003

Changed:
<
<

Should there be a way to specify compilation options (the main package, class directory, classpath...). These are per-project setups, so I don't think they should go in the global preferences. -- DanielBonniot

>
>

Should there be a way to specify compilation options (the main package, class directory, classpath...). -- DanielBonniot

Changed:
<
<

we should specify the most necessary things in the main preferences (Menu Window > Preferences > Nice) -- AlexGreif

>
>

we should specify the most necessary things in the main preferences (Menu Window > Preferences > Nice). And project specific preferences can be set in the project itself. -- AlexGreif

Added:
>
>

Its another ant plugin. I deleted it two days before so I cannot tell whats it exacly doing. But it helps with editing the ant script maybe in a graphical way -- AlexGreif - 12 Jun 2003


 <<O>>  Difference Topic EclipsePlugin (r1.19 - 12 Jun 2003 - DanielBonniot)
Added:
>
>

For syntax highlighting, it seems to me the best would be to implement an generic SyntaxHighlighter?. It would take as input a java.io.Writer, and return as output a list of specifications: at such position there is a keyword, at such other position there is the name of a variable being defined, ... Would it be easy to do the highlighting in the text editor, given this info?

Added:
>
>

It should probably be started in a low-priority thread, so it does not slow-down the system when writing.

A good thing is that SyntaxHighlighter? could be shared among several editors (think JEdit).

If we think, in the long term, about refactoring, showing the definition of a class and automatic completion, which basically mean parsing the whole program, this could be seen as duplicating effort. On the other hand, it could be nice to have syntax highlighting on syntactically incorrect programs (when you are writing a method, and it is not finished yet), and then SyntaxHighlighter? needs to be quite different from a normal parser anyway.

Do we know how code completion works in eclipse plugins?

Thoughts?

-- DanielBonniot

Changed:
<
<

Should there be a way to specify compilation options (the main package, class directory, classpath...). -- DanielBonniot

>
>

Should there be a way to specify compilation options (the main package, class directory, classpath...). These are per-project setups, so I don't think they should go in the global preferences. -- DanielBonniot

Added:
>
>

I managed to compile a Nice project, by writing a ant build file! The editing was in a text window, but there was automatic tag completion. Is this what you were refering to, or is there something more user-friendly? -- DanielBonniot


 <<O>>  Difference Topic EclipsePlugin (r1.18 - 12 Jun 2003 - AlexGreif)
Changed:
<
<

  • List of Classes that contain info about CharRange?+Style+Color
>
>

  • List of Classes that contain info about CharRange+Style+Color

 <<O>>  Difference Topic EclipsePlugin (r1.17 - 12 Jun 2003 - AlexGreif)
Added:
>
>

Question:

Added:
>
>

Answer:
with Nice Project I mean a special eclipse project Type, that was created by menu =File > new... > Project... > Nice =. A Nice-Project knows which filetypes how to handle and how to invoke the compiler ... -- AlexGreif - 12 Jun 2003

Added:
>
>

If you build the project by ant, in a java-Project, all ant compilation errrors are "routed" in the Task view. If a java-project can to this, then we should be able to do this too :) -- AlexGreif - 12 Jun 2003

Added:
>
>

I dont know it this is better, Pizza did it this way and I think javac too. I was quite happy with this solution. There are only some types of Information that the compiler returns, so may be both are good. We schould start with yours and see how it involvs. -- AlexGreif - 12 Jun 2003

Changed:
<
<

    • class, interface - green you mean the class name?
>
>

    • class, interface - green you mean the class name? I mean the words "class" and "interface" themselves. It is just an example.

All editors that I know use the second way, they scan the source for strings and apply the rules in for of setting style and color.

Changed:
<
<

It seems that we need three parsers, for the compiler (can be used for refactoring too), NiceDoc, and syntax highlighting. They are similar, but have different requirement. Does anybody know a way to share the common parts, while getting the different behaviours?

>
>

It seems that we need three parsers, for the compiler (can be used for refactoring too), NiceDoc, and syntax highlighting. They are similar, but have different requirement. Does anybody know a way to share the common parts, while getting the different behaviours? -- DanielBonniot - 12 Jun 2003

Changed:
<
<

-- DanielBonniot - 12 Jun 2003

>
>

yes that would be a good thing! -- AlexGreif - 12 Jun 2003

Changed:
<
<

I think implementing simple keyword highligthing is a good start.

>
>

-- AlexGreif - 12 Jun 2003

I think implementing simple keyword highligthing is a good start. -- DanielBonniot - 12 Jun 2003

OKwe will take this for the first proto , then I can use the Ruby example :)) They do it the simple way too -- AlexGreif - 12 Jun 2003

Changed:
<
<

Compiler Invocation

>
>

I would prefer the parser in the final solution.

The question is, how should the parser return the syntax information?

  • xml?
  • proprietary format?
  • List of Classes that contain info about CharRange?+Style+Color
Changed:
<
<

In the first run I will embed the nice.jar in the temporary (net.sf.nice.compile) plugin. This makes it fast to implement the plugin proto. If we get more experience how to handle only one nice.jar on the whole system, we will get rid of this temp plugin.

>
>

It depends how eclipse allows us to implement it, but IMO the third one is the best.

Deleted:
<
<

Should there be a way to specify compilation options (the main package, class directory, classpath...). Or should we require that the user writes an Ant build file to do that? (Is there a good assistant to write build files? Or maybe the nice plugin could contain an editor to create sections in a ant build file specifically for the nicec target, listing the available options?).

Changed:
<
<

-- DanielBonniot - 12 Jun 2003

>
>

Compiler Invocation

In the first run I will embed the nice.jar in the temporary (net.sf.nice.compile) plugin. This makes it fast to implement the plugin proto. If we get more experience how to handle only one nice.jar on the whole system, we will get rid of this temp plugin. -- AlexGreif - 12 Jun 2003

Question:
Should there be a way to specify compilation options (the main package, class directory, classpath...). -- DanielBonniot

Answer:
we should specify the most necessary things in the main preferences (Menu Window > Preferences > Nice) -- AlexGreif

Question:
Or should we require that the user writes an Ant build file to do that? (Is there a good assistant to write build files? Or maybe the nice plugin could contain an editor to create sections in a ant build file specifically for the nicec target, listing the available options?). -- DanielBonniot - 12 Jun 2003

Answer:
Only ant script is not enough. Its not very user friendly. There is another plugin that lets one build ant scripts. we can make our plugin dependant on the ant-plugin. -- AlexGreif


 <<O>>  Difference Topic EclipsePlugin (r1.16 - 12 Jun 2003 - ArjanB)
Added:
>
>

I think implementing simple keyword highligthing is a good start.

We don't need three parsers because the NiceDoc comments could be parsed by the compiler and be put in the AST. This allow better linking between NiceDoc pages because the compiler can know wich method implementation belongs to which method definition and vice versa.

The parser for the plugin could be a lot simpler than the one for the compiler so sharing common parts might be not worth the effort.

-- ArjanB


 <<O>>  Difference Topic EclipsePlugin (r1.15 - 12 Jun 2003 - DanielBonniot)
Changed:
<
<

    • Nice genaral Preferences: panels are there, and a sample editor pref. ist finished
    • the nice.jar is intergrated in a plugin
>
>

    • Nice general Preferences: panels are there, and a sample editor pref. is finished
    • the nice.jar is integrated in a plugin
Changed:
<
<

  • Plug-in Details
  • Configuration Detalis
>
>

  • Plug-in Details (the more info button should link to this page)
  • Configuration Details
Added:
>
>

The compilation listener is already implemented. So maybe you can skip the console step. --Daniel

Added:
>
>

What is Nice-Project? --Daniel

Added:
>
>

Yes. But if the compiler was invoked by ant, I wonder how the information can be passed to eclipse through ant. --Daniel

Added:
>
>

All messages should be identified by a precise kind, I think. --Daniel

Added:
>
>

Is this better? One drawback is that it encourages to catch the generic message, thus losing information. I think a listener will take different actions depending on the kind of message, so we might as well call different methods for that. --Daniel

Added:
>
>

At the moment, the compilation API only allows a full compilation. It would not be very difficult to add an API to get an AST. It just needs to be defined: should we pass a package name and get back a list of AST for all files in this package and the imported packages? Or work on a file-by-file basis?

Pretty printing would need to be written (at the moment there is a toString method, but it won't create indentation, for instance). I'd suggest writing a Nice multi-method for pretty-printing, so it could be kept in a separate package. The root class for an AST is bossa.syntax.AST.

-- DanielBonniot

Changed:
<
<

    • class, interface - green
>
>

    • class, interface - green you mean the class name?
Added:
>
>

The parser is not very adapted for syntax highlighting because:

  • it skips comments
  • it does remember the location of keywords

It seems that we need three parsers, for the compiler (can be used for refactoring too), NiceDoc, and syntax highlighting. They are similar, but have different requirement. Does anybody know a way to share the common parts, while getting the different behaviours?

-- DanielBonniot - 12 Jun 2003

Added:
>
>

Should there be a way to specify compilation options (the main package, class directory, classpath...). Or should we require that the user writes an Ant build file to do that? (Is there a good assistant to write build files? Or maybe the nice plugin could contain an editor to create sections in a ant build file specifically for the nicec target, listing the available options?).

-- DanielBonniot - 12 Jun 2003


 <<O>>  Difference Topic EclipsePlugin (r1.14 - 12 Jun 2003 - AlexGreif)
Added:
>
>

    • the nice.jar is intergrated in a plugin
Changed:
<
<

The plug-in consists of two plugins:

>
>

The plug-in consists of three plugins:

Added:
>
>

  • net.sf.nice.compile
Changed:
<
<

the downloadable jar contains the two folders. you can download here:

>
>

the downloadable jar (v0.0.2) contains the two folders. you can download here:

Changed:
<
<

Put nice plugins in the %eclipse_home%/plugins folder and restart eclipse.

>
>

Put the nice plugins in the %eclipse_home%/plugins folder and restart eclipse.


 <<O>>  Difference Topic EclipsePlugin (r1.13 - 12 Jun 2003 - AlexGreif)
Added:
>
>

    • Nice genaral Preferences: panels are there, and a sample editor pref. ist finished
Deleted:
<
<

    • Nice project Properties (eg. location of nice.jar)
Added:
>
>

    • Nice compiler should use a central nice.jar on the system
Changed:
<
<

The plug-in consists of two parts:

>
>

The plug-in consists of two plugins:

Changed:
<
<

Put these two folders in the %eclipse_home%/plugins folder and restart eclipse.

>
>

Put nice plugins in the %eclipse_home%/plugins folder and restart eclipse.

Troubleshooting

If you experience an unexpected behaviour sheck the following by Menu Help > About Eclipse Platform >

  • Plug-in Details
  • Configuration Detalis
Added:
>
>

Documentation

You can find a fast intro on the exclipse workbench at worbench_userguide.pdf
Changed:
<
<

If I understand well, a perspective is a set of windows that fill the screen at some point. The Nice perspective has "Nice resources" and the text editor. Note that when I created a Nice project, it did not switch automatically to the Nice perspective. Is this normal? In the "resource" perspective, there is a "task" window. That's where compilation errors will go in the future, right?

>
>

Question:
If I understand well, a perspective is a set of windows that fill the screen at some point. The Nice perspective has "Nice resources" and the text editor. Note that when I created a Nice project, it did not switch automatically to the Nice perspective. Is this normal? -- DanielBonniot - 10 Jun 2003

Answer:
I will investigate how to set the default perspective. -- AlexGreif - 12 Jun 2003

Question:
In the "resource" perspective, there is a "task" window. That's where compilation errors will go in the future, right? -- DanielBonniot - 10 Jun 2003

Answer:
In the first drop we will present all compiler output in a console window. But later, yes the task view will list all errors and warnings... and the user can then double-click the error and lands in the appropriate line. -- AlexGreif - 12 Jun 2003

Question:
How will this work in a multi-language project (say, Nice and Java, like in the Nice compiler source)? The source files will be opened in different editors, depending on the extension? -- DanielBonniot - 10 Jun 2003

Answer:
Yes, in the Nice-Project, that can contain diffferent file types, always the appropriate editor is opened. -- AlexGreif - 12 Jun 2003

Question:
If I write an ant build file for that project, will it be possible that compile errors are parsed correctly, depending on whether they come from javac and nicec?

Changed:
<
<

How will this work in a multi-language project (say, Nice and Java, like in the Nice compiler source)? The source files will be opened in different editors, depending on the extension? If I write an ant build file for that project, will it be possible that compile errors are parsed correctly, depending on whether they come from javac and nicec? Does eclipse support Makefile too? I know, these are advanced features. I'm just curious. For the moment, support for Nice-only projects would already be great. Keep up the good work! -- DanielBonniot - 10 Jun 2003

>
>

Answer:
all errors should land in the task view, independently from which compiler. This is the desired solution. Isn't it? -- AlexGreif - 12 Jun 2003

Question:
Does eclipse support Makefile too?

Answer:
I dont know, we have to look :) -- AlexGreif - 12 Jun 2003

I know, these are advanced features. I'm just curious. For the moment, support for Nice-only projects would already be great. Keep up the good work! -- DanielBonniot - 10 Jun 2003

Changed:
<
<

This plugin is a good reason for me to try out eclipse.

>
>

This plugin is a good reason for me to try out eclipse. -- ArjanB

Deleted:
<
<

If you need it, I want to help the syntax highlighting since I familiar with the grammar of Nice and I have some time. -- ArjanB

Added:
>
>

CompilationListener

Added:
>
>

I would add a method "message(String)" for general messages.

ASAIK other compilers go the other way:

interface CompilationListener {
  message(CompilationMessage);
}

class CompilationMessage {
  String getText()
}

class Error extends CompilationMessage {
  int getLine();
}

class Warning extends CompilationMessage {
 int getLine()
}

class Progress extends CompilationMessage {
  String getPackage();
}

-- AlexGreif - 12 Jun 2003

AST

Added:
>
>

Syntax Highlighting

If you need it, I want to help the syntax highlighting since I familiar with the grammar of Nice and I have some time. -- ArjanB

We have to collect ideas how to realize syntax highlighting. My suggestion is

  • when the user types nice code then the parser should be called immediately to return the sequences that should be highlighted
  • or as an easy, static, alternative we define a set of syntactic rules like
    • comment - red
    • keywords - blue
    • class, interface - green

I think the first suggestion is better, because we let the nice parser determine which words are highlighted. On the other hand we have to measure how performant on the fly parsing is.

Maybe there is a way in eclipse to parse only the relevant parts of the edited document, and not the whole file all the time. -- AlexGreif - 12 Jun 2003

Compiler Invocation

In the first run I will embed the nice.jar in the temporary (net.sf.nice.compile) plugin. This makes it fast to implement the plugin proto. If we get more experience how to handle only one nice.jar on the whole system, we will get rid of this temp plugin.

-- AlexGreif - 12 Jun 2003


 <<O>>  Difference Topic EclipsePlugin (r1.12 - 11 Jun 2003 - ArjanB)
Added:
>
>

No, the compiler offer no easy way to obtain the AST. And pretty-printing is only very limited because it's only used for creating *.nicei files. Both things could easily be implemented once the bossa.syntax package is completely converted to Nice. -- ArjanB


 <<O>>  Difference Topic EclipsePlugin (r1.11 - 11 Jun 2003 - BrynKeller)
Added:
>
>

Looks useful to me. By the way, does the compiler offer a convenient way of obtaining the AST? Do we have a pretty-printer that will generate Nice source code from the AST? These could be important for this plugin (or others), if we want to support automated refactoring operations.

-- BrynKeller - 11 Jun 2003


 <<O>>  Difference Topic EclipsePlugin (r1.10 - 11 Jun 2003 - AlexGreif)
Changed:
<
<

  • todo
>
>

  • todo as next

 <<O>>  Difference Topic EclipsePlugin (r1.9 - 11 Jun 2003 - DanielBonniot)
Added:
>
>

Development

One improvement I want to make to the compiler interface is to create a CompilationListener interface. It would receive messages that describe how the compilation is going. Incidentally, I will completely separate the console compiler in nice.tools.compiler.console. The package nice.tools.compiler will only hold the high-level, java/nice compilation api.

A first idea for the listener is:

interface CompilationListener
{
  error  (Location location, String message);
  warning(Location location, String message);

  /** Reports the progress of compilation.
      phase can be: parsing, type-checking, generating code, ...
      the package can be null if the phase applies to the whole program (testing dispatch, creating the archive, compiling to native code, ...).
  */
  progress(?String package, String phase);
}
Comments?

I might work on this today.

-- DanielBonniot - 11 Jun 2003


 <<O>>  Difference Topic EclipsePlugin (r1.8 - 11 Jun 2003 - DanielBonniot)
Changed:
<
<

The Plug-in's progress

>
>

The Plug-in's progress

Changed:
<
<

download

>
>

Download

Changed:
<
<

install

>
>

Install

Added:
>
>

User feedback

I just tried the plugin. Installation was very easy! I could create a new project, a new folder hello, and a file hello.nice. To go farther, I would need to be able to compile my project! :-)

If I understand well, a perspective is a set of windows that fill the screen at some point. The Nice perspective has "Nice resources" and the text editor. Note that when I created a Nice project, it did not switch automatically to the Nice perspective. Is this normal? In the "resource" perspective, there is a "task" window. That's where compilation errors will go in the future, right?

How will this work in a multi-language project (say, Nice and Java, like in the Nice compiler source)? The source files will be opened in different editors, depending on the extension? If I write an ant build file for that project, will it be possible that compile errors are parsed correctly, depending on whether they come from javac and nicec? Does eclipse support Makefile too? I know, these are advanced features. I'm just curious. For the moment, support for Nice-only projects would already be great. Keep up the good work! -- DanielBonniot - 10 Jun 2003



 <<O>>  Difference Topic EclipsePlugin (r1.7 - 10 Jun 2003 - ArjanB)
Changed:
<
<

The Plug-in's progress

>
>

The Plug-in's progress

Changed:
<
<

download

>
>

download

Changed:
<
<

install

>
>

install

Changed:
<
<

User feedback

>
>

This plugin is a good reason for me to try out eclipse.

Changed:
<
<

I just tried the plugin. Installation was very easy! I could create a new project, a new folder hello, and a file hello.nice. To go farther, I would need to be able to compile my project! :-)

If I understand well, a perspective is a set of windows that fill the screen at some point. The Nice perspective has "Nice resources" and the text editor. Note that when I created a Nice project, it did not switch automatically to the Nice perspective. Is this normal? In the "resource" perspective, there is a "task" window. That's where compilation errors will go in the future, right?

How will this work in a multi-language project (say, Nice and Java, like in the Nice compiler source)? The source files will be opened in different editors, depending on the extension? If I write an ant build file for that project, will it be possible that compile errors are parsed correctly, depending on whether they come from javac and nicec? Does eclipse support Makefile too? I know, these are advanced features. I'm just curious. For the moment, support for Nice-only projects would already be great. Keep up the good work! -- DanielBonniot - 10 Jun 2003

>
>

If you need it, I want to help the syntax highlighting since I familiar with the grammar of Nice and I have some time. -- ArjanB


 <<O>>  Difference Topic EclipsePlugin (r1.6 - 10 Jun 2003 - DanielBonniot)
Changed:
<
<

The Plug-in's progress

>
>

The Plug-in's progress

Changed:
<
<

download

>
>

download

Changed:
<
<

install

>
>

install

Added:
>
>

User feedback

I just tried the plugin. Installation was very easy! I could create a new project, a new folder hello, and a file hello.nice. To go farther, I would need to be able to compile my project! :-)

If I understand well, a perspective is a set of windows that fill the screen at some point. The Nice perspective has "Nice resources" and the text editor. Note that when I created a Nice project, it did not switch automatically to the Nice perspective. Is this normal? In the "resource" perspective, there is a "task" window. That's where compilation errors will go in the future, right?

How will this work in a multi-language project (say, Nice and Java, like in the Nice compiler source)? The source files will be opened in different editors, depending on the extension? If I write an ant build file for that project, will it be possible that compile errors are parsed correctly, depending on whether they come from javac and nicec? Does eclipse support Makefile too? I know, these are advanced features. I'm just curious. For the moment, support for Nice-only projects would already be great. Keep up the good work! -- DanielBonniot - 10 Jun 2003


 <<O>>  Difference Topic EclipsePlugin (r1.5 - 09 Jun 2003 - AlexGreif)
Changed:
<
<

    • Nice project Properties
>
>

    • Nice project Properties (eg. location of nice.jar)
Added:
>
>

    • display compiler output in console
    • display errors in double-clickable way
Added:
>
>

    • debugger

 <<O>>  Difference Topic EclipsePlugin (r1.4 - 09 Jun 2003 - DanielBonniot)
Changed:
<
<

the downloadable jar contains the two folders. you can doenload here:

>
>

the downloadable jar contains the two folders. you can download here:

Changed:
<
<

Put these two folders in the %eclipse_home%/plugins folder and restart eclipse

>
>

Put these two folders in the %eclipse_home%/plugins folder and restart eclipse.


 <<O>>  Difference Topic EclipsePlugin (r1.3 - 08 Jun 2003 - AlexGreif)
Added:
>
>

    • design basic icons
Deleted:
<
<

    • design icons
Added:
>
>

    • design icons

 <<O>>  Difference Topic EclipsePlugin (r1.2 - 08 Jun 2003 - AlexGreif)
Changed:
<
<

The Plugin for the Eclipse IDE is currently in progress ...

>
>

On this page the Nice Eclipse Plug-in is described

Changed:
<
<

-- AlexGreif - 06 Jun 2003

>
>

The Plug-in's progress

  • completed parts
    • creating nice project
    • switching to Nice perspective
    • opening Nice files in a simple editor
  • todo
    • design icons
    • Nice project Properties
    • activate compiler
    • syntax highlighting
    • ...

download

The plug-in consists of two parts:
  • net.sf.nice.core
  • net.sf.nice.ui

the downloadable jar contains the two folders. you can doenload here:
nice_plugin

install

Put these two folders in the %eclipse_home%/plugins folder and restart eclipse

-- AlexGreif - 08 Jun 2003


 <<O>>  Difference Topic EclipsePlugin (r1.1 - 06 Jun 2003 - AlexGreif)
Added:
>
>

%META:TOPICINFO{author="AlexGreif" date="1054939301" format="1.0" version="1.1"}% %META:TOPICPARENT{name="WebHome"}% The Plugin for the Eclipse IDE is currently in progress ...

-- AlexGreif - 06 Jun 2003


Topic EclipsePlugin . { View | Diffs | r1.34 | > | r1.33 | > | r1.32 | More }
Revision r1.1 - 06 Jun 2003 - 22:41 GMT - AlexGreif
Revision r1.34 - 19 Feb 2004 - 18:55 GMT - IsaacGouy
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.