ONAP POLICY

All major releases are tagged in gerrit and the artifacts are stored with the release information on onap.nexus. So we can access all old versions of the artifact. If and when a upgrade requires certain steps to be followed they are being added to the release documents as needed

Jira is used to track issues. https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA

Vulnerabilities can be reported using the link https://wiki.onap.org/pages/viewpage.action?pageId=6591711 Currently we dont have any vulnerabilities reported, but the wiki page explains on how to report a vulnerability and how to report anonymously if you do not want the credit for it.

Vulnerabilities handling is documented in https://wiki.onap.org/pages/viewpage.action?pageId=6591711

Coding style is defined in https://wiki.onap.org/display/DW/Java+code+style https://google.github.io/styleguide/jsguide.html

Policy Framework project utilizes the ONAP checkstyle using the Maven maven-checkstyle-plugin.

Policy is written primarily in Java and JavaScript, neither of which creates native binary applications.

The application does not create native binaries.

Maven ensure submodules are built in the proper order. There are no bi-directional cross-dependencies between submodules.

All releases are tagged in gerrit(git), and the builds are controlled using jenkins. By providing the git tag information the same image can be build over and over again with same bit-for-bit result.

All packages are delivered either as an jar artifact or a docker image. In case of maven artifacts, they can be removed using the pom file. In case of docker container. We can delete the container we dont want. Also control the orchestration in Kubernetes if you want to exclude certain docker images.

The compiled docker images and jar files can be installed/used as the user sees fit. Both run on JVM or docker. So there is no reason to select locations etc.

All the components require only java and maven to begin with for a developer to quickly install and test it. Even for deployment using OOM and the right amount of resources, we can deploy the full Policy/ONAP suite in less than a day. The steps are documented in https://docs.onap.org/projects/onap-oom/en/latest/oom_quickstart_guide.html

External dependencies are controlled using the pom file, which can be found in the root folder for the projects. We store most of our common dependencies in our policy/parent project's pom.xml: https://gerrit.onap.org/r/gitweb?p=policy/parent.git;a=blob;f=pom.xml;hb=refs/heads/master

NexusIQ sonar scan is run on all the projects on a weekly basis

External components are maintained through Maven. The user can get a list of all included components using the maven dependency tree and can update or reuse as they see fit

We avoid depending on deprecated/obsolete functions. Sonar scans, which are run daily, identify the use of deprecated functions.

Automatic test suites are run every time before merging the code. The code check in cannot pass with out jenkins posting a +1 on the review.

We require JUnit tests to be added to support bug fixes if they are not present.

We use sonar to measure the overall code/branch coverage. policy/common 84.0% policy/models 99.3% policy/api 83.9% policy/pap 94.0% policy/apex-pdp 79.7% policy/drools-pdp 80.3% policy/xacml-pdp 90.4% policy/drools-applications 93.4% policy/distribution 78.1%

Contributing guide lines for development is recorded in https://wiki.onap.org/display/DW/Development+Procedures+and+Policies

This is documented on our wiki: Code Coverage and Static Code Analysis

Build systems run the compile with test flag enabled by default. So any failure in test cases will fail the ci and the merge request.

in case of exception or any other issue during login for the REST APIs, the request is denied.