RE: Our site is too big

> From: Nicola Ken Barozzi [mailto:[email protected]]
> 
> Berin Loritsch wrote:
> > From: Nicola Ken Barozzi [mailto:[email protected]]
> > 
> > 
> > If we decide to set up an avalon CVS module and put all content in 
> > there, I can start the restructuring, and we can work 
> > together to put it 
> > in better shape.
> > 
> > 
> > If you want to propose, then +1 from me--although we need 
> to determine
> > what is the long-term structure of the CVS archive going to 
> look like?
> > We should pick a scalable strategy.  
> 
> Initial take:
> 
> -- avalon
>    -- legal
>    -- lib
>    -- src--java
>          --test
>          --deprecated
>          --documentation
>          --resources
> 
> This is as clean IMHO as it can be with one codebase.


I would change "documentation" to xdocs.  It's clearer about
what goes in there.  What is in "resources"?  Is that where
i18n properties and such go?

* I like i18n/l10n properties to be incorporated into the source
  directory.  It is handy to have right there.
* I like to have a different directory for client code (AKA
  the A5 equiv. of Framework) separate from the container
  code.  I think they should have a separate directory.
  Question is, under src/ or root directory?
* I like the deprecated directory.  It forces us to write our
  code so that we *don't* need it, but will support it if we
  must.
* I would like to make the addendum that upon a release, we
  mark all deprecated code with both a replacement, and the
  date we expect to remove the code.  That way our users are
  adequately warned, and we have a reminder of what cruft is
  safe to remove.