Re: Our site is too big

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