On 8/11/12 6:33am, Andrus Adamchik wrote:
Today loaded 3.1 javadocs and docbook HTML to the cms site. We have a total of 4
independent books in 3.1 (will probably refactor the whole docbook structure soon to make
them easier to manipulate). Manually copying the folders wasn't too bad. The worst part
was "git svn dcommit" after a Javadocs dump. But never the less it worked.
Notice the new docs structure. I wanted the subfolders to logically follow
dropdown menus, so instead of calling it /doc31/, I went with /doc/3_1/ :
http://cayenne.staging.apache.org/doc/3_1/index.html
Not sure how changing the path syntax helps. If you really want to do that
we'll need redirects from all the old simpler URLs to the new structure.
Remember that people will end up in doc pages from a google search and may just
change the URL to go to a different version.
I also suggest a redirect
/doc/latest/ --> /doc/3.1/
That makes it easier to refer people to the docs and for the links in mailing
list archives to remain pointing to the current docs.
Kept the older folders unchanged though. Next I will go back to docbook HTML
template work (and maybe the refactoring above).
Ari, any word on publishing our staging to the live site?
Yes, spoke to infra and created a ticket a few days ago. It is on their list.
Ari
Cheers,
Andrus
On Nov 5, 2012, at 11:44 AM, Andrus Adamchik <[email protected]> wrote:
On Nov 5, 2012, at 11:25 AM, Aristedes Maniatis <[email protected]> wrote:
1. Hosting from the ci server isn't a good idea in the long term
2. The API and docbook are pointing to trunk and this is now for 3.1
However, I don't think that the differences between trunk and 3.1 are important
yet and certainly we are a long way before we need to branch docbook.
Cool. I think we need to start publishing javadoc artifacts to Maven central
with releases (which is prolly a good idea regardless, as it would improve IDE
integration). Then Javadocs publish procedure will be like
* get cayenne-server-XX-javadoc.jar from Maven
* unpack it into site/
* commit
I may do that manually for the relevant releases.
I'm discussing some ideas with infra about how we might be publishing trunk
realtime docbook builds. As you point out, we may never need nightly javadoc
published on the website.
I'll ask infra now to put our site live, unless anyone has any final words.
Let's do it!
I've now disabled all my scripts which previously published javadocs and
confluence. I have also now disabled public read access, and committer
read-write access to the CAYSITE confluence space. It appears that the CAYDOC,
CAYDOC12, CAYDOC20, etc space are already all gone.
Also we need infra help to delete CAY/, CAYDOC/, CAYDOC12/, CAYDOC20/,
CAYDOC30/, CAYDV/, CAYJPA/ CAYSITE/ folders from https://cwiki.apache.org/
Or do they autoexport everything, regardless of the space purpose? In this case
we still need their help to delete autoexports of the previously deleted
spaces: CAYDOC/, CAYDOC12/, CAYDOC20/, CAYDOC30/ (and CAYSITE/ once we delete
that one as well).
Andrus
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
