Google Git
Sign in
apache / accumulo-website / 02fbf3d0940ecf13cb652743cb60aa29e7cf32ad
commit02fbf3d0940ecf13cb652743cb60aa29e7cf32ad[log] [tgz]
authorChristopher Tubbs <ctubbsii@apache.org>Tue Sep 15 13:14:12 2020 -0400
committerChristopher Tubbs <ctubbsii@apache.org>Tue Sep 15 13:14:12 2020 -0400
treec8e94b8544da2b521dfe0ba5658b1a6f48e66265
parentf3c4bf76bbbe97225c1a14596f362dc5e6f9fbfb [diff]
Fix incorrect Apache IDs and sort people page

Fix Shana and Ed's Apache IDs, using information from
https://whimsy.apache.org/roster/committee/accumulo

Also sort both PMC/committer section and contributor section
1 file changed
tree: c8e94b8544da2b521dfe0ba5658b1a6f48e66265
  1. .github/
  2. 1.10/
  3. 1.3/
  4. 1.4/
  5. 1.5/
  6. 1.6/
  7. 1.7/
  8. 1.8/
  9. 1.9/
  10. _data/
  11. _docs-2/
  12. _includes/
  13. _layouts/
  14. _plugins/
  15. _posts/
  16. _sass/
  17. _scripts/
  18. accumulo2-maven-plugin/
  19. contributor/
  20. css/
  21. design/
  22. doap/
  23. images/
  24. js/
  25. latest/
  26. pages/
  27. papers/
  28. tour/
  29. .asf.yaml
  30. .gitignore
  31. .htaccess
  32. _config.yml
  33. CONTRIBUTING.md
  34. favicon.ico
  35. favicon.png
  36. feed.xml
  37. Gemfile
  38. Gemfile.lock
  39. index.html
  40. README.md
  41. search_data.json
README.md

Apache Accumulo Website

Apache Accumulo's website is generated from Markdown source (specifically, kramdown style) with Jekyll, using Bundler to manage its gem dependencies.

Development

Custom Liquid Tags

Jekyll uses Liquid to process files before interpreting their Markdown contents. We have extended Jekyll using its plugin mechanism to create custom Liquid tags that make it easier to link to javadocs, properties, and documents.

The source for these tags is at _plugins/links.rb.

TagDescriptionOptionsExamples
jlinkCreates Javadoc linkLink text will be class name by default. Use -f for full package + class name{% jlink -f org.apache.accumulo.core.client.Connector %} {% jlink -f org.apache.accumulo.core.client %}
jurlCreates Javadoc URLNone{% jurl org.apache.accumulo.core.client.Connector %}
plinkCreates Property linkAssumes server property by default. Use -c to link to client properties. Accepts server property prefixes (i.e table.\*){% plink -c instance.name %}
purlCreates Property URLDefault is server property. Use -c to link to client properties. Accepts server property prefixes (i.e table.\*){% purl instance.volumes %}
dlinkCreates Documentation linkNone{% dlink getting-stared/clients %}
durlCreates Documentation URLNone{% durl troubleshooting/performance %}
ghiGitHub issue linkNone{% ghi 100 %}
ghcGitHub code linkBranch defaults to gh_branch setting in _config.yml. Override using -b{% ghc server/tserver/src/main/java/org/apache/accumulo/tserver/TabletServer.java %} {% ghc -b 1.10 README.md %}
jiraJira issue linkNone{% jira ACCUMULO-1000 %}

Updating Property Documentation for Releases

Building Accumulo generates server-properties.md and client-properties.md. To regenerate these, do the following.

ACCUMULO_SITE_CLONE=<accumulo website clone location, with main branch checked out>
ACCUMULO_CLONE=<accumulo clone location>
cd "$ACCUMULO_CLONE"
mvn package -DskipTests
cp ./core/target/generated-docs/server-properties.md "$ACCUMULO_SITE_CLONE"/_docs-2/configuration
cp ./core/target/generated-docs/client-properties.md "$ACCUMULO_SITE_CLONE"/_docs-2/configuration

Local Builds for Testing

Setting up Your Jekyll/Bundler Environment

Ruby and RubyGems are required to use Jekyll and Bundler, so first make sure you have those on your machine.

If you are using an OS packaged version of Ruby, you may also need to install the ruby-dev (Ubuntu) or ruby-devel (Fedora) package as well to build any native code for gems that are installed later. Installing these will also ensure your system's RubyGems package is installed. Depending on your OS, you may also need other packages to install/build gems, such as ruby-full, make, gcc, nodejs, build-essentials, or patch.

Once Ruby, RubyGems, and any necessary native tools are installed, you are ready to install Bundler to manage the remaining RubyGem dependencies. Bundler is included in Ruby 2.6 and later as a default gem, so installing it may not be needed.

Because we use Bundler to install specific versions of gems, it is not recommended to use an OS packaged version of gems other than what comes built-in. If you are using an OS packaged version of Ruby, it is strongly recommended to avoid sudo when installing additional gems, in order to avoid conflicting with your system's package-managed installation. Instead, you can specify a GEM_HOME directory for installing gems locally in your home directory. You can do this in your $HOME/.bashrc file or other appropriate place for your environment:

# in .bashrc
export GEM_HOME=$HOME/.gem/ruby

With Ruby installed on your machine, you can install Bundler using the command below:

# not necessary in Ruby >2.6, since it is a default gem since 2.6
gem install bundler

Next, use Bundler to install Jekyll and other dependencies needed to run the website (this command assumes your current working directory is your clone of this repository with the main branch checked out, because that's where the Gemfile dependency list exists).

bundle install

Testing with the Built-in Jekyll Webserver

The command to serve the site contents using Jekyll‘s built-in webserver is as follows (this webserver may behave differently than apache.org’s servers).

bundle exec jekyll serve -w

You do NOT need to execute a bundle exec jekyll build command first, as the serve command is sufficient to both build the site and serve its contents. By default, it will also try to re-build any pages you change while running the webserver, which can be quite useful if trying to get some CSS or HTML styled “just right”.

Jekyll will print a local URL where the site can be viewed (usually, http://0.0.0.0:4000/).

Publishing

Automatic Staging

Changes pushed to our main branch will automatically trigger Jekyll to build our site from that branch and push the result to our asf-staging branch, where they will be served on our default staging site.

Publishing Staging to Production

First, add our repository as a remote in your local clone, if you haven't already done so (these commands assume the name of that remote is ‘upstream’).

Example:

git clone https://github.com/<yourusername>/accumulo-website
cd accumulo-website
git remote add upstream https://github.com/apache/accumulo-website

Next, publish the staging site to production by updating the asf-site branch to match the contents in the asf-staging branch:

# Step 0: stay in main branch; you never need to switch
git checkout main

# Step 1: update your upstream remote
git remote update upstream

# Step 2: push upstream/asf-staging to upstream/asf-site
# run next command with --dry-run first to see what it will do without making changes
git push upstream upstream/asf-staging:asf-site

A convenience script can be found that performs these steps for you, after asking which remote you want to use. It is located in the main branch at _scripts/publish.sh

Note that Step 2 should always be a fast-forward merge. That is, there should never be any reason to force-push it if everything is done correctly. If extra commits are ever added to asf-site that are not present in asf-staging, then those branches will need to be sync'd back up in order to continue avoiding force pushes.

The final site can be viewed here.