This page provides an overview of the tools Apache projects use to manage their own websites, and the tools used to manage the overall apache.org website. Everyone, even non-committers, can suggest changes to any Apache project website using these tools; committers on each project can use them to easily update their website very easily.

More notes about website generation are also found on infra-site.html.

How To Manage any Apache Project's Website¶

Every Apache project or podling has a website hosted at apache.org that is maintained by one of these tools. It is up to each project to decide the details of how their own website is maintained and what software is used - as long as it results in static files that can be served by the our public web servers (limited support for .htaccess files and CGI scripts is also available).

The basic requirements for site management are that only committers should be able to modify the site and that notifications of all site changes should be sent to the relevant project mailing lists. The Apache CMS allows non-committers to send patches via a simple web interface by "Mail Diff"ing to the project mailing list that can be easily published by a committer.

The infrastructure team currently supports two primary tools for publishing and maintaining Apache project websites:

• Apache CMS, (being deprecated; don't use for new sites) which provides a simple browser-based user interface for editing, staging and publishing site content in Markdown, HTML or any other source format for which support has been added. See the CMS reference and adoption for more details. The Apache CMS uses svnpubsub as the underlying mechanism for publishing a site.
• svnpubsub, which allows the static contents of a designated svn folder (example) to automatically published as the project web site at http://project.apache.org/. The project team can use any site build mechanism it wants as long as the above requirements are met.
• gitpubsub, which allows the static contents of a designated git repository to be served as the website for a project. git based websites are typically maintained in a asf-site branch to be published as https://project.apache.org. They can be hosted from your primary project repo. Typically these will be built as a jenkins job or a buildbot job. It is recommended that you only have a single writer to the asf-site branch to avoid potential conflicts.

Is there a default website template we can use?¶

Projects are free to choose their own styles and layout for websites.
However if you'd like a quick way to get started with an easy to use Markdown based site that many other projects started with, see the Sample Apache Project website repo, which has many useful features and instructions for using svnpubsub easily.

How do I preview my project website?¶

For svnpubsub sites, review the local files in your svn checkout before committing them. The changes will be published immediately after you commit them.

For CMS sites, just commit the changes (without "publish"-ing them) and browse to http://TLP.staging.apache.org/. (For example, the staging version of this page.) The CMS web interface includes a [Staged] link that will take you there directly.

There is no preview mode for gitpubsub. You should ideally have a way to locally build and test the website.

Can I control the configuration of my project website?¶

Yes, the central config file allows you to use .htaccess files in your website directories to control configuration. Of course, reading and parsing an .htaccess file on each request can slow down the server, so you should consider requesting an adjustment in the central config file for permanent configuration changes.

How does logging work?¶

The build output from your job is available from either buildbot or jenkins, depending on which you use.

Which tools do I have to use?¶

Projects can use one of the three options. Note that if you use CMS you are using svnpubsub under the covers.

gitpubsub is based on git repos so if you're using that for source control it may make sense to use that over a svnpubsub directory.

What revision of the site is currently being served?¶

This only applies to SVN based websites.

Look at the .revision file at the root of your site (for example, https://www.apache.org/dist/subversion/.revision or http://subversion.apache.org/.revision). That file is updated after every successful svn update. (If the update is underway or exited abnormally, .revision won't have been changed.)

How to provide public access to our project mail archive mbox files?¶

Some projects have a "mail" directory at the top of their project website. Enable this by creating a symbolic link in svnpubsub or CMS output (to /home/apmail/public-arch/$tlp.apache.org). Also see other notes.

Can my project site use its own favicon instead of just the Apache Feather?¶

Yes, just add a favicon.ico file to your site's root. The feather is only used for project sites that don't have a favicon.ico file.

How can I minimize the number of changes committed in my Maven/JavaDoc/generated site?¶

If you are using svnpubsub, the commit will perform very slowly if the number of changes is large - particularly if the number of files is large. This is often the case with JavaDoc, and to a lesser extent Maven generated sites.

You may wish to use the CMS instead of svnpubsub directly. This moves the work to the server-side, but it will still be valuable to minimize the changes committed.

These are some steps that can be taken:

• Ask infrastructure to store your generated content in the CMS repository, rather than the main ASF repository. While this won't necessarily speed up the commit, it will prevent it from impacting other users.
• When running JavaDoc, pass the -notimestamp option. This will avoid most files from being modified between runs if there haven't been code changes.
• Use a Maven skin that doesn't generate a timestamp into the output. This may require customizing the current skins.
• If you use the Maven dependencies report in the Project Info Reports plugin, use version 2.7+ of the plugin which avoids random strings being generated.
• If you maintain historical versions of documentation, always check-in to a single "trunk", then use an svn copy operation to tag or branch the content, rather than checking in a complete copy
• Minimize uses of "publish date" and "version" in templates to those that are truly necessary or helpful. Consider using a "last modified date" and version in the URL instead (unless "latest" is implied).
• Minimize Subversion keywords in the output that may change frequently without significant meaning. This includes in source code that may be rendered to JavaDoc or a Maven JXR source cross-reference).
• Avoid publishing Maven reports that change constantly to the project site. Code coverage, style reports, static analysis, etc. can be generated into a working copy on the CI server instead for easy developer viewing, and project's can consider utilizing https://analysis.apache.org/ for such reports as well.