avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Our site is too big
Date Sun, 29 Dec 2002 13:35:09 GMT


Berin Loritsch wrote:
> 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. 

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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Mime
View raw message