On Nov 25, 2011, at 2:30 AM, Jürgen Schmidt wrote: > On 11/24/11 6:12 PM, Kay Schenk wrote: >> 2011/11/24 Jürgen Schmidt<[email protected]> >> >>> On 11/23/11 5:55 PM, Kay Schenk wrote: >>> >>>> +1...all good, and something we had discussed early on. >>>> >>>> However, as I work on porting legacy info over, I am wondering what to do >>>> about the more "developer" centered areas of the site: api, sc, sw, >>>> framework, external (? -- I need to look at this one), tools,porting, and >>>> many others that are not really "user centered". I will load these into >>>> the >>>> ooo-site tree, but at some point, someone on the "developer" side should >>>> really cull this out and move them to the "developer" side so we don't >>>> continually deal with these areas on the "user portal". >>>> >>> >>> i also have thought about the api page and i would like to support it in >>> the future as well. Because it provides some useful stuff for macro, >>> extension developers. But maybe in a simplified and reduced form. >>> >>> things i would i would like to keep >>> >>> - API reference >>> - C++/Java UNO Runtime reference >>> - search features into the different reference documentation as well as >>> the Developer's Guide >>> - links to the SDK >>> - link to the API wiki pages >>> >>> Most of the content will i move into the wiki as soon as possible. >>> >>> I would really like to work with you or somebody else who knows the Apache >>> framework better then i to rework the API page. >>> It would be really helpful if we can find an easy way to update the >>> generated reference docu without checking in thousands of files. >>> >> >> Jurgen-- >> >> Everything form the old "api" site is available via -- >> >> https://svn.apache.org/repos/asf/incubator/ooo/ooo-site/trunk/content/api/ >> >> just plain ole html...I don't think you should have any problems > > ok thanks. One concern i had in the past and will have it now is that the > generated reference docu have to be checked in. I would prefer a place where > i simply could secure copy the generated files. But important for the near > future is of course that we have everything in place, have it under our > control and can work on future improvements.
I agree and I would like to discuss the api generation process now so that we can get it right. I've always expected this to be special. Please describe how the API reference documents come out the process. If it can easily be part of the Ubuntu buildbot that is being worked on then I propose the following: (1) The buildbot is enhanced to always update the podling site with the bleeding edge of the api documentation. The Apache CMS also uses buildbot and this should not be hard to automate at all. It could be at i.a.o/openofficeorg/api/ and updated daily. (Andrew and Gavin am I correct?) (2) The pages at www.openoffice.org/api/* are always the api from the latest release - currently 3.3.0, but perhaps TOOo 3.3.1 followed by AOO copied from podling at release. This starts with what Kay has imported. This allows users to have the API for the release and the project developers to always see a current build which any committer can fix and any contributor can submit a patch. Having two sites works to our advantage. In the Apache POI project's mailing lists we often have to explain that the API documents at poi.apache.org are from the current trunk and that those for a release are part of the release package. We won't have the problem. Our general rule should be that openoffice.org is for the current (and legacy) releases and the podling site is the dynamic place that shows our activity. > > Will come back to this later. Now is good! Regards, Dave > > Juergen > >> >> >>> extensions.openoffice.org points today already in the wiki and i would >>> like to redirect this page today to the api side. And in the future we can >>> hopefully reactivate this page for an extension repository. >>> >>> And hopefully templates.openoffice.org for templates ;-) >>> >>> Juergen >>> >>> >>> >>>
