As there are tighter limits on the first line of commit message,
the end of the line should not be marked by period.
-entences in the rest of commit message should be punctuated as usual.
+sentences in the rest of commit message should be punctuated as usual.
Some projects verify commit message formatting in automated verify-style job.
- 120 characters line length
-To automate pep8 scanning we recommend using a tox configuration as follows:
-
-tox.ini
-
-::
+To automate pep8 scanning we recommend using a ``tox.ini`` configuration file as follows::
[tox]
envlist = pep8
max-line-length = 120
Unfortunately the version of tox installed in the Jenkins build infra does not
-support the skipdist parameter which is necessary if your project does not have
-a setup.py file.
-A workaround is to create a minimal setup.py file as follows:
-
-setup.py
-
-::
+support the ``skipdist`` parameter which is necessary if your project does not have
+a ``setup.py`` file.
+A workaround is to create a minimal ``setup.py`` file as follows::
# Workaround for tox missing parameter 'skipsdist=true' which was not
# introduced until tox 1.6.0
JDK 9 is on track to making underscores forbidden in identifiers, which means
we will need to map them and it is not going to be pleasant :-(
- Each declaration needs to have either a description or a reference to a
- defintion document (like an IETF draft)
-- Use typedefs to declare concepts. An UUID is typeless, so each instance
+ definition document (like an IETF draft)
+- Use ``typedefs`` to declare concepts. An UUID is typeless, so each instance
should have its scope, so we know its applicability domain.
'type string' should only be used to things like free-form comments and
similar. Please attach a 'units' statement whenever possible.
Mandatory Fields
================
-Here is the list of mandatory fields for each jira ticket:
+Here is the list of mandatory fields for each Jira ticket:
**Project:**
Prerequisites
-------------
-The following are the prerequires for app creation:
+The following are the prerequisites for app creation:
- A development environment with the following setup and working correctly
from the shell:
:header-rows: 1
* - OpenDaylight Simultaneous Release
- - opendaylight-startup-archetype version
+ - ``opendaylight-startup-archetype`` version
* - Magnesium Development
- 1.3.0-SNAPSHOT
* - Aluminium Development
- 1.4.0-SNAPSHOT
-2. Update the properties values. Ensure that the values for the groupId and
- the artifactId are in lower case.
+2. Update the properties values. Ensure that the values for the ``groupId`` and
+ the ``artifactId`` are in lower case.
.. code:: text
Define value for property 'copyright': Copyright (c) 2021 Yoyodyne, Inc.
[INFO] Using property: copyrightYear = 2021
-3. Accept the default value of classPrefix, that is:
+3. Accept the default value of ``classPrefix``, that is:
``(${artifactId.substring(0,1).toUpperCase()}${artifactId.substring(1)})``.
- The classPrefix creates a Java Class Prefix by capitalizing the first
- character of the artifactId.
+ The ``classPrefix`` creates a Java Class Prefix by capitalizing the first
+ character of the ``artifactId``.
.. note::
- This will create a directory with the name given to artifactId in the above dialog, with
- the following contents.
+ This will create a directory with the name given to ``artifactId``
+ in the above dialog, with the following contents.
.. code:: shell
same as what was done in the previous steps.
2. View the entry point to understand the origins of the log line. The
- entry point starts in the ./impl project:
+ entry point starts in the ``./impl`` project:
.. code:: shell
}
}
-3. Return to the hello/api directory. Do the following to build the API:
+3. Return to the ``hello/api`` directory. Do the following to build the API:
.. code:: shell
Users are free to install arbitrary subset of those features,
but not every feature combination is expected to work properly.
-Some features are pro-active, which means OpenDaylight in contact with othe network elements
+Some features are pro-active, which means OpenDaylight in contact with other network elements
starts diving changes in the network even without prompting by users,
in order to satisfy initial conditions their use case expects.
Such activity from one feature may in turn affect behavior of another feature.
-In some cases, there exists features which offer diferent implementation of the same service,
+In some cases, there exists features which offer different implementation of the same service,
they may fail to initialize properly (e.g. failing to bind a port already bound by the other feature).
Integration/Test project is maintaining system tests (CSIT) jobs.
so the feature repository which defines them is not enabled by default.
The content of these features is determined by upstream OpenDaylight contributions,
-with Integration/Test providing insight on observed compatibuility relations.
+with Integration/Test providing insight on observed compatibility relations.
Integration/Distribution team is focused only on making sure the build process is reliable.
Feature repositories
~~~~~~~~~~~~~
This feature repository defines the two aggregate features.
-To enable this repository, change the featuresRepositories line of org.apache.karaf.features.cfg file,
+To enable this repository, change the ``featuresRepositories`` line of ``org.apache.karaf.features.cfg`` file,
by copy-pasting the feature-index value and editing the name.
Karaf features
Note that is the compatibility relation differs between single node an cluster deployments,
single node point of view takes precedence.
-odl-integration-all
-~~~~~~~~~~~~~~~~~~~
+``odl-integration-all``
+~~~~~~~~~~~~~~~~~~~~~~~
This feature contains the largest set of user-facing features which may affect each others operation,
but the set does not affect usability of Karaf infrastructure.
Note that port binding conflicts and "server is unhealthy" status of config subsystem
-are considered to affect usability, as is a failure of Restconf
-to respond to GET on /restconf/modules with HTTP status 200.
+are considered to affect usability, as is a failure of RESTCONF
+to respond to GET on ``/restconf/modules`` with HTTP status 200.
This feature is used in verification process for Integration/Distribution contributions.
-odl-integration-compatible-with-all
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+``odl-integration-compatible-with-all``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This feature contains the largest set of user-facing features which are not pro-active
and do not affect each others operation.
-Installing this set together with just one of odl-integration-all features should still result
+Installing this set together with just one of ``odl-integration-all`` features should still result
in fully operational installation, as one pro-active feature should not lead to any conflicts.
-This should also hold if the single added feature is outside odl-integration-all,
-if it is one of conflicting implementations (and no such implementations is in odl-integration-all).
+This should also hold if the single added feature is outside ``odl-integration-all``,
+if it is one of conflicting implementations (and no such implementations is in ``odl-integration-all``).
This feature is used in the aforementioned -all- CSIT jobs.
of at least one OpenDaylight component.
There are indirect ways to deduce such version, but the direct way is enabled
-by odl-distribution-version feature. Administrator can specify version strings,
+by ``odl-distribution-version`` feature. Administrator can specify version strings,
which would be available to users via NETCONF, or via RESTCONF
if OpenDaylight is configured to initiate NETCONF connection
to its config subsystem northbound interface.
Config subsystem can hold multiple modules, the version string should contain
version of OpenDaylight component corresponding to the module name.
As this is pure metadata with no consequence on OpenDaylight behavior,
-there is no prescribed scheme for chosing config module names.
+there is no prescribed scheme for choosing config module names.
But see the default configuration file for examples.
Java API
~~~~~~~~~~~~~
The ``odl-distribution-version`` feature is currently the only feature defined
-in feature repository of artifactId ``features-distribution``,
+in feature repository of ``artifactId`` ``features-distribution``,
which is available (transitively) in OpenDaylight Karaf distribution.
RESTCONF usage
~~~~~~~~~~~~~~
-Opendaylight config subsystem NETCONF northbound is not made available just by installing
+OpenDaylight config subsystem NETCONF northbound is not made available just by installing
``odl-distribution-version``, but most other feature installations would enable it.
RESTCONF interfaces are enabled by installing ``odl-restconf`` feature,
but that do not allow access to config subsystem by itself.
akka
analytics
BigInteger
+bgpcep
bugfixes
boolean
bytecode
Checkstyle
catalogue
+closeable
codebase
codec
codecs
JUnit
jamoluhrsen
jarfile
+judgement
Karaf
karaf
keyed
todo
tox
tsc
+typeless
uint
uncheck
unkeyed
Code Review / docs.git / commitdiff