Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id EFD85200B89 for ; Wed, 21 Sep 2016 19:02:36 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id ECDEB160AE5; Wed, 21 Sep 2016 17:02:36 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 07908160ABC for ; Wed, 21 Sep 2016 19:02:34 +0200 (CEST) Received: (qmail 84614 invoked by uid 500); 21 Sep 2016 17:02:34 -0000 Mailing-List: contact commits-help@yetus.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@yetus.apache.org Delivered-To: mailing list commits@yetus.apache.org Received: (qmail 84603 invoked by uid 99); 21 Sep 2016 17:02:34 -0000 Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Sep 2016 17:02:34 +0000 Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33) id 05A2CDFE60; Wed, 21 Sep 2016 17:02:34 +0000 (UTC) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: aw@apache.org To: commits@yetus.apache.org Date: Wed, 21 Sep 2016 17:02:34 -0000 Message-Id: X-Mailer: ASF-Git Admin Mailer Subject: [1/8] yetus git commit: git hash 1c29e36a39b21452d19a64af392d46d18ea27513 archived-at: Wed, 21 Sep 2016 17:02:37 -0000 Repository: yetus Updated Branches: refs/heads/asf-site f25b5e829 -> b2e6ae5a9 http://git-wip-us.apache.org/repos/asf/yetus/blob/b2e6ae5a/documentation/in-progress/audience-annotations-apidocs/overview-tree.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/audience-annotations-apidocs/overview-tree.html b/documentation/in-progress/audience-annotations-apidocs/overview-tree.html index e6f4185..101c378 100644 --- a/documentation/in-progress/audience-annotations-apidocs/overview-tree.html +++ b/documentation/in-progress/audience-annotations-apidocs/overview-tree.html @@ -2,16 +2,21 @@ - - -Class Hierarchy (Apache Yetus - Audience Annotations Component 0.3.0-SNAPSHOT API) - + + +Class Hierarchy (Apache Yetus - Audience Annotations Component 0.4.0-SNAPSHOT API) + + @@ -19,9 +24,11 @@
JavaScript is disabled on your browser.
-
+
- + + +
- +

Hierarchy For All Packages

-Package Hierarchies: +Package Hierarchies:
  • org.apache.yetus.audience,
  • org.apache.yetus.audience.tools
  • @@ -74,30 +81,32 @@

    Class Hierarchy

    Annotation Type Hierarchy

    -
    +
    - + + +
    - +
    http://git-wip-us.apache.org/repos/asf/yetus/blob/b2e6ae5a/documentation/in-progress/index.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/index.html b/documentation/in-progress/index.html index a79aec3..9a52d6f 100644 --- a/documentation/in-progress/index.html +++ b/documentation/in-progress/index.html @@ -157,11 +157,12 @@ Options: --skipprnorep Skip Private & Not Replaceable -

    Yetus Audience Annotations

    +

    You can mark a file to be ignored by shelldocs by adding SHELLDOC-IGNORE as a comment in its own line.

    -

    Audience Annotations allows you to use Java Annotations to denote which parts of your Java library is publicly consumable and which parts are reserved for a more restricted use. It also provides doclets and examples for generating javadocs limited by audience.

    +

    Yetus Audience Annotations

    -

    See the javadocs for details.

    +

    Audience Annotations allows you to use Java Annotations to denote which parts of your Java library is publicly consumable and which parts are reserved for a more restricted use. It also provides doclets and examples for generating javadocs limited by audience. +You can refer the user documentation here and the javadocs here.

    http://git-wip-us.apache.org/repos/asf/yetus/blob/b2e6ae5a/documentation/in-progress/interface-classification/index.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/interface-classification/index.html b/documentation/in-progress/interface-classification/index.html new file mode 100644 index 0000000..477f010 --- /dev/null +++ b/documentation/in-progress/interface-classification/index.html @@ -0,0 +1,345 @@ + + + + + + Apache Yetus + + + + + + + + + + + + + + + +
    + + +

    Apache Yetus Interface Taxonomy: Audience and Stability Classification

    + +

    Motivation

    + +

    The interface taxonomy classification provided by Apache Yetus annotations is for guidance to +developers and users of interfaces. The classification guides a developer to +declare the targeted audience or users of an interface and also its stability.

    + +
      +
    • Benefits to the user of an interface: Knows which interfaces to use or not use and their stability.

    • +
    • Benefits to the developer: to prevent accidental changes of interfaces and +hence accidental impact on users or other components or system. This is +particularly useful in large systems with many developers who may not all have +a shared state/history of the project.

    • +
    + +

    Interface Classification

    + +

    Yetus provides the following interface classification, derived from the +OpenSolaris taxonomy +and, to some extent, from taxonomy used inside Yahoo. +Interfaces have two main attributes: Audience and Stability

    + +

    Audience

    + +

    Audience denotes the potential consumers of the interface. While many interfaces +are internal/private to the implementation, others are public/external interfaces +and are meant for wider consumption by applications and/or clients. For example, +POSIX definitions in libc are external, while large parts of the kernel are internal or private interfaces. +Also, some interfaces are targeted towards other specific subsystems.

    + +

    Identifying the audience of an interface helps define the impact of breaking +it. For instance, it might be okay to break the compatibility of an interface +whose audience is a small number of specific subsystems. On the other hand, it +is probably not okay to break a protocol interfaces that millions of Internet +users depend on.

    + +

    Yetus uses the following kinds of audience in order of increasing/wider visibility:

    + +

    Private

    + +

    The interface is for internal use within a project(such as Apache Hadoop) +and should not be used by applications or by other projects. It is subject to +change at anytime without notice. Most interfaces of a project are Private (also +referred to as project-private).

    + +

    Limited-Private

    + +

    The interface is used by a specified set of projects or systems (typically +closely related projects). Other projects or systems should not use the +interface. Changes to the interface will be communicated/ negotiated with the +specified projects. For example, in the Apache Hadoop project, some interfaces are +LimitedPrivate{HDFS, MapReduce} in that they are private to the HDFS and +MapReduce subprojects.

    + +

    Public

    + +

    The interface is for general use by any application.

    + +

    Stability

    + +

    Stability denotes how stable an interface is, as in when incompatible changes to +the interface are allowed. Yetus provides the following levels of stability.

    + +

    Stable

    + +

    Can evolve while retaining compatibility for minor release boundaries; in other +words, incompatible changes to APIs marked Stable are generally only allowed +at major releases (i.e. at m.0).

    + +

    Evolving

    + +

    Evolving, but incompatible changes are allowed at minor release (i.e. m .x)

    + +

    Unstable

    + +

    Incompatible changes to Unstable APIs are allowed any time. This usually makes +sense for only private interfaces.

    + +

    However one may call this out for a supposedly public interface to highlight +that it should not be used as an interface; for public interfaces, labeling it +as Not-an-interface is probably more appropriate than Unstable.

    + +

    Examples of publicly visible interfaces that are unstable +(i.e. not-an-interface): GUI, CLIs whose output format will change

    + +

    Deprecated

    + +

    APIs that could potentially be removed in the future and should not be used.

    + +

    How are the Classifications Recorded

    + +

    How should the classification be recorded for the annotated APIs?

    + +
      +
    • Each interface or class will have the audience and stability recorded using +annotations in org.apache.yetus.classification package.

    • +
    • The javadoc generated by the maven target javadoc:javadoc lists only the public API.

    • +
    • One can derive the audience of java classes and java interfaces by the +audience of the package in which they are contained. Hence it is useful to +declare the audience of each java package as public or private (along with the +private audience variations).

    • +
    + +

    FAQ

    + +
      +
    • Why aren’t the java scopes (private, package private and public) good enough?

      + +
        +
      • Java’s scoping is not very complete. One is often forced to make a class +public in order for other internal components to use it. It does not have +friends or sub-package-private like C++.
      • +
    • +
    • But I can easily access a private implementation interface if it is Java public. +Where is the protection and control?

      + +
        +
      • The purpose of this is not providing absolute access control. Its purpose +is to communicate to users and developers. One can access private +implementation functions in libc; however if they change the internal +implementation details, your application will break and you will have +little sympathy from the folks who are supplying libc. If you use a +non-public interface you understand the risks.
      • +
    • +
    • Why bother declaring the stability of a private interface? +Aren’t private interfaces always unstable?

      + +
        +
      • Private interfaces are not always unstable. In the cases where they are +stable they capture internal properties of the system and can communicate +these properties to its internal users and to developers of the interface. + +
          +
        • e.g. In HDFS, NN-DN protocol is private but stable and can help +implement rolling upgrades. It communicates that this interface should +not be changed in incompatible ways even though it is private.
        • +
        • e.g. In HDFS, FSImage stability can help provide more flexible roll backs.
        • +
      • +
    • +
    • What is the harm in applications using a private interface that is stable? How +is it different than a public stable interface?

      + +
        +
      • While a private interface marked as stable is targeted to change only at +major releases, it may break at other times if the providers of that +interface are willing to changes the internal users of that +interface. Further, a public stable interface is less likely to break even +at major releases (even though it is allowed to break compatibility) +because the impact of the change is larger. If you use a private interface +(regardless of its stability) you run the risk of incompatibility.
      • +
    • +
    • Why bother with Limited-private? Isn’t it giving special treatment to some projects? +That is not fair.

      + +
        +
      • First, most interfaces should be public or private; actually let us state +it even stronger: make it private unless you really want to expose it to +public for general use.
      • +
      • Limited-private is for interfaces that are not intended for general +use. They are exposed to related projects that need special hooks. Such a +classification has a cost to both the supplier and consumer of the limited +interface. Both will have to work together if ever there is a need to +break the interface in the future; for example the supplier and the +consumers will have to work together to get coordinated releases of their +respective projects. This should not be taken lightly - if you can get +away with private then do so; if the interface is really for general use +for all applications then you should consider making it public. But remember +that making an interface public has huge responsibility. Sometimes +Limited-private is just right.
      • +
      • A good example of a limited-private interface is BlockLocations in the Apache +Hadoop Project, This is fairly low-level interface that they are willing to +expose to MR and perhaps HBase. They are likely to change it down the road +and at that time they will have to get a coordinated effort with the MR +team to release matching releases. While MR and HDFS are always released +in sync today, they may change down the road.
      • +
      • If you have a limited-private interface with many projects listed then you +are fooling yourself. It is practically public.
      • +
      • It might be worth declaring a special audience classification called +{YourProjectName}-Private for your closely related projects.
      • +
    • +
    • Can’t a private interface be treated as project-private also? For example what is +the harm in projects in the Apache Hadoop extended ecosystem, having access to +private classes?

      + +
        +
      • Do we want MR accessing class files that are implementation details inside +HDFS? There used to be many such layer violations in the Apache Hadoop +project that they have been cleaning up over the last few years. It is highly +undesirable for such layer violations to creep back in by no separation +between the major components like HDFS and MR.
      • +
    • +
    • Aren’t all public interfaces stable?

      + +
        +
      • One may mark a public interface as evolving in its early days. Here one is +promising to make an effort to make compatible changes but may need to +break it at minor releases.
      • +
      • One example of a public interface that is unstable is where one is +providing an implementation of a standards-body based interface that is +still under development. For example, many companies, in an attempt to be +first to market, have provided implementations of a new NFS protocol even +when the protocol was not fully completed by IETF. The implementor cannot +evolve the interface in a fashion that causes least disruption because +the stability is controlled by the standards body. Hence it is appropriate +to label the interface as unstable.
      • +
    • +
    + +
    +
    +
    + +
    + + + http://git-wip-us.apache.org/repos/asf/yetus/blob/b2e6ae5a/documentation/in-progress/precommit-advanced/index.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/precommit-advanced/index.html b/documentation/in-progress/precommit-advanced/index.html index 4262af8..9592e1f 100644 --- a/documentation/in-progress/precommit-advanced/index.html +++ b/documentation/in-progress/precommit-advanced/index.html @@ -156,7 +156,7 @@

    Plug-ins

    -

    test-patch allows one to add to its basic feature set via plug-ins. There is a directory called test-patch.d off of the directory where test-patch.sh lives. Inside this directory one may place some bash shell fragments that, if setup with proper functions, will allow for test-patch to call it as necessary. Different plug-ins have specific functions for that particular functionality. In this document, the common functions available to all/most plug-ins are covered. Test plugins are covered below. See other documentation for pertinent information for the other plug-in types.

    +

    test-patch allows one to add to its basic feature set via plug-ins. There is a directory called test-patch.d inside the directory where test-patch.sh lives. Inside this directory one may place some bash shell fragments that, if setup with proper functions, will allow for test-patch to call it as necessary. Different plug-ins have specific functions for that particular functionality. In this document, the common functions available to all/most plug-ins are covered. Test plugins are covered below. See other documentation for pertinent information for the other plug-in types.

    Common Plug-in Functions

    @@ -227,7 +227,7 @@

    Plug-ins are imported from several key directories:

      -
    • core.d is an internal-to-Yetus directory that first loads the basic Yetus library, followed by the common routines used by all of the precommit shell code. This order is dictated by prefixing the plug-in files with a number. Other files in this directory are loaded in shell collated order.

    • +
    • core.d is an internal-to-Yetus directory that first loads the basic Apache Yetus library, followed by the common routines used by all of the precommit shell code. This order is dictated by prefixing the plug-in files with a number. Other files in this directory are loaded in shell collated order.

    • personality contains bundled personalities for various projects. These will be imported individually based upon either a project name or if specifically identified with the --personality flag.

    • test-patch.d contains all of the optional, bundled plug-ins. These are imported last and in shell collated order.

    @@ -244,7 +244,7 @@
  • pluginname_filefilter

      -
    • executed while determine which files trigger which tests. This function should use add_test pluginname to add the plug-in to the test list.
    • +
    • executed while determining which files trigger which tests. This function should use add_test pluginname to add the plug-in to the test list.
  • pluginname_compile

    @@ -288,7 +288,7 @@

    Global Definitions

    Globals for personalities should be defined in the personality_globals function. This function is called after the other plug-ins have been imported. This allows one to configure any settings for plug-ins that have been imported safely:

    -
    funciton personality_globals
    +
    function personality_globals
     {
       PATCH_BRANCH_DEFAULT=master
       GITHUB_REPO="apache/yetus"
    
    http://git-wip-us.apache.org/repos/asf/yetus/blob/b2e6ae5a/documentation/in-progress/precommit-apidocs/core/index.html
    ----------------------------------------------------------------------
    diff --git a/documentation/in-progress/precommit-apidocs/core/index.html b/documentation/in-progress/precommit-apidocs/core/index.html
    index ab53dfc..0a85007 100644
    --- a/documentation/in-progress/precommit-apidocs/core/index.html
    +++ b/documentation/in-progress/precommit-apidocs/core/index.html
    @@ -165,8 +165,6 @@
     
     
@@ -1230,78 +1228,6 @@ No -

personality_file_tests

- -
    -
  • Synopsis
  • -
-
personality_file_tests
-
- -
    -
  • Description
  • -
- -

None

- -
    -
  • Returns
  • -
- -

Nothing

- - - - - - - - - - - - - - - - -
ClassificationLevel
AudienceNone
StabilityNone
ReplaceableNo
-

personality_modules

- -
    -
  • Synopsis
  • -
-
personality_modules
-
- -
    -
  • Description
  • -
- -

None

- -
    -
  • Returns
  • -
- -

Nothing

- - - - - - - - - - - - - - - - -
ClassificationLevel
AudienceNone
StabilityNone
ReplaceableNo

http://git-wip-us.apache.org/repos/asf/yetus/blob/b2e6ae5a/documentation/in-progress/precommit-apidocs/plugins/index.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/precommit-apidocs/plugins/index.html b/documentation/in-progress/precommit-apidocs/plugins/index.html index a4be12f..a81dd57 100644 --- a/documentation/in-progress/precommit-apidocs/plugins/index.html +++ b/documentation/in-progress/precommit-apidocs/plugins/index.html @@ -130,10 +130,10 @@
  • Public/Stable/Not Replaceable
  • None/None/Not Replaceable @@ -352,25 +352,25 @@

    Public/Stable/Not Replaceable

    -

    jira_write_comment

    +

    bugzilla_write_comment

    • Synopsis
    -
    jira_write_comment filename
    +
    bugzilla_write_comment filename
     
    • Description
    -

    Write the contents of a file to JIRA

    +

    Write the contents of a file to Bugzilla

    • Returns
    -

    exit code from posting to jira

    +

    Nothing

    @@ -388,27 +388,25 @@
    Classification LevelNo
    -

    javac_precheck

    +

    github_write_comment

    • Synopsis
    -
    javac_precheck
    +
    github_write_comment filename
     
    • Description
    -

    Verify that ${JAVA_HOME} is defined

    +

    Write the contents of a file to github

    • Returns
    -

    1 - no JAVA_HOME

    - -

    0 - JAVA_HOME defined

    +

    Nothing

    @@ -426,25 +424,27 @@
    Classification LevelNo
    -

    bugzilla_write_comment

    +

    javac_precheck

    • Synopsis
    -
    bugzilla_write_comment filename
    +
    javac_precheck
     
    • Description
    -

    Write the contents of a file to Bugzilla

    +

    Verify that ${JAVA_HOME} is defined

    • Returns
    -

    Nothing

    +

    1 - no JAVA_HOME

    + +

    0 - JAVA_HOME defined

    @@ -462,25 +462,25 @@
    Classification LevelNo
    -

    github_write_comment

    +

    jira_write_comment

    • Synopsis
    -
    github_write_comment filename
    +
    jira_write_comment filename
     
    • Description
    -

    Write the contents of a file to github

    +

    Write the contents of a file to JIRA

    • Returns
    -

    Nothing

    +

    exit code from posting to jira

    http://git-wip-us.apache.org/repos/asf/yetus/blob/b2e6ae5a/documentation/in-progress/precommit-basic/index.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/precommit-basic/index.html b/documentation/in-progress/precommit-basic/index.html index 736f6a7..8740555 100644 --- a/documentation/in-progress/precommit-basic/index.html +++ b/documentation/in-progress/precommit-basic/index.html @@ -304,6 +304,9 @@ have a location to look at the output artifacts:

    It is a fairly common practice within the Apache community to use Apache’s JIRA instance to store potential patches. As a result, test-patch supports providing just a JIRA issue number. test-patch will find the last attachment, download it, then process it.

    +

    NOTE: test-patch expects the patch files to follow a particular naming convention. For complete details + on the naming convention please refer to patch-naming-conventions

    +

    For example:

    $ test-patch.sh (other options) HADOOP-9905
     
    @@ -334,7 +337,7 @@ have a location to look at the output artifacts:

    Generic URLs

    -

    Luckily, test-patch supports provide ways to provide unified diffs via URLs.

    +

    Luckily, test-patch supports ways to provide unified diffs via URLs.

    For example:

    $ test-patch.sh (other options) https://example.com/webserver/file.patch
    
    http://git-wip-us.apache.org/repos/asf/yetus/blob/b2e6ae5a/documentation/in-progress/precommit-buildtools/index.html
    ----------------------------------------------------------------------
    diff --git a/documentation/in-progress/precommit-buildtools/index.html b/documentation/in-progress/precommit-buildtools/index.html
    index 534f384..a83d6ed 100644
    --- a/documentation/in-progress/precommit-buildtools/index.html
    +++ b/documentation/in-progress/precommit-buildtools/index.html
    @@ -182,12 +182,12 @@
     
  • pluginname_builtin_personality_modules

      -
    • Default method to determine how to enqueue modules for processing. Note that personalities may override this function.
    • +
    • Default method to determine how to enqueue modules for processing. Note that personalities may override this function. Requires two arguments: repo status and test desired. For example, in a maven build, values may be 'branch’ and 'mvninstall’.
  • pluginname_builtin_personality_file_tests

      -
    • Default method to determine which tests to trigger. Note that personalities may override this function.
    • +
    • Default method to determine which tests to trigger. Note that personalities may override this function. Requires a single argument: the file in which the tests exist.
  • @@ -288,7 +288,7 @@

    Maven will test eclipse and site if maven is being used as the build tool and appropriate files trigger them.

    -

    Maven will trigger add a maven install test when the maven_add_install function has been used and the related tests are requierd. Plug-ins that need to run maven before MUST call it as part of their respective initialize functions, otherwise maven may fail unexpectedly. All Yetus provided plug-ins that require maven will trigger the maven install functionality.

    +

    Maven will trigger add a maven install test when the maven_add_install function has been used and the related tests are requierd. Plug-ins that need to run maven before MUST call it as part of their respective initialize functions, otherwise maven may fail unexpectedly. All Apache Yetus provided plug-ins that require maven will trigger the maven install functionality.

    http://git-wip-us.apache.org/repos/asf/yetus/blob/b2e6ae5a/documentation/in-progress/precommit-smart-apply-patch/index.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/precommit-smart-apply-patch/index.html b/documentation/in-progress/precommit-smart-apply-patch/index.html index bf76f8b..205575e 100644 --- a/documentation/in-progress/precommit-smart-apply-patch/index.html +++ b/documentation/in-progress/precommit-smart-apply-patch/index.html @@ -127,7 +127,7 @@

    Usage

    -

    Its simpliest form is used when a patch is stored in a local file:

    +

    Its simplest form is used when a patch is stored in a local file:

    $ smart-apply-patch patch
     
    http://git-wip-us.apache.org/repos/asf/yetus/blob/b2e6ae5a/documentation/in-progress/precommit-testformats/index.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/precommit-testformats/index.html b/documentation/in-progress/precommit-testformats/index.html index 5c7ac5e..25e5e81 100644 --- a/documentation/in-progress/precommit-testformats/index.html +++ b/documentation/in-progress/precommit-testformats/index.html @@ -127,6 +127,8 @@
    add_test_format <pluginname>
     
    +

    Test format plugins can provide following two methods, which will be called by test-patch if defined.

    +
    • pluginname_process_tests

      @@ -140,6 +142,8 @@
    +

    For an example of how to write a test-format plugin, you can look at junit plugin bundled in Apache Yetus.

    +

    http://git-wip-us.apache.org/repos/asf/yetus/blob/b2e6ae5a/documentation/in-progress/releasedocmaker/index.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/releasedocmaker/index.html b/documentation/in-progress/releasedocmaker/index.html index 3bbb8a9..c7a4a2d 100644 --- a/documentation/in-progress/releasedocmaker/index.html +++ b/documentation/in-progress/releasedocmaker/index.html @@ -276,7 +276,8 @@ default value for this label by using –incompatiblelabel option e.g.

    Index Mode

    -

    There is basic support for an autoindexer. It will create two files that contain links to all directories that have a major.minor.micro-style version numbering system, where all fields are numeric.

    +

    There is basic support for an autoindexer. It will create two files that contain links to all directories that have a major.minor*-style version numbering system. +For example directories with names like 0.6, 1.2.2, 1.2alpha etc. will all be linked.

    • index.md: a file suitable for conversion to HTML via mvn site
    Classification Level