5/7/2002
By: Eitan Suez (with input from Bob Hays)
Last revision: March 2003

What are the things driving the To-Do list right now
----------------------------------------------------
There are plenty of important tasks to work on that would greatly 
increase the adoption of ashkelon.  Simpler installation, configuration,
tools, adding features, documenting the schema, support for other databases,
integration into tools like eclipse and gforge, more metrics, realizing
the vision of ashkelon serving as a way to measure [and have insight into]
your code in various ways.

Ashkelon To-Do List
-------------------

XP
 1. Write Unit Tests for Application and begin developing using
  test-first method.

Refactoring
 1. Oracle version uses separate connect-by statements to generate
     inheritance trees.  Action: revise/refactor to use same solution
     other databases use

 2. Code that supports multiple GUIs forces data duplication.
   Refactor.  Proposed solution:  One set of JSPs generate the
   content to go on all versions of a page in XML format.
   Use separate XSLT transform to produce the different look
   and feel's.
    
 3. Modularize the build.xml file

 4. Review how application is configured and try to consolidate
    config files into a single file

 5. Review command line interface for ashkelon manager (populator) for
    possible improvements

 6. Refactor Model to use EJBs

Enhancements
 1. Build an ant task to run the ashkelon manager (populator).
 2. Support more databases (wider audience): hypersonicsql
 3. Support for multiple versions of APIs in a single repository. [hays]

Improvements
 1. Replace existing makeshift database connection pooling code with 
    a quality implementation that also handles refreshing stale connections.
    Use Jakarta's dbcp.
 2. Smarter parsing of @author tags to extract email address as a separate
     field (revise schema for author table to include email field)
 3. A GUI tool for creating api.xml files

UI
 1. Improve usability of GUI and continue refactoring JSPs
  - make ui javabeans aware.  separate accessor/mutator pairs
    as listed properties in the ui.  ones that are read-only
    should display as such (no mutator).  this would really
    clean up the method listing for classes with many methods.
    on the other hand, how does one distinguish between a class
    that coincidentally has getter/setter methods but was never
    intended to be a javabean (example: java.awt.Color)??
    maybe do this only for classes with associated beaninfo classes.

  - scrollable div's in ui should not have hard-coded height.
    is it possible with html to do something layout-manager-like?
    that is, specify that that div should take up whatever
    vertical space remains on the page?

 2. Port solution to use Struts (Under consideration)
   Current solution is MVC but author's own implementation.
 3. GUI Customization:  Make packages page configurable so it
  can list packages of relevance to a specific business 
  environment [hays]
 4. Use JSTL in JSPs
 5. A third, XUL-based GUI
 6. Make DHTML look & feel work in Safari

Performance
 1. Make caching implemntation more complete
 2. Profile application

Major
 1. GUI for Ashkelon Manager (populator)
  a. Swing
  b. Web front-end
  c. Remote proxy (like cvs pserver et al)

 2. Integration with various IDEs
  a. Eclipse [hays]
  b. NetBeans
  c. JBuilder
  d. IDEA

 3. Integration with GForge
 (Add GForge support to automatically run ashkelon against a project
   and display the documentation as a link under the documentation item) [hays]

 4. Integration with Maven.  That is, make ashkelon a maven-enabled project
   so that code can be built using maven.  Also at some point might want to
   consider writing a maven plugin to the populator (ben walding intends to work
   on an ashkelon plugin for maven)..
 
Add Value
 1. Integrate with open source measurement tools [hays]
   - jdepend
 2. Add a referenced-by and references list [hays]

XML
 1. add a third dimension (xml) to ashkelon.

   currently model can exist at runtime (org.ashkelon model objects) or in 
   database (have a database schema and code to support transfer of doc 
   info from model to db and back).

   vision:
     cvs export apiname
      exports api information as an xml document

     cvs import apiinfo.xml
      imports an entire api into the db from corresponding info save
       into apiinfo.xml (not to confuse with existing api.xml file
       which contains only info about the api entity; this new xml
       is deep and contains package and class and member info and more)

      new doclet:  ashkelon xml @api.xml
        functions similar to ashkelon add but instead of dumping
        data into db, it would dump it to a target xml file

 2. build on top of this xml infrastructure web services to allow
   the transfer of api info to a remote repository

Specific Tasks / Bugs, Small Features
- Stats page:  add class count by api in addition to class count
 by package
- API Page:  add listing of classes in a single api, flattening
  the various packages an api contains.  sort of like a 
  single package page, but for multiple packages (all
  belonging to a certain api).
- Tab selection initialization:  appears to be broken (at least
  on mozilla), fix it
- Search:  ability to restrict a search (both 'direct' and 'power')
  to a single API
- member or class listing:  modifier columns:  establish min-width in style
   to improve look


Ashkelon Completed List
-----------------------
1. Build Ant Scripts to build and deploy ashkelon on multiple platforms
2. Set up open source project at sourceforge.net so can leverage
   development & hosting tools such as mailing lists and cvs.
3. Build Mozilla-optimized set of JSPs (GUI)
4. Code repackaging away from com.u2d.dbdoc and to org.ashkelon
5. Pool Page classes
6. Postgresql support
7. Document the database structure (see doc/ERD.pdf)

Abandoned Ideas
---------------
1. Remove all references to PK's (primary keys) from URL's.  Reference 
   programming elements only by fully qualified names.
   
  reason abandoned:
   - url would get much longer
   - somewhat conflicts with multi-versioning feature (fully qualified
     name would not uniquely identify a programming element)

2. Gump Integration
  reason:  will focus on maven first.  will revisit gump later.
