Re: Our site is too big

[Nicola Ken Barozzi]

Berin Loritsch wrote:

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.

Errr, that's exactly why I prefer documentation.
In fact, with Forrest you can put all contents in the same dir, html, xdocs, pdfs, svg, etc and have them in the output.

So it would be (almost link in Phoenix)

-- avalon
..
-- src...
--documentation
-- content
-- resources

Where content is all content and resources are images, pdfs, etc that can be referenced easily from any content subdir.

What is in "resources"?  Is that where
i18n properties and such go?

Nope.

* I like i18n/l10n properties to be incorporated into the source
  directory.  It is handy to have right there.

Yes, I agree.

Resources would keep logos, extra stuff, and basically anything that is needed but does not go in the output jar or is not tied to a java package.

* 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.

Yes, it's a good idea.

  Question is, under src/ or root directory?

Under src, because it's part of the "source"

But the problem comes with more than one programming language... should c# use this CVS module? ./lib though is not about c#m, so it seems ackward...

If we only had java I would do (as in Cocoon):

-- avalon
-- build (tmp)
-- dist (tmp)
-- legal
-- lib (though we will be downloading them, this is to override)
-- src
--framework
--container
--test
--deprecated
--documentation
-- content
-- resources
--resources
-- logos


The naming is not important, we can decide this, what I am defining is the structure now.

* 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.

Yup.

* 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.

Agreed. Instead of @since, we would then add a @till javadoc.

--
Nicola Ken Barozzi                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>