Re: Our site is too big

[Nicola Ken Barozzi]

Berin Loritsch wrote:

From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]

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.


That makes more sense then.

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

We have a couple choices.  We could do:

/src/cs
/lib/cs

or we can do what Axis does:

avalon-java/.....
avalon-csharp/....
avalon-c++/....

I'm mildly in favor of this second solution, like

avalon/.....
avalon-csharp/....
avalon-c++/....

Avalon is written in Java, and the others are just ports.

Why?

If ever we get a c++ version, we would have problems.
Plus all the documentation, sources libs, build process would be different.

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

Can't we have *all* resources under documentation/resources?

If they are about documentation, yes.
I don't see the need ATM for ./src/resources yet really, we can decide later if we see the need.

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

Is that standard JavaDoc, or would we have to alter the JavaDoc
renderer?

1.4 javadoc can be supplied with new tags to use IIRC.
Anyway, we would use xdoclet or similar to get a list of these in a tidy manner.

--
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]>