james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject Website (was RE: website broken .. Help ..)
Date Fri, 11 Jul 2003 14:32:05 GMT
> > [NOTE TO server-dev@ SUBSCRIBERS: please notice the
> > site-dev@james.apache.org address.  Messages related to site development
> > will be migrating, along with the site contents, to a new module
> > and list.]
>
> (As soon as I get back from Mallorca :-)

I'm back.
Boy was it ever Hot and Sunny :-)

Right, I'm going to make some proposals about the website stuff, anyone with
opinions pls subscribe to site-dev@ and say your stuff. I know I'm cross
posting this message, thats so that I can canvass people who aren't
subscribed there, but lets keep the discussion on site-dev please.

Ok. As I see it we want to achieve the following:

1/ that the website continues to be built from xdocs stored in cvs, and
updated to the webserver using cvs.
2/ that we can have javadocs for the current *stable* release of James on
the site not the docs for the head of cvs
2a/that we achieve 2 without messing around trying to check the correct
javadocs using cvs tags and dates and things
3/ that we can continue to build James distros with docs and without
*having* to include a snapshot of the site.
4/ that we admit the differences between product docs and website material
and provide a *simple* machanism to support and encourage the authoring of
both.

Therfore to these ends I think that we should seperate the existing xdocs
into website and product documentation, and rather than move everything en
masse into james-site move only the website docs to the site module leave
the James and Mailet docs in the server module.
We call the product docmentation The Manual, and the Project documentation
is the website.

In this fashion a build of James will build appropriate Manuals and
Javadocs. Users will have correct product documentation at their fingertips,
and won't have a lot of spurious material relating to policy and process.

If we then make it a task of release management (and make sure it is simple
to carry out) to commit the released Manual and Javadocs to site then we can
achieve all of this.

We can continue to use the refreshingly simple XSLT, which I personally
prefer to other systems only because I'm at more home with xsl, and see what
help we can get, some has been very kindly offered, for forrest-ising the
process.

If we don't automate the copying of Manual and Javadocs we will avoid people
accidentally comitting the wrong versions.

I'd like to conclude all this by re-arranging the James and Mailet
distributed documentation to include one or two cover pages which aren't
part of the manual, aren't copied to the website but do provide an
introduction to the project and links to the site and other on-line
material.

I'll accomodate this and anyones expressed opinions in a formal proposal
soon.

NB Opinions to site-dev@james.apache.org

d.






---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message