Avalon 4.0 Post Release Issues
               ------------------------------

    The purpose for this file is to document potential issues
that we need to discuss after the Avalon 4.0 Final Release,
and before any maintenance releases (i.e. 4.1, 4.0.1, etc.).
Since I don't want to clutter the mailing list and cause alarm
unnecessarily, I am placing the issues in this list.

    Please use this file to relay any issues that we need to
address after release.

Issues:
-------

* Should we require every Excalibur component to have a package.html
  file with instructions on how to use the components?  This
  should be settled on for Beta 2.

* What kind of release schedule do we want?  Should be make
  regular releases every 3 months with what we have (i.e.
  bug fixes or new features)?  Or Should we be milestone
  driven?  For Framework/Excalibur I would lean toward the
  regular release approach.

* How do components in Scratchpad be promoted to Excalibur?
  In other words, what are the exit criteria?

* Should we wait for commons to build component directory 
  or do it ourselves?

  - Excalibur is our "component directory" (BL)
  - Excalibur is our project that contains components (ie
    component repository) but we don't have a nice easily integratable
    interface lookup/discover and download components separately. (ie
    think combination of RpmFind, CPAN and tucows) (PD)

* Should we support download of resources via JNLP/CJAN/JJAN

* Should we even store the avalon generated jars (testlet/
  logkit/avalon-*/phoenix-* in CVS or should we suck them between projects
  automagically).

  - This makes it tough to focus on one project at a time. (BL)
  - If we have JNLP/CJAN/JJAN repository, that can handle this
    requirement. (BL)

* Should we have a CVS check that reformats code on insert into repository.

* Should we move to docbook DTD

  - I am +1.  The docbook documentation build process is done, and we have
    an easy migration path.  DocBook affords a better semantic view of the
    documentation plus more tools to create alternate formats. (BL)
  - +1 (PD)

* Enhance Parameters so that it can be built from writer/inputstream in such a
  way that it reads in velocity/turbine style parameters

  - Perhaps we should have a group of Parameter Builder objects so that the
    original form (XML, Configurations, Velocity paramters) can be separated
    from the actual Parameters object (SoC). (BL)
  - The velocity team moved it to commons and renamed the class  
    ExtendedProperties so we can probably use our already existing fromProperties()
    method.