avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@citi-us.com>
Subject RE: Our site is too big
Date Fri, 27 Dec 2002 13:27:02 GMT
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Berin Loritsch wrote:
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > 
> > 
> > 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
* 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.

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message