Currently, our uima-website project stores a copy of each release's
documentation. This can be quite large, mainly due to the Javadoc API storage
which is around 20 MB. A previous discussion pointed out that this was probably
not an issue for SVN, which was cited as being good for storing lots of small
things.
This was contrasted to an alternative, where we might use the official
distribution site to store not only our zipped/tarred up releases, but also
copies of the documentation; it was pointed out that the mirroring mechanism
was "tuned" to work with fewer numbers of large files, as opposed to lots and
lots of little ones (which is the organization of the Javadoc html site).
Because of this we were advised against putting our Javadocs, especially, on the
mirroring distribution site, in expanded form for access from our web-site.
The website for UIMA on people.apache.org is built doing an SVN update. Only
the docs/ directory is checked out.
The current situation is that we have in SVN copies of the docs (Javadocs, plus
docbook docs in html and pdf format) for all releases (of UIMA). < Well, that's
not quite accurate - some of the previous releases didn't have all the docs put
up on the web site apparently >. But we only provide links on our website to
the "current" release of the Javadocs, even though we have the older releases
available.
This seems inconsistent; we should either have pointers to all the docs for all
the releases, or, if we decide not to provide links to other than the current
release, we should not burden the website with storing the older releases (even
though the storage of these in SVN cannot be reclaimed).
If we continue to store copies of the expanded release docs as entities in our
SVN in the web-site project so we can have them available on the web site, I
would prefer that we change the website to have links to all the documentation
for all the releases that is available in SVN. These could be categorized to
reduce clutter. Other opinions?
-Marshall
- storing particular release documentation in SVN in our proj... Marshall Schor
-
