TODO-1.0.txt

+------------- Critical For Release -------------+

o Configuration Cleanup
  
  PLAN:
  We're still debating.
  
  STATUS:
  [JVZ] I will make the changes when we agree.
  [JSS] At this point, I don't care.
  [GMJ] I do and I think we're in agreement. I will
        do the necessary support in the Velocity class
        to keep things friendly for app developers once
        Jason finished the Runtime configuration API.

o Log4j for Logging
  
  PLAN:
  Simply replace the org.apache.log package for now. Just a flat
  replacement for the features that log4j provides. The logging
  interface can come later.
  
  STATUS:
  [JVZ] I will do this if we can agree on this.
  [JSS]
        Ok, I wrote the start of a pluggable system. In other words,
        the LogManager can now be writen to Class.forName() the
        appropriate class. I took the default Avalon code and
        created an AvalonLoggingSystem. It should be possible to create
        a Log4JLoggingSystem and then have LogManager instantiate that
        instead.

        Note: We should probably make it so that this can be tied
        in with Turbine's logging system as well so that we can have a 
        centralized system as needed. In other words, instead of logging
        to a separate log file, we should be able to have Turbine init
        Velocity and then have Turbine hand it a LoggingSystem to use.
           [GMJ] I assume what you meant was that with a nice
                logging interface, Turbine can write an adapter around
                it's logging system, so that it is compatible with 
                what Velocity requires so you can just hand velocity
                a 'TurbineVelocityLogAdapter' that implements
                Velocity.LoggingSystemIfc (so to speak) :)  And instead
                of depending on Class.forName() it would be great to be 
		able to hand Vel a living instance, so the client app could
                do all the configuration it needs to, and give it to Vel
                like any other config val : setProperty( 'logger', mylogger);

        Note: Implementing Log4J might become somewhat difficult if we 
        want to support all of its features because it will add a lot
        of configuration options to the vel.props file. For instance,
        the ability to log to a console + syslog + file all at the same
        time.
           [GMJ] a solution there would be to offer a nice adapter to 
              log4j for people to use (use the one we use internally)
              so for that kind of 'advanced' use they would config log4j
              themselves, wrap in the adapter, and hand that to Vel.
              No muss, no fuss, and no endless config options.

  [GMJ] +1 on log4j - and I think a simple Interface here and now
        would go a long way. Nothing too fancy - just let people
        plug in what they want.
        - another issue is distribution - we have a nice thing now
         where the user doesn't have to go fetch anything to get vel
         going.  I assume that we will include a tested version of 
         log4j with the distro? [JSS] yes.

o Get a copy of Alexandria for Javadocs

  PLAN:
  It would be ideal to get a copy of Alexandria running on the
  apache.org box. But we can do it manually if necessary.
  
  STATUS:
  [JVZ] I have asked on the Alexandria mailing list to
  to see if someone will look into setting up Alexandria
  but I have heard anything back yet.
  [JSS] For now, lets just use DLR's scripts to generate
  the javadocs through cron.
  [GMJ]  Is this critical, or can we just push a snapshot
       to the server, or generate it there?

o UML Diagrams
  
  PLAN:
  Use a tool to reverse engineer the code in XMI so we have
  something to play with in Argo.
  
  STATUS:
  Ilkka Priha has made us a set of XMI files for Velocity,
  I will check them into CVS and we can go from there.
  [JVZ] I've place the XMI file on the apache website
  if anyone wants to take a crack at using ArgoUML.

o Specification Directory
  PLAN:
  1. Update the bnf and ast files to reflect latest Velocity code.
  2. Make sure that the questions in the questions file 
     are all answered and dealt with.

  STATUS:
  [NONE]

o Test for Texen

  PLAN:
  Just add a simple test for Texen to make sure things
  don't break when changes are made.
  
  STATUS:
  [JVZ] I will add the test for Texen.
  [GMJ] Any chance we want to push this and Anakia
        to the  new Commons project?  Good tools, good to
        be shared, and we will certainly get more
        people interested in Velocity...  

o Control Caching Resource Usage

  Change resource caching to limit cache size and expire
  least-recently-used.  This is needed to prevent Vel from
  sucking up RAM uncontrollably for content-centric or 
  other sites that may use #include() or #parse() 
  extensively.

  PLAN:
  Fix code.

  STATUS:
  [GMJ] Will start once the config stuff is set in stone.

o Method Exception Propogation

  Need to propgate errors out from methods called in user objects
  when rendering.

  STATUS :
  [GMJ]  working


+------------- Not Critical For Release -------------+

o Speed testing suite

  PLAN:
  Create a repeatable testing suite for Velocity so that it can be
  compared against other tools. In other words, other tools should also
  be plugged into this suite. We can also use this to test the relevant
  performance of changes made to Velocity.

  STATUS:
  None