http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/59a6d65d/contributor/source.html ---------------------------------------------------------------------- diff --git a/contributor/source.html b/contributor/source.html new file mode 100644 index 0000000..79c168a --- /dev/null +++ b/contributor/source.html @@ -0,0 +1,418 @@ + + + + + + + + + + + + +Source Code and Developers Guide + + + + + + + + + + + + +
+
+
+ + +
+ + + +

Source Code

+ +

Apache Accumulo

+ +

Apache Accumulo™ source code is maintained using Git version control +(browse|checkout). It builds with Apache Maven.

+ +

Instructions for configuring git are here.

+ +

Contrib Projects

+ +

Accumulo has a number of contrib projects that maintain their own code repositories and release schedules.

+ +

Website

+ +

Accumulo’s web site is developed using Jekyll. Development is +performed by editing the contents of the gh-pages branch, either +directly by a committer, with a pull request to GitHub, or a patch +submitted to JIRA. The rendered site can be previewed locally or on +GitHub, and the rendered site (in the _site directory) will be +merged into the asf-site branch to update our official/canonical +site after being built.

+ +

To manage any Gem dependencies, it is highly recommended to use Bundler. +To start using Bundler, install it and then the dependencies for the website:

+ +
gem install bundler
+bundle install
+
+
+ +

To get help with jekyll:

+ +
jekyll help
+
+
+ +

To test the site locally (usually on http://localhost:4000):

+ +
jekyll serve --safe
+
+
+ +

To do the same with Bundler:

+ +
bundle exec jekyll serve --safe
+
+
+ +

To build for updating the asf-site branch:

+ +
jekyll build --safe
+
+
+ +

To do the same with Bundler:

+ +
bundle exec jekyll build --safe
+
+
+ +

For preview convenience and consistent builds and testing, build using a +version which looks the same locally and on GitHub.

+ +

A post-commit hook is available for you to automatically create a +commit in the asf-site branch locally each time you commit to the gh-pages +branch. You can also run this command manually:

+ +
./_devtools/git-hooks/post-commit
+
+
+ +

To automatically run this post-commit hook in your local repository, copy +the given file into your .git/hook directory:

+ +
cp ./_devtools/git-hooks/post-commit .git/hooks/
+
+
+ +

Developer’s Guide

+ +

Building

+ +

Installing Apache Thrift

+ +

If you activate the ‘thrift’ Maven profile, the build of some modules will attempt to run the Apache Thrift command line to regenerate +stubs. If you activate this profile and don’t have Apache Thrift installed and in your path, you will see a warning and +your build will fail. For Accumulo 1.5.0 and greater, install Thrift 0.9 and make sure that the ‘thrift’ command is in your path. +Watch out for THRIFT-1367; you may need to configure Thrift with –without-ruby. Most developers do not +need to install or modify the Thrift definitions as a part of developing against Apache Accumulo.

+ +

Checking out from Git

+ +

To check out the code:

+ +
git clone https://git-wip-us.apache.org/repos/asf/accumulo.git
+
+
+ +

Running a Build

+ +

Accumulo uses Apache Maven to handle source building, testing, and packaging. To build Accumulo you will need to use Maven version 3.0.5 or later.

+ +

You should familiarize yourself with the Maven Build Lifecycle, as well as the various plugins we use in our POM, in order to understand how Maven works and how to use the various build options while building Accumulo.

+ +

To build from source (for example, to deploy):

+ +
mvn package -Passemble
+
+
+ +

This will create a file accumulo-*-SNAPSHOT-dist.tar.gz in the assemble/target directory. Optionally, append -DskipTests if you want to skip the build tests.

+ +

To build your branch before submitting a pull request, you’ll probably want to run some basic “sunny-day” integration tests to ensure you haven’t made any grave errors, as well as checkstyle and findbugs:

+ +
mvn verify -Psunny
+
+
+ +

To run specific unit tests, you can run:

+ +
mvn package -Dtest=MyTest -DfailIfNoTests=false
+
+
+ +

Or to run the specific integration tests MyIT and YourIT (and skip all unit tests), you can run:

+ +
mvn verify -Dtest=NoSuchTestExists -Dit.test=MyIT,YourIT -DfailIfNoTests=false
+
+
+ +

There are plenty of other options. For example, you can skip findbugs with mvn verify -Dfindbugs.skip or checkstyle -Dcheckstyle.skip, or control the number of forks to use while executing tests, -DforkCount=4, etc. You should check with specific plugins to see which command-line options are available to control their behavior. Note that not all options will result in a stable build, and options may change over time.

+ +

If you regularly switch between major development branches, you may receive errors about improperly licensed files from the RAT plugin. This is caused by modules that exist in one branch and not the other leaving Maven build files that the RAT plugin no longer understands how to ignore.

+ +

The easiest fix is to ensure all of your current changes are stored in git and then cleaning your workspace.

+ +
$> git add path/to/file/that/has/changed
+$> git add path/to/other/file
+$> git clean -df
+
+
+ +

Note that this git clean command will delete any files unknown to git in a way that is irreversible. You should check that no important files will be included by first looking at the “untracked files” section in a git status command.

+ +
$> git status
+# On branch master
+nothing to commit (working directory clean)
+$> mvn package
+{ maven output elided }
+$> git checkout 1.6.1-SNAPSHOT
+Switched to branch '1.6.1-SNAPSHOT'
+$> git status
+# On branch 1.6.1-SNAPSHOT
+# Untracked files:
+#   (use "git add <file>..." to include in what will be committed)
+#
+# mapreduce/
+# shell/
+nothing added to commit but untracked files present (use "git add" to track)
+$> git clean -df
+Removing mapreduce/
+Removing shell/
+$> git status
+# On branch 1.6.1-SNAPSHOT
+nothing to commit (working directory clean)
+
+
+ +

Continuous Integration

+ +

Accumulo uses Jenkins for automatic builds.

+ +

Master

+ +

1.7 Branch

+ +

1.6 Branch

+ +

Issue Tracking

+ +

Accumulo tracks issues with JIRA. Every commit should reference a JIRA ticket of the form ACCUMULO-#.

+ +

Merging Practices

+ +

Changes should be merged from earlier branches of Accumulo to later branches. Ask the dev list for instructions.

+ +

Public API

+ +

Refer to the README in the release you are using to see what packages are in the public API.

+ +

Changes to non-private members of those classes are subject to additional scrutiny to minimize compatibility problems across Accumulo versions.

+ +

Coding Practices

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
License HeaderAlways add the current ASF license header as described in ASF Source Header.
Trailing WhitespacesRemove all trailing whitespaces. Eclipse users can use Source→Cleanup option to accomplish this.
IndentationUse 2 space indents and never use tabs!
Line WrappingUse 160-column line width for Java code and Javadoc.
Control Structure New LinesUse a new line with single statement if/else blocks.
Author TagsDo not use Author Tags. The code is developed and owned by the community.
+ +

Code Review

+ +

Accumulo has guidelines for using Review Board to support code reviews.

+ +

IDE Configuration Tips

+ +

Eclipse

+ +
    +
  • Download Eclipse formatting and style guides for Accumulo.
  • +
  • Import Formatter: Preferences > Java > Code Style > Formatter and import the Eclipse-Accumulo-Codestyle.xml downloaded in the previous step.
  • +
  • Import Template: Preferences > Java > Code Style > Code Templates and import the Eclipse-Accumulo-Template.xml. Make sure to check the “Automatically add comments” box. This template adds the ASF header and so on for new code.
  • +
+ +

IntelliJ

+ +
    +
  • Formatter plugin that uses eclipse code style xml.
  • +
+ +

Release Guide

+ +

Accumulo’s release guide can be found here.

+ + +
+ + + + + +
+
+
+ + http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/59a6d65d/contributor/verifying_releases.html ---------------------------------------------------------------------- diff --git a/contributor/verifying_releases.html b/contributor/verifying_releases.html new file mode 100644 index 0000000..e9d61cf --- /dev/null +++ b/contributor/verifying_releases.html @@ -0,0 +1,249 @@ + + + + + + + + + + + + +Verifying a Release + + + + + + + + + + + + +
+
+
+ + +
+ +

Verifying a Release

+ +

This is a guide for the verification of a release candidate of Apache Accumulo. These steps are meant to encapsulate +the requirements of the PMC set forth by the Foundation itself.

+ +

The information here is meant to be an application of Foundation policy. When in doubt or conflict, any Foundation-level +trumps anything written here.

+ +

Verification of a release candidate can be broken down into three categories.

+ +

Accumulo Correctness

+ +

Testing a distributed database is, arguably, the easiest of these requirements.

+ +

Accumulo contains unit and integration tests which can be automatically run via Maven. These tests can be invoked +by issues the following commands:

+ +
$ mvn verify
+
+
+ +

Additionally, Accumulo contains multiple distributed tests, most notably the RandomWalk and ContinuousIngest tests. +Information on these tests can be found in their respective directories, test/system/randomwalk and + test/system/continuous, which include instructions on how to run the tests. These tests are intended to be run +for days on end while injecting faults into the system. These are the tests that truly verify the correctness of +Accumulo on real systems.

+ +

More information on these tests, and the requirements in running them for a given release, can be found on the +governance page on releasing

+ +

Foundation Level Requirements

+ +

The ASF requires that all artifacts in a release are cryptographically signed and distributed with hashes.

+ +

OpenPGP is an asymmetric encryption scheme which lends itself well to the globally distributed nature of Apache. +Verification of a release artifact can be done using the signature and the release-maker’s public key. Hashes +can be verified using the appropriate command (e.g. sha1sum, md5sum).

+ +

An Apache release must contain a source-only artifact. This is the official release artifact. While a release of +an Apache project can contain other artifacts that do contain binary files. These non-source artifacts are for +user convenience only, but still must adhere to the same licensing rules.

+ +

PMC members should take steps to verify that the source-only artifact does not contain any binary files. There is +some leeway in this rule. For example, test-only binary artifacts (such as test files or jars) are acceptable as long +as they are only used for testing the software and not running it.

+ +

The following are the aforementioned Foundation-level documents provided for reference:

+ + + +

Apache Software License Application

+ +

Application of the Apache Software License v2 consists of the following steps on each artifact in a release. It’s +important to remember that for artifacts that contain other artifacts (e.g. a tarball that contains JAR files or +an RPM which contains JAR files), both the tarball, RPM and JAR files are subject to the following roles.

+ +

The difficulty in verifying each artifact is that, often times, each artifact requires a different LICENSE and NOTICE +file. For example, the Accumulo binary tarball must contain appropriate LICENSE and NOTICE files considering the bundled +jar files in lib/. The Accumulo source tarball would not contain these same contents in the LICENSE and NOTICE files +as it does not contain those same JARs.

+ +

LICENSE file

+ +

The LICENSE file should be present at the top-level of the artifact. This file should be explicitly named LICENSE, +however LICENSE.txt is acceptable but not preferred. This file contains the text of the Apache Software License +at the top of the file. At the bottom of the file, all other open source licenses contained in the given +artifact must be listed at the bottom of the LICENSE file. Contained components that are licensed with the ASL themselves +do not need to be included in this file. It is common to see inclusions in file such as the MIT License of 3-clause +BSD License.

+ +

NOTICE file

+ +

The NOTICE file should be present at the top-level of the artifact beside the LICENSE file. This file should be explicitly +name NOTICE, while NOTICE.txt is also acceptable but not preferred. This file contains the copyright notice for +the artifact being released. As a reminder, the copyright is held by the Apache Software Foundation, not the individual +project.

+ +

The second purpose this file serves is to distribute third-party notices from dependent software. Specifically, other code +which is licensed with the ASLv2 may also contain a NOTICE file. If such an artifact which contains a NOTICE file is +contained in artifact being verified for releases, the contents of the contained artifact’s NOTICE file should be appended +to this artifact’s NOTICE file. For example, Accumulo bundles the Apache Thrift libthrift JAR file which also have its +own NOTICE file. The contents of the Apache Thrift NOTICE file should be included within Accumulo’s NOTICE file.

+ + +
+ + + + + +
+
+
+ + http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/59a6d65d/contributor/versioning.html ---------------------------------------------------------------------- diff --git a/contributor/versioning.html b/contributor/versioning.html new file mode 100644 index 0000000..e28caba --- /dev/null +++ b/contributor/versioning.html @@ -0,0 +1,238 @@ + + + + + + + + + + + + +Versioning + + + + + + + + + + + + +
+
+
+ + +
+ +

Versioning

+ +

The Apache Accumulo PMC closed a vote on 2014/12/12 which adopted Semantic Versioning 2.0.0 as +the reference document on the meaning and requirements of the versions of Apache Accumulo. Semantic +versioning requires a definition of a public API: this definition is unchanged over previous releases and +can be found in section 9 of the README. A copy of the specification is included here, licensed under +Creative Commons - CC BY 3.0:

+ +

Specification

+ +

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” +in this document are to be interpreted as described in RFC 2119.

+ +
    +
  1. +

    Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist +strictly in documentation. However it is done, it should be precise and comprehensive.

    +
  2. +
  3. +

    A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain +leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase +numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

    +
  4. +
  5. +

    Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST +be released as a new version.

    +
  6. +
  7. +

    Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be +considered stable.

    +
  8. +
  9. +

    Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent +on this public API and how it changes.

    +
  10. +
  11. +

    Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix +is defined as an internal change that fixes incorrect behavior.

    +
  12. +
  13. +

    Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the +public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if +substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. +Patch version MUST be reset to 0 when minor version is incremented.

    +
  14. +
  15. +

    Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public +API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.

    +
  16. +
  17. +

    A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following +the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. +Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal +version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements +as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

    +
  18. +
  19. +

    Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following +the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST +NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the +build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

    +
  20. +
  21. +

    Precedence refers to how versions are compared to each other when ordered. Precedence MUST be calculated by separating +the version into major, minor, patch and pre-release identifiers in that order (Build metadata does not figure into precedence). +Precedence is determined by the first difference when comparing each of these identifiers from left to right as follows: Major, +minor, and patch versions are always compared numerically. Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. When major, minor, and patch +are equal, a pre-release version has lower precedence than a normal version. Example: 1.0.0-alpha < 1.0.0. Precedence for two +pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier +from left to right until a difference is found as follows: identifiers consisting of only digits are compared numerically and +identifiers with letters or hyphens are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence +than non-numeric identifiers. A larger set of pre-release fields has a higher precedence than a smaller set, if all of the +preceding identifiers are equal. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < +1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

    +
  22. +
+ + +
+ + + + + +
+
+
+ + http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/59a6d65d/css/accumulo.css ---------------------------------------------------------------------- diff --git a/css/accumulo.css b/css/accumulo.css index 261c55c..0958ed4 100644 --- a/css/accumulo.css +++ b/css/accumulo.css @@ -130,8 +130,8 @@ h2:hover .header-link, h3:hover .header-link, h4:hover .header-link, h5:hover .h /* insert invisible space above header elements with an id attribute, so that if they are linked to, the actual content will appear below the nav menu */ h1[id]::before, h2[id]::before, h3[id]::before, h4[id]::before, h5[id]::before, h6[id]::before { display: block; content: " "; margin-top: -80px; height: 80px; visibility: hidden; } -/* Makes navbar collapse at larger width (1185px) */ -@media (max-width: 1185px) { .navbar-header { float: none; } +/* Makes navbar collapse at larger width (1050px) */ +@media (max-width: 975px) { .navbar-header { float: none; } .navbar-toggle { display: block; } .navbar-collapse { border-top: 1px solid transparent; box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.1); } .navbar-collapse.collapse { display: none !important; } http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/59a6d65d/docs-archive/index.html ---------------------------------------------------------------------- diff --git a/docs-archive/index.html b/docs-archive/index.html new file mode 100644 index 0000000..dfdb043 --- /dev/null +++ b/docs-archive/index.html @@ -0,0 +1,193 @@ + + + + + + + + + + + + +Accumulo Documentation Archive + + + + + + + + + + + + +
+
+ +
+
+ + http://git-wip-us.apache.org/repos/asf/accumulo-website/blob/59a6d65d/downloads/index.html ---------------------------------------------------------------------- diff --git a/downloads/index.html b/downloads/index.html index 4a4b58b..6014000 100644 --- a/downloads/index.html +++ b/downloads/index.html @@ -93,13 +93,13 @@
  • Get Involved
  • Mailing Lists
  • People
  • -
  • News Archive
  • -
  • Community Projects
  • -
  • Thanks
  • +
  • Related Projects
  • +
  • Contributor Guide
  • Governance
  • - -