...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Table of Contents
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
- ${project.groupId} : Multi-module projects often share the same project.groupId and project.version.
${project.artifactId} :A project’s artifactId is often used as the name of a deliverable.${project.build.directory} : This represents by default the target folder${project.build.outputDirectory} : This represents by default the target/classes folder${project.build.testOutputDirectory} : This represents the default target/test-classes folder${project.build.sourceDirectory} : This represents the default src/main/java folder.${project.build.testSourceDirectory} : This represents the defaultsrc/test/javafolder.
When declaring interdependencies between two modules, groupId and version should be using properties ${project.groupId} and ${project.version}. Eg cps-rest and cps-ri are added as dependencies in cps-application.
...
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.
Eg: ${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
...
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_HOMEContains 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.
Helm charts & Environment Variable properties
CPS uses very few environment variables which are defined from the OOM charts and they are being used in Application.yml. Eg : CPS_USERNAME, CPS_PASSWORD, DB_USERNAME, DB_PASSWORD
...
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 properties to be used by the entire application should be defined as properties in cps-parent pom.xml. Eg: Version of common dependencies, image_tag etc
- 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 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.