On 11/27/11 10:52 PM, Dave Fisher wrote:
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.
The API reference is build as part of the SDK (in the odk module). Means
a developer build of the SDK contains always the latest reference. For
every release i have update the reference document on api.openoffice.org
with the released version. No backup (online) for older versions.
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?)
sounds good, but we should definitely identify this version a developer
preview version
(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.
agree, we should have always one official version in place where i would
like to provide the search features.
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.
sounds good to me
Juergen
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
