> 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. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
