cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: Website CMS
Date Wed, 07 Nov 2012 19:33:00 GMT
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/ :

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?


On Nov 5, 2012, at 11:44 AM, Andrus Adamchik <> wrote:
> On Nov 5, 2012, at 11:25 AM, Aristedes Maniatis <> 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
> Also we need infra help to delete CAY/, CAYDOC/, CAYDOC12/, CAYDOC20/, CAYDOC30/, CAYDV/,
CAYJPA/ CAYSITE/ folders from 
> 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

View raw message