update: move langsymp event files to events site instead of main site

NGINX rewrites kept but moved to point at the new home under the events subsection

config/nginx/default.conf

@@ -276,76 +276,76 @@ server {
 
 
     location = /org/langsymp/A%20note%20for%20the%20Eclipse%20Language%20Conference.pdf {
-        return 301 https://$host/org/langsymp/a-note-for-the-eclipse-language-conference.pdf;
+        return 301 https://$host/events/2005/langsymp/a-note-for-the-eclipse-language-conference.pdf;
     }
     location = /org/langsymp/content/org/langsymp/Adding%20support%20for%20a%20new%20language%20to%20an%20Eclipse%20based%20.pdf {
-        return 301 https://$host/org/langsymp/adding-support-for-a-new-language-to-an-eclipse-based-ide.pdf;
+        return 301 https://$host/events/2005/langsymp/adding-support-for-a-new-language-to-an-eclipse-based-ide.pdf;
     }
     location = /org/langsymp/Ascher%20-%20Eclipse%20Position.pdf {
-        return 301 https://$host/org/langsymp/ascher-eclipse-position.pdf;
+        return 301 https://$host/events/2005/langsymp/ascher-eclipse-position.pdf;
     }
     location = /org/langsymp/CDT%20Managed%20Build%20System.pdf {
-        return 301 https://$host/org/langsymp/cdt-managed-build-system.pdf;
+        return 301 https://$host/events/2005/langsymp/cdt-managed-build-system.pdf;
     }
     location = /org/langsymp/Compiled%20Language%20Support%20In%20Eclipse.pdf {
-        return 301 https://$host/org/langsymp/compiled-language-support-in-eclipse.pdf;
+        return 301 https://$host/events/2005/langsymp/compiled-language-support-in-eclipse.pdf;
     }
     location = /org/langsymp/CraigRasmussen.pdf {
-        return 301 https://$host/org/langsymp/craig-rasmussen.pdf;
+        return 301 https://$host/events/2005/langsymp/craig-rasmussen.pdf;
     }
     location = /org/langsymp/Doug%20Lang%20Symp.pdf {
-        return 301 https://$host/org/langsymp/doug-lang-symp.pdf;
+        return 301 https://$host/events/2005/langsymp/doug-lang-symp.pdf;
     }
     location = /org/langsymp/Eclipse%20and%20Dynamic%20Languages.pdf {
-        return 301 https://$host/org/langsymp/eclipse-and-dynamic-languages.pdf;
+        return 301 https://$host/events/2005/langsymp/eclipse-and-dynamic-languages.pdf;
     }
     location = /org/langsymp/EclipseEverywhere.pdf {
-        return 301 https://$host/org/langsymp/eclipse-everywhere.pdf;
+        return 301 https://$host/events/2005/langsymp/eclipse-everywhere.pdf;
     }
     location = /org/langsymp/eclipseLanguagePosition.pdf {
-        return 301 https://$host/org/langsymp/eclipse-language-position.pdf;
+        return 301 https://$host/events/2005/langsymp/eclipse-language-position.pdf;
     }
     location = /org/langsymp/Extending%20Eclipse%20with%20Languages%20Other%20Than%20Java.pdf {
-        return 301 https://$host/org/langsymp/extending-eclipse-with-languages-other-than-java.pdf;
+        return 301 https://$host/events/2005/langsymp/extending-eclipse-with-languages-other-than-java.pdf;
     }
     location = /org/langsymp/Extending_Eclipse_with_Compiled_Languages_other_than_C.pdf {
-        return 301 https://$host/org/langsymp/extending-eclipse-with-compiled-languages-other-than-c.pdf;
+        return 301 https://$host/events/2005/langsymp/extending-eclipse-with-compiled-languages-other-than-c.pdf;
     }
     location = /org/langsymp/ExtendingEclipseInHaskell.pdf {
-        return 301 https://$host/org/langsymp/extending-eclipse-in-haskell.pdf;
+        return 301 https://$host/events/2005/langsymp/extending-eclipse-in-haskell.pdf;
     }
     location = /org/langsymp/JulianDolby_paper.pdf {
-        return 301 https://$host/org/langsymp/julian-dolby-paper.pdf;
+        return 301 https://$host/events/2005/langsymp/julian-dolby-paper.pdf;
     }
     location = /org/langsymp/lang_symposium_oct_2005.pdf {
-        return 301 https://$host/org/langsymp/lang-symposium-oct-2005.pdf;
+        return 301 https://$host/events/2005/langsymp/lang-symposium-oct-2005.pdf;
     }
     location = /org/langsymp/MImrisek_Languages_Workshop_PositionPaper.pdf {
-        return 301 https://$host/org/langsymp/m-imrisek-languages-workshop-position-paper.pdf;
+        return 301 https://$host/events/2005/langsymp/m-imrisek-languages-workshop-position-paper.pdf;
     }
     location = /org/langsymp/Multi%20Language%20Support%20-%20User%20Perspective.pdf {
-        return 301 https://$host/org/langsymp/multi-language-support-user-perspective.pdf;
+        return 301 https://$host/events/2005/langsymp/multi-language-support-user-perspective.pdf;
     }
     location = /org/langsymp/Split%20along%20Technology%20not%20Language%202005-10.pdf {
-        return 301 https://$host/org/langsymp/split-along-technology-not-language-2005-10.pdf;
+        return 301 https://$host/events/2005/langsymp/split-along-technology-not-language-2005-10.pdf;
     }
     location = /org/langsymp/StayingPragmatic.pdf {
-        return 301 https://$host/org/langsymp/staying-pragmatic.pdf;
+        return 301 https://$host/events/2005/langsymp/staying-pragmatic.pdf;
     }
     location = /org/langsymp/TestPointInPractice.pdf {
-        return 301 https://$host/org/langsymp/test-point-in-practice.pdf;
+        return 301 https://$host/events/2005/langsymp/test-point-in-practice.pdf;
     }
     location = /org/langsymp/Volanakis%20-%20Mixed-language%20usage%20scenarios.pdf {
-        return 301 https://$host/org/langsymp/volanakis-mixed-language-usage-scenarios.pdf;
+        return 301 https://$host/events/2005/langsymp/volanakis-mixed-language-usage-scenarios.pdf;
     }
     location = /org/langsymp/langsympduimovich.html {
-        return 301 https://$host/org/langsymp/common-eclipse-support-for-language-ides;
+        return 301 https://$host/events/2005/langsymp/common-eclipse-support-for-language-ides;
     }
     location = /org/langsymp/Oct2005LanguageGroup.html {
-        return 301 https://$host/org/langsymp/language-support-in-eclipse-wtp-sse;
+        return 301 https://$host/events/2005/langsymp/language-support-in-eclipse-wtp-sse;
     }
     location = /org/langsymp/position_paper_martin_aeschlimann.html {
-        return 301 https://$host/org/langsymp/a-seed-for-an-eclipse-language-toolkit;
+        return 301 https://$host/events/2005/langsymp/a-seed-for-an-eclipse-language-toolkit;
     }
     
     # Legal migration

content/org/langsymp/_index.md

----
-title: The Eclipse Languages Symposium
-hide_sidebar: true
-keywords: ["The Eclipse Languages Symposium"]
-layout: single
----
-
-## Position Papers Received So Far;
-
-- [Martin Aeschlimann "A Seed for an Eclipse Language Toolkit"](./a-seed-for-an-eclipse-language-toolkit)
-- [David Ascher "An Alien's Perspective"](./ascher-eclipse-position.pdf)
-- [Ward Cunningham "TestPoint In Practice"](./test-point-in-practice.pdf)
-- [Julian Dolby "Using Static Analysis For IDE's for Dynamic Languages"](./julian-dolby-paper.pdf)
-- [John Duimovich "Common Eclipse support for language IDE"](common-eclipse-support-for-language-ides)
-- [Brian Foote "Architectural Balkanization in the Post-Linguistic Era"](./balkanization.pdf)
-- [Bjorn Freeman-Benson "Extending Eclipse with Languages Other Than Java"](./extending-eclipse-with-languages-other-than-java.pdf)
-- [Leif Frenzel "Extending Eclipse in Haskell"](./extending-eclipse-in-haskell.pdf)
-- [Doug Gaff "Extending Eclipse with Compiled Languages Other than C/C++"](./extending-eclipse-with-compiled-languages-other-than-c.pdf)
-- [Guy Harpaz "Multi Language Support (MLS) - User perspective"](./multi-language-support-user-perspective.pdf)
-- [Martin Imrisek "Compiled Language Debug as Extensions to Platform Debug vs. Parallel Hierarchy"](./m-imrisek-languages-workshop-position-paper.pdf)
-- [Mike Milinkovich "Staying Pragmatic"](./staying-pragmatic.pdf)
-- [Jeffrey Overbey "Instant IDEs: Supporting New Languages in the CDT"](./etx-paper.pdf)
-- [Andrey Platov "Eclipse and Dynamic Languages"](./eclipse-and-dynamic-languages.pdf) (not attending)
-- [Alan Pratt "A note for the Eclipse Language Conference"](./a-note-for-the-eclipse-language-conference.pdf) (not attending)
-- [Craig Rasmussen "Native Parser/Compiler Front Ends for Eclipse?"](./craig-rasmussen.pdf)
-- [Chris Recoskie ""Compiled" Language Support in Eclipse"](./compiled-language-support-in-eclipse.pdf)
-- [Reginald Reed "Eclipse Everywhere"](./eclipse-everywhere.pdf)
-- [Doug Schaefer "Can the CDT DOM be used to represent languages other than C and C++"](./doug-lang-symp.pdf)
-- [Michael Scharf "Split along Technology not Language"](./split-along-technology-not-language-2005-10.pdf)
-- [Markus Schorn "Adding support for a new language to an Eclipse based IDE"](./adding-support-for-a-new-language-to-an-eclipse-based-ide.pdf)
-- [Mikhail Sennikovsky "CDT Managed Build System"](./cdt-managed-build-system.pdf)
-- [Leo Treggiari "Build Configurations & Tool-chains"](./lang-symposium-oct-2005.pdf)
-- [Elias Volanakis "Mixed-language usage scenarios in Eclipse"](./volanakis-mixed-language-usage-scenarios.pdf)
-- [Ed Warnicke "A Desire for a Point of Integration"](./eclipse-language-position.pdf)
-- [David Williams "Language Support in Eclipse WTP/SSE"](language-support-in-eclipse-wtp-sse)
-
-[All papers in one zip.](all.zip)
-
-## Workshop Format
-
-We'll run the workshop in the [LAWST](http://www.kaner.com/lawst.htm) / [WOPR](http://www.performance-workshop.org/content/view/28/64/) style. The workshop will have seven sessions, each with a different topic emphasis:
-
-*   Thursday 9-10:30 - Overview/Architecture
-*   Thursday 11:00-12:30 - Existing Frameworks
-*   _lunch_
-*   Thursday 1:30-3:00 - IDE for Dynamic Languages
-*   Thursday 3:30-5:00 - _wild card_
-*   _dinner_
-*   Friday 9:00-10:30 - IDE for Compiled Languages
-*   Friday 11:00-12:30 - Plug-ins Written in Other Languages
-*   _lunch_
-*   Friday 1:30-3:00 - _wild card_
-
-For each session, I will choose one of the relevant attendees to be the center of the discussion. We'll start with a question like "tell us about what you did" and the center will give us an unrehearsed, but very knowledgeable description, probably based on their position paper. Then we'll spend about half an hour discussing the center's story; questions like "how did that work?" and "how did you solve this problem?" are legitimate - questions that form little mini-lectures about "I did X" are not. Once we have extracted the center's story and commingled it with the experiences of the others, we will open the discussion up to others with similar systems, experiences, ambitions or beliefs. Here's where you can tell a bit about your story while still staying focus on the session's topic.
-
-The wild card sessions at the end of each day will be used to continue or extend interesting topics that arise during the day. They might be used for another center of discussion session or they might be used to brainstorm about direction and action items or they might be used to continue an earlier discussion or ...?
-
-## Older Paragraphs about the Workshop Format
-
-We'll run the workshop in the [LAWST](http://www.kaner.com/lawst.htm) / [WOPR](http://www.performance-workshop.org/content/view/28/64/) style. This means that all attendees must submit a position paper. No paper; no attendance; no exceptions (even Mike and I will write position papers). The position paper should be on one of the four topics:
-
-*   Eclipse Language Support for dynamically typed languages (Perl, Tcl, Python, PHP, Ruby,etc).
-*   Support for writing Eclipse plug-ins in dynamically typed languages (Python, Ruby, Tcl, etc).
-*   Generic compiled language debugging infrastructure and implementation
-*   Current state and future of the text and document model in Eclipse
-*   All issues related to supporting compiled and dynamic languages in Eclipse
-
-The intent of requiring a position paper is to (1) have everyone better prepare by writing � or at least outlining � a paper and reading all the other papers prior to a session, and (2) frankly to filter out the idly curious. These people are not unwelcome, but especially when they dilute the discussion or occupy limited seats then their attendance does not have high priority. The idea is to have brief position papers or longer, more developed papers to help each of us lead a group-wide discussion. In the most recent LAWST workshop session, several papers were only one or two pages long, and the longest was about 25 pages. The flavor is different than traditional conferences, with mostly one-way communication to a large group. These workshop sessions are more like small group peer reviews with lots of impromptu brainstorming.
-
-The position papers are all distributed (email) in advance. The papers will be grouped into approximately six sessions. Not all papers will be included (there might just not be a logical place). Each session will start with presentations by the select authors. Not slick powerpoint presentations, but more of an interactive talk: the author will describe his or her experiences, ideas, difficulties, and so on. A couple powerpoint slides or, better yet, a demo, are acceptable, but the key here is that this is a workshop - an interactive conversation - not a lecture. In general, the talk should be about successes and future successes, but instructive failures are also welcome. After the war stories, there is general discussion between the audience and the speakers - the key feature of the discussion is that it stays focused on the speakers' points and does not devolve into each audience member giving a short speech about his or her own ideas.
-
-## Logistics
-
-*   The symposium will be held October 27th and 28th at the QNX headquarters at [175 Terence Matthews Crescent, Kanata, ON, Canada](http://maps.google.com/maps?q=175+Terence+Matthews+Cres,+Kanata,+ON,+Canada&spn=0.003736,0.005657&t=k&hl=en). There is no registration fee for this workshop which also means that you're responsible for your own transportation and accommodation. Sharon (the Eclipse administrator and Ottawa resident) suggests these hotels:
-    *   [Holiday Inn Select](http://www.ichotelsgroup.com/h/d/hi/1/en/hd/yowow?irs=null)    Middle of the road
-    *   [Brookstreet](http://www.brookstreethotel.com/reach_us/)        High end
-    *   [Days Inn](http://www.daysinnottawawest.com/cont.htm)         BasicThey are all about 10-15 minutes by car from QNX.
-*   We will begin each day at 8:30am 9:00am. Not everyone can attend both days (some people are in the CDT workshop that overlaps by a day; some people have early flights out on Friday), but we'll do the best we can. We will have a group dinner outing Thursday evening.
-*   The CDT Workshop that we are overlapping with is holding a party Wednesday night, October 26th and we're all invited. [Linda Campbell](mailto:linda@qnx.com) of QNX would like your RSVP if you plan to attend so that she can order enough food. The details are:
-    *   Pizza, Beer, Pool @ Le Skratch - [1642 Merivale Road, Nepean, Ontario](http://maps.google.com/maps?q=1642+Merivale+Road,+Nepean,+Ontario&t=k&iwloc=A&hl=en) - 6:30 p.m. until 9:00 p.m or later.
-
-### The CDT Workshop
-
-Note that QNX is hosting the CDT workshop Tue-Wed-Thurs at the same location. In fact, it is QNX's generosity with their space that allows this Languages Workshop to occur. The key thing to remember is that the CDT Workshop (Tue-Wed-Thurs) is separate from the Languages Workshop (Thurs-Fri). They are co-located to take advantage of many of your travel plans, but they are separate events. I'm not organizing the CDT Workshop; I am organizing the Languages Workshop. 
-
-## Goal of the Languages Symposium
-
-The goal is to get a group of smart engineers and researchers together for two days to talk about, and plan the future of, language support in Eclipse. The symposium will be a very interactive workshop - not a conference with formal papers and lots of bored listeners reading email on their laptops.
-
-## Deadlines
-
-The original deadline was Friday, October 14th, but we all know that these things slip a bit, so the new deadline is a week later: Friday, October 21st. But I'm still happy to accept very very late papers - so send them in.
-
-To attend, you must submit a position paper.
\ No newline at end of file

content/org/langsymp/a-seed-for-an-eclipse-language-toolkit.md

----
-title: A Seed for an Eclipse Language Toolkit
-hide_sidebar: true
----
-
-## Martin Aeschlimann, IBM Research Zurich
-
-Position paper for the Eclipse Language Symposium in Ottawa (October 2005)  
-  
-
-## My background
-
-I'm a member of the Eclipse JDT UI team since its beginning. Responsibilities are the quick fix feature, including the underlying code rewriting infrastructure. I'm in close contact with the JDT model and DOM-AST and also helped there evolving these APIs. I happened to be the author of a 3 week C-plug-in prototype that later became be the seed for the current CDT plug-in.
-
-## Motivation
-
-The approach taken when implementing this CDT prototype was to follow the concepts and structure of the JDT plug-in. Eclipse gives you comprehensive support to integrate (e.g. building, launching, compare and search) and reusing/extending existing components like editors with outline views. Still there were parts that had to been copied; most notable the language model infrastructure.
-
-Several other language plug-in implementations followed that same way and duplicated again the same code, resulting in the desire that Eclipse should provide a common infrastructure for language models to avoid code duplication.
-
-API is always costly in creation and especially in maintenance. It introduces new dependencies that can hinder innovation as you get locked into solutions.  JDT was therefore very conservative investing work towards this topic. However, more infrastructure has significant benefits. For developers it's a time saver, users get language plug-ins, faster and maybe designed more consistently, and the Eclipse platform wins by providing new infrastructure.
-
-To summarize, the goals are:  
-
-*   Distill the JDT / Platform proven concepts so they can also be used for new language plug-ins.  
-*   A fresh look at the problem, make is as simple as possible. Start fresh and don't have the goal to bring existing plug-ins into the framework. Gain more experience with new language plug-ins to create new infrastructure and improve existing plug-ins in this direction.
-*   Provide a seed with the goal to be grown by the community
-
-## Proposal  
-
-In my proposal for a seed, I would like to look at the problem from a compiler and not from an editor or explorer perspective. A compiler's inputs are tokens and it uses parsers to build syntax trees. Most of the tooling for a language plug-in (e.g. refactoring, quick fix) directly works on ASTs. The proposal therefore 'structures' the language model along these lines and use _tokens_, _AST nodes_, _token streams_ and _parser_ as foundation for a language independent toolkit.
-
-The interesting question is, what kind of concepts are needed as a foundation to implement as much concrete functionality as possible?  
-Only having AST nodes and tokens will not be enough. For example it would not be possible to show an outline (of declarations) in a generic way. The solution is to add additional information to AST nodes such as structural information. This additional information can be annotations on the node itself or provided by visitors that calculate it.  
-
-This is a sketch of abstractions, concrete type names have been used for illustration only:  
-
-*   **ILanguageModel**: access point to the languages infrastructure  
-    *   getTokenStream(ISourceElement) : ITokenStream   
-    *   createAST(ITokenStream) : AST
-*   **ITokenStream**
-    *   getNextToken(): ITokenNode
-*   **IAST**
-    *   getASTRoot(): IASTNode
-    *   findNode(position)
-
-The types ITokenNode and IASTNode could both be unified using INode
-
-*   **ITokenNode**: abstract base class for tokens
-*   **IASTNode**: abstract base class for AST nodes: has parent (AST node) and children (nodes: AST nodes and tokens), provides functionality to traverse children and to the node type  
-*   **INodeType**: meta information describing token types and AST node types  
-    *   what are the children for a node of this type: what token types what node types, are they mandatory  
-    *   which nodes are declarations    
-
-Languages often have the concept of declarations and references to these declarations. A resolver connects references to declarations  
-
-*   **IResolver**
-    *   Given a AST node, find the corresponding declaration (to be discussed in what format)  
-
-The following sections describe what language neutral infrastructure can be built using these abstractions:  
-
-*   **Handle based elements**: ASTs are usually expensive to build and to keep in memory. There's a need for a more lightweight element that can be used e.g. by viewers. These elements are created from the AST, but don't hold a reference to it. They can rebuild the underlying AST anytime when required.  
-The handles are usualy only a subset of the existing AST nodes, typically all declarations.  
-    *   **NodeHandle**  
-        *   Inexpensive representatation of an AST node that can be shown in viewer. Does not hold on the full AST, but can rebuild AST if necessary  
-        *   Handles: Might not exist anymore (or not yet)  
-        *   can be stored/restored using mementos
-*   **Search index**: Indexing declarations and references
-*   **AST flattening** and **code formatting** using the AST node type properties
-*   **AST rewriting** infrastructure using AST flattening and code formatting
-
-  
-On the user interface front it is now possible to implement a 'generic editor':  
-
-*   **syntax highlighting** from token streams
-*   **structure views** (Outlines) from handle based elements  
-*   **code resolve** ('Open Declaration F3') using the resolver  
-*   **structured selection expansion** (Source > Expand Selection) and **bracket matching** using AST nodes
-*   **mark occurrences** and **local (linked) rename** with the resolver
-*   **auto-indent** using the formatter
-*   ...
-
-It has to be noted that using such a generic editor is good to get quick results for new plug-ins. It is likely that language plug-in will use the generic editor as a base, but extend with language specific features.  
-  
-Optional opportunities (extra plug-ins):  
-
-*   Generation of compatible scanners and ASTs from a grammar
\ No newline at end of file

content/org/langsymp/common-eclipse-support-for-language-ides.md

----
-title: Common Eclipse support for language IDEs
-hide_page_title: true
-hide_sidebar: true
----
-
-  
-# Common Eclipse support for language IDEs Position Paper for Eclipse Languages Symposium  
-
-John Duimovich  
-October 21, 2005
-
-**Position**
-
-I am interested in making it simpler to create new programmming language IDEs for the Eclipse platform. I am motivated by my work on a Smalltalk IDE for Eclipse in which I found I was writing too much code for the functionality I was getting in return. I found that was that much of the code ends up being very similiar to code found in JDT and CDT. In fact, it has become a common joke that the way to get a new IDE for eclipse, is to take code from JDT and replace the "J" with your language letter in the class name (I used ST). I have seen many initial ports of new languages done this way and as a quick and dirty way to get started it's a pretty good way to go, especially if you borrow ideas (and code) from a well architected piece of code like JDT. Of course, the drawback to this technique is that you "bake in" the bugs you copied from the original code and you don't get the fixes as they are made in the original. You also miss new innovations as they appear in JDT and the underlying platform. Given that many of these components end up being quite similiar I feel it should be possible to create generic components for creating language IDEs, possibly starting from existing components from the existing language IDEs and generalizing them to allow re-use in other contexts. Clearly over time as you re-use components from one language in another, you will create common components as the problem accross many languages becomes better understood.
-
-So, this suggests a path forward. As IDEs for different languages are built, there will be opportunities to harvest components which will be applicable to different languages.
-
-A non-exhaustive list of tools (and problems to solve) may look something like this (I make no claims on how hard or easy the specific items are).
-
-*   **generic components for data based simple integrations (no code required)**
-    *   token based syntax colouring
-    *   non context-sensitive code assist
-    *   consoles and process control
-    *   external compiler (or other tools) error processing
-    *   declaration of artifacts for external tools
-*   **common utilities for parsers, syntax colouring, code assist**
-    *   grammar and parsing tools - generate common DOM for programming language
-    *   indexers (with persistence) for structured searching
-    *   partial/incorrect code parser support
-*   **common tools for for compiled languages**
-    *   C/C++, Fortran, COBOL, Ada ...
-    *   external tool-chain launch and processing (makefiles, compile, link)
-    *   external program (execution/debug) launch and processing
-*   **common tools for for dynamic languages**
-    *   PHP, Ruby, Smalltalk
-    *   external program (execution/debug) launch and processing
-    *   the "intermediate" language problem (script lang generates Java (or C) or ...
-    *   techniques for dealing with mixed languages in same file (HTML, PHP etc)
-    *   internal scripting execution (scriptable eclipse?)
-*   **common tools for for all languages**
-    *   integrated performance and testing tools
-
-Once we've identified these common components, the next steps would be the "IDE Wizard" tools which help you generate "your first" IDE. What I really would like to see is the Eclipse IDE equivalent of "_glasses in about an hour_" in which much of the the first implementation of an IDE is generated for you. You can then tailor the generated components for the specific needs or wholesale replace them with custom versions which provide tighter integrations. The reaction I get when talking to most people about this type of tool for creating IDEs is typically divided into two distinct groups. There's the _when can I have it?_ people and the _that's impossible!_ people. I understand the motivation of the first group, they want a simpler way to build IDEs. The latter group, is clearly thinking that we intend to auto generate JDT level functionality which is a pretty high bar or if you don't do a JDT then it won't be usefull. I don't think you're going to generate a JDT class IDE for "free" but I think you may be able to generate a usefull first cut. The tricky part is defining what "usefull" means in this context or even describing what you could expect from a generated IDE. One way, is to look at the level of functionality that an IDE has and decide what kind of functionality you could expect to find in a generated IDE.
-
-**Levels of integration in an Eclipse based IDE**
-
-There are many possible levels of integration with Eclipse. The simplest integration is to use Eclipse as your edit, compile, run (and possibly debug)system. The next level is to create a program model (parse the source code) so that you can implement language aware functionality. As the integration becomes more advanced, the opportunities become richer and features like program manipulation (refactoring, code generation, and full round trip editing for code generation systems that use programming languages as their intermediate language) become possible
-
-For simplicity, I decided to describe IDEs in terms of **levels of integration** with eclipse.
-
-*   **Editor Level Integration or Basic Integration (Level 0)**
-    *   Functionality: Text editor for source files, external compiler, compiler errors parsed into markers, launch external debugger, token based syntax coloring, text search, token based search.
-*   **Language Aware Integration - (Level 1)**
-    *   Functionality: outline view, language hierarchy/structure view, syntax based coloring, code assist, structured search (references, declarations), structured compare. Eclipse debugger support.
-*   **Advanced Language Aware Integration - (Level 2)**
-    *   Functionality: refactoring, quick fix, intentional programming (type inferencing, auto-complete of statements DOM for language and extension to these tools.
-*   **Uber-Integration - JDT class integration (Level 3,4,5)**
-    *   Functionality: all of the above and more. Full exploitation with of the platform functionality. Continued innovation in IDE technology.
-
-My position is that a IDE Wizard could create a level 0 or level 1 IDE. The key to this being a successfull strategy is the ability to selectively replace generated components. This would allow the ide implementor start with a basic IDE, and grow into full featured IDE (in the uber JDT spirit) incrementally.
\ No newline at end of file