| <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> |
| <?xml-stylesheet type="text/xsl" href="http://www.eclipse.org/projects/project-plan.xsl"?> |
| <p:plan plan-format="1.0" xmlns:p="http://www.eclipse.org/project/plan" xmlns="http://www.w3.org/1999/xhtml" name="Dynamic Languages Toolkit"> |
| <p:release projectid="technology.dltk" version="1.0" /> |
| <p:introduction> |
| <div>Some xhtml content here. Make sure to use the prefix |
| before the elements</div> |
| </p:introduction> |
| <p:release_deliverables> |
| <div> |
| <ul> |
| <li> |
| <b>DLTK source code release</b> |
| , available as versions tagged "R1_0" in the project's |
| <ul> |
| <li> |
| <a href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.dltk/?cvsroot=Technology_Project">DLTK CVS Repository</a> |
| , |
| </li> |
| </ul> |
| </li> |
| <li> |
| <b>DLTK Core Frameworks:</b> |
| <ul> |
| <li>DLTK Core (runtime and SDK) (downloadable).</li> |
| </ul> |
| </li> |
| <li> |
| <b>Stand-alone components:</b> |
| <ul> |
| <li>Ruby IDE (runtime and SDK) (downloadable).</li> |
| <li>TCL IDE (runtime and SDK) (downloadable).</li> |
| </ul> |
| </li> |
| <li> |
| <b>DLTK extensions:</b> |
| <ul> |
| <li>Incr TCL (runtime and SDK) (downloadable).</li> |
| <li>XOTcl (runtime and SDK) (downloadable).</li> |
| </ul> |
| </li> |
| <li> |
| <b>Integration Components:</b> |
| <ul> |
| <li>DLTK Remote Projects via DSDP TM (runtime and SDK) (downloadable).</li> |
| <li>DLTK Mylyn Integration (runtime and SDK) (downloadable).</li> |
| </ul> |
| </li> |
| <li> |
| <b>Incubating components:</b> |
| <ul> |
| <li>Python IDE (runtime and SDK) (downloadable).</li> |
| <li>Javascript IDE (runtime and SDK) (downloadable).</li> |
| </ul> |
| </li> |
| </ul> |
| </div> |
| </p:release_deliverables> |
| <p:release_milestones> |
| <p:preamble> |
| <p> |
| Release milestones will be occurring at roughly 6 week intervals, and will be aligned with the |
| <a href="http://wiki.eclipse.org/Galileo_Simultaneous_Release">Galileo Simultaneous Release</a> |
| train. Milestone names start with M2 in order to clarify this relationship. |
| </p> |
| </p:preamble> |
| <p:milestone date="01-Oct-2008" milestone="M2"> |
| <div>1.0M2</div> |
| </p:milestone> |
| <p:milestone date="12-Nov-2008" milestone="M3"> |
| <div>1.0M3</div> |
| </p:milestone> |
| <p:milestone date="29-Dec-2008" milestone="M4"> |
| <div>1.0M4</div> |
| </p:milestone> |
| <p:milestone date="06-Feb-2009" milestone="M5"> |
| <div>1.0M5</div> |
| </p:milestone> |
| <p:milestone date="18-Mar-2009" milestone="M6"> |
| <div>1.0M6</div> |
| </p:milestone> |
| <p:milestone date="06-May-2009" milestone="M7"> |
| <div>1.0M7 (API/Feature Freeze)</div> |
| </p:milestone> |
| <p:milestone date="19-May-2009" milestone="RC1"> |
| <div>1.0RC1</div> |
| </p:milestone> |
| <p:milestone date="26-May-2009" milestone="RC2"> |
| <div>1.0RC2</div> |
| </p:milestone> |
| <p:milestone date="02-Jun-2009" milestone="RC3"> |
| <div>1.0RC3</div> |
| </p:milestone> |
| <p:milestone date="09-Jun-2009" milestone="RC4"> |
| <div>1.0RC4</div> |
| </p:milestone> |
| <p:milestone date="16-Jun-2009" milestone="RC5"> |
| <div>1.0RC5</div> |
| </p:milestone> |
| <p:postamble> |
| <div> |
| <p>The target date for availability of Dynamic Languages Toolkit 1.0 is:</p> |
| <ul> |
| <li>Wednesday June 26, 2009 - DLTK 1.0 Release date (with Galileo)</li> |
| </ul> |
| </div> |
| </p:postamble> |
| </p:release_milestones> |
| <p:target_environments> |
| <div> |
| <p>In order to remain current, each Eclipse release is designed to run on |
| reasonably current versions of the underlying |
| operating environments.</p> |
| <p>The DLTK 1.0 depends upon on the Eclipse Platform 3.4. |
| Various sub components also depend on other Eclipse Projects, |
| namely the the Eclipse Modeling Framework (EMF) 2.3 or later and DSDP TM. |
| For this release, the core sources will be |
| written and compiled against version 5.0 of the Java Platform APIs and |
| designed to run on |
| version 5.0 of the Java Runtime |
| Environment, Standard Edition. |
| </p> |
| </div> |
| </p:target_environments> |
| <p:compatibility_with_previous_releases> |
| <div> |
| <p> |
| <strong>Source/binary Compatibility:</strong> |
| Due to active refactoring/optimization/improvement of the core DLTK frameworks |
| DLTK 1.0 will not be source/binary |
| compatible with DLTK 0.95. |
| </p> |
| <p> |
| <strong>Workspace Compatibility:</strong> |
| We intend to keep DLTK 1.0 |
| upwards workspace-compatible with DLTK 0.95 unless noted. |
| This means that workspaces and |
| projects created with DLTK 0.95 can be successfully |
| opened by DLTK 1.0 and upgraded to a 1.0 workspace. |
| A workspace |
| created (or opened) by a product based on DLTK 1.0 will be unusable |
| with a product based on DLTK 0.95. |
| </p> |
| <p> |
| <b>API Contract</b> |
| APIs published for the DLTK 1.0 release will be carefully |
| reviewed prior to release, making use of "internal" packages |
| for |
| unsupported and variable implementation classes. Client plug-ins that |
| directly depend on anything other than what is |
| specified in the |
| published API are inherently unsupportable and receive no guarantees |
| about future compatibility. |
| </p> |
| </div> |
| </p:compatibility_with_previous_releases> |
| <p:themes_and_priorities> |
| <!-- |
| p:preamble> <div>Some xhtml content here. Make sure to use the prefix before the elements</div> </p:preamble |
| --> |
| <p:theme name="Project Building and Indexing"> |
| <p:committed> |
| <ul> |
| <li>Mixin indexing should be performed independently from the builder</li> |
| <li>Move error reporting from the editor to the ProjectBuilder.</li> |
| <li>Unsaved changes in the editor should not be reported as markers in the Problems view.</li> |
| <li>Project isolation for the the Selection, Completion, Type Inference, etc engines.</li> |
| <li>Introduce API to easily implement additional semantic checks</li> |
| </ul> |
| </p:committed> |
| <p:proposed> |
| <ul> |
| <li>Indexing and search should be moved from the core to separate plugins.</li> |
| <li>Indexing should be configurable for each language separately, and only if required.</li> |
| <li>Support of multi-pass indexing and resource dependencies.</li> |
| <li>API to implement pluggable indexers</li> |
| </ul> |
| </p:proposed> |
| </p:theme> |
| <p:theme name="Core Frameworks improvements"> |
| <p:committed> |
| <ul> |
| <li>Fix Type Hierarchy bugs</li> |
| </ul> |
| </p:committed> |
| <p:proposed> |
| <ul> |
| <li> |
| <b>Review public API</b> |
| Internal packages should be rarely used. |
| </li> |
| <li> |
| Project/buildpath management |
| <ul> |
| <li>Switch to EMF</li> |
| <li>Improve extensibility</li> |
| <li>API simplifications</li> |
| </ul> |
| </li> |
| <li> |
| <b>External application management</b> |
| Implement EMF based application management: |
| <ul> |
| <li>Interpreters</li> |
| <li>Debuggers</li> |
| <li>External checker tools</li> |
| </ul> |
| </li> |
| <li>Type inferencing engine improvements</li> |
| <li> |
| <b>Remove AST from core</b> |
| and allow each language to use it is own AST classes |
| </li> |
| <li>Implement persistent AST caching to speed up all operations</li> |
| <li> |
| <b>Debugger improvements</b> |
| <ul> |
| <li>Support of different kind of expressions</li> |
| <li>Support of different kind of breakpoints</li> |
| <li>Support of async dbgp.</li> |
| <li>Support of consoles over debug protocol.</li> |
| <li>Improve DBGP implementation quality and reliability</li> |
| </ul> |
| </li> |
| <li> |
| <b>Code assistance</b> |
| APIs needs improvements. Context information (AKA argument hinting) calls should be |
| fairly separated from code |
| completion calls. API should allow the addition of language specific features. |
| </li> |
| <li>Implement proper Runtime Model based on the current mixin model</li> |
| <li> |
| <b>Documentation view</b> |
| improvements: |
| <ul> |
| <li>Hyperlink navigation</li> |
| <li>Display documentation form multiple sources and ability to switch from one source to another</li> |
| <li>Ability to display documentation for multi-word commands (e.g. "package require ...." in TCL)</li> |
| </ul> |
| </li> |
| <li>User-defined templates for the new script files</li> |
| </ul> |
| </p:proposed> |
| </p:theme> |
| <p:theme name="Ruby IDE improvements"> |
| <!-- p:description> |
| ...(optional) html... |
| </p:description--> |
| <p:committed> |
| <ul> |
| <li>Ruby source code formatter</li> |
| <li>Testing frameworks support (Test::Unit, Shoulda, RSpec)</li> |
| </ul> |
| </p:committed> |
| <p:proposed> |
| <ul> |
| <li> |
| Rubygems suppport |
| <ul> |
| <li>package management (list, install, etc.)</li> |
| <li>ability to add installed gems to the project buildpath</li> |
| </ul> |
| </li> |
| <li>Implement own parser based on XRuby with automatic error recovery, correct positions for all elements, |
| etc. Implement 2 modes of parser operations: FAST for building internal models and error reporting and EXTENDED with |
| detailed information of every source token for use in editor and formatter</li> |
| <li>Cache parsed ASTs for all modules to optimize performance of the search/content assist |
| operations</li> |
| <li> |
| <b>Syntax highlighting improvements</b> |
| fix some cases with incorrect syntax highlighting. Deep use of semantic highlighting to correctly highlight all the |
| sources. |
| </li> |
| <li>Rake runnner</li> |
| <li>Checks for the common code errors (need to clarify what could be checked)</li> |
| <li>Regular Expression Tester</li> |
| <li>Spell Checking Support</li> |
| <li>Mark Occurrences</li> |
| <li>Refactoring support</li> |
| </ul> |
| </p:proposed> |
| </p:theme> |
| <p:theme name="New TCL parser"> |
| <p:description> |
| <p> |
| TCL everything-is-a-string concept is cool but it makes difficult any tooling support (particulary ones dealing with |
| code analysis). TCL code is also string so to parse TCL source properly any tool must know parameter types at least to |
| follow execution flow in the source. Consider TCL statement |
| <code>if a b c</code> |
| Tool must know that for the case above b and c strings are source code which may be executed and shall be handled |
| appropriately by the tool. Real life is much complex and written above is true only if c string is not equal to else |
| value... This rules (proc metadata) can not be derived (inferred) from program source, and the only way is to supply |
| this rules externally. |
| Current parser has hard-coded metadata for widely used control-flow TCL procs, such as if, |
| switch, while, etc. This allow DLTK to |
| walk through large part of user program, but this is not enough to cover user |
| programs well. |
| </p> |
| </p:description> |
| <p:committed> |
| <ul> |
| <li>Standard library metadata</li> |
| <li>Initial implementation of TCL parser based on provided metadata</li> |
| <li>Initial bundle of TCL сode checks (procedure redefinition, unreachable code, wrong arguments, etc)</li> |
| </ul> |
| </p:committed> |
| <p:proposed> |
| <ul> |
| <li>Build metadata for user-defined commands</li> |
| <li>Infer argument types for metadata of the user-defined commands</li> |
| <li>ITCL support by the new parser and metadata</li> |
| <li>XOTCL support by the new parser and metadata</li> |
| <li>Update model element parser to use new parser</li> |
| <li>Update indexing to use new parser</li> |
| <li>Update search to use new parser</li> |
| <li>Update CompletionEngine to use new parser</li> |
| <li>Update SelectionEngine to use new parser</li> |
| <li>Update semantic highlighting to use new parser</li> |
| <li>Advanced TCL checks (undefined variable, unused command or variable, more detailed reporting of the |
| mismatched command arguments, etc)</li> |
| </ul> |
| </p:proposed> |
| </p:theme> |
| <p:theme name="TCL ActiveState tools support"> |
| <p:proposed> |
| <ul> |
| <li>tclchecker: quickfix support, pretty message formatting, incremental project checks, support new |
| options</li> |
| <li>debugger: hotswap, watchpoints, configuration function instrumentation, enhance debugging of threads or |
| spawned processes</li> |
| <li> |
| <a href="http://docs.activestate.com/tdk/4.1/#tpm_summary">Teapot</a> |
| package management support |
| </li> |
| <li>Better license management to avoid potential licensing issues with ActiveState</li> |
| </ul> |
| </p:proposed> |
| </p:theme> |
| <p:theme name="Powerful Script Console"> |
| <p:description> |
| <p> |
| As a Java oriented IDE (initially) Eclipse lack of powerful Console support. But developers using interpreted |
| languages |
| like TCL expect good interactive (console, shell) support from tooling. Current Eclipse Console is a simple |
| stream-based |
| output to the the window, with some coloring and pattern matching features, which is not enough for good |
| interactive |
| console. |
| </p> |
| </p:description> |
| <p:proposed> |
| <ul> |
| <li>Syntax highlighting</li> |
| <li>Code assist</li> |
| <li>API Documentation</li> |
| <li>Show variable values on hover</li> |
| <li>Proper OS streams handling</li> |
| <li>Available for local and remote processes</li> |
| </ul> |
| </p:proposed> |
| </p:theme> |
| <p:theme name="TCL IDE improvements"> |
| <p:proposed> |
| <ul> |
| <li>TCL source code indenter (formatter)</li> |
| <li> |
| Man-pages and documentation should be tied to the code |
| <ul> |
| <li>At the moment tcl documentation is configured globally instead the user should be able to specify different |
| documentation for each interpreter/library</li> |
| </ul> |
| </li> |
| </ul> |
| </p:proposed> |
| </p:theme> |
| </p:themes_and_priorities> |
| </p:plan> |
