Location: http://www.eclipse.org/dltk/dltk-plan-1_0.xml
Meta-data Tag: projectplanurl
Raw:

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