Maven Properties 

Any application can use Maven properties in a pom.xml file or in any resource that is being processed by the Maven Resource plugin’s filtering features.

The following sections provide some detail on the various properties available in a Maven project and how they should be defined/used in CPS

Maven Project Properties

When a Maven Project Property is referenced,  you are referencing a property of the org.apache.maven.model.Model class which is being exposed as the implicit variable project.

Eg: The following list shows some common property references from the Maven project used in CPS

...

Maven Settings Properties

These are the  properties in the Maven Local Settings file which is usually stored in ~/.m2/settings.xml. This file contains user-specific configuration such as the location of the local repository and any servers, profiles, and mirrors configured by a specific user. These properties should not be redefined in CPS, unless we need to override the values. Like:

• ${onap.nexus.dockerregistry.release} : The default onap docker registry for releasing artifacts
• ${docker.pull.registry} : The default docker pull registry 
• ${docker.push.registry} : The default docker push registry
• ${onap.nexus.url} : The default onap nexus url

A full reference for the ONAP Settings file and corresponding properties is available here. https://github.com/onap/oparent/blob/master/settings.xml

If CPS needs to reconfigure any of these properties, they should be added to parent pom.xml.

In case different users wish to use different docker-registry or nexus url, these properties could be overridden in the CI-CD jobs.

Note: CPS has redefined these properties with almost the same values.

Environment Variable Properties

Environment variables can be referenced in the pom.xml with the env.* prefix. Some interesting environment variables are listed in the following list:

• env.PATH: Contains the current PATH in which Maven is running. The PATH contains a list of directories used to locate executable scripts and programs.
• env.HOME: (On *nix systems) this variable points to a user’s home directory. Instead of referencing this, you should use the ${user.home}env.
• JAVA_HOME: Contains the Java installation directory. This can point to either a Java Development Kit (JDK) installation or a Java Runtime Environment (JRE). Instead of using this, you should consider referencing the ${java.home} property.env.
• M2_HOME: Contains the Maven 2 installation directory.

While they are available, you should always use the Java System properties wherever available. This would help in creating a more portable build adhering to the Write-Once-Run-Anywhere (WORA) promise of the Java platform.

CPS uses very few environment variables which are defined from the OOM(Helm) charts and they are being used in Application.yml. Eg :

...

Maven exposes all properties from java.lang.System. Anything you can retrieve from System.getProperty() can be referenced as a Maven property and could be used anywhere in the pom.xml. Since these properties would be mostly related to the entire application, it is suggested to define them in parent pom.xml.

Eg : java.version is used in CPS.

User-defined Properties

In addition to the implicit properties provided by the POM, Maven Settings, environment variables, and the Java System properties, you have the ability to define your own arbitrary properties. Properties can be defined in a POM or in a Profile. Period character should be used as a separator in property names. 

• Common dependencies to be used by the entire application should be defined as properties in cps-dependencies pom.xml
  • Eg: groovy.version, spock-spring.version
• Other common properties to be used by the entire application should be defined as properties in cps-parent pom.xml.
  • Eg: spring-boot-maven-plugin.version, java.version, minimum-coverage, base.image
• Each module can specify the properties which is exclusively used by the module. In case a module needs to override a property defined in the cps-parent pom.xml, that could also be done in the properties section. 
• In case a property is only used in a particular profile, then it is advised to define the property inside the profile. In case a profile needs to override a property defined in the pom, that could also be done in the profile's properties section. CPS has different profiles defined namely cps-docker, ncmp-docker and cps-ncmp-docker for building different docker images. Each profile could define their own image.name property to be used for deriving their own docker image name.
  • Eg : image.name is set to cps-service in cps-docker profile
  • image.name is set to cps-and-ncmp in cps-ncmp-docker profile