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 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/java
folder.
When declaring interdependencies between two modules, groupId
and version should be
using properties ${project.groupId} and ${project.version}.
project.build* Project build related properties have a default value set and hence could be used anywhere in the pom.xml. They should not be over ridden by the application.
A complete reference for the POM structure is available at http://maven.apache.org/ref/3.0.3/maven-model/maven.html. Anything in a Maven POM can be referenced with a property.
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
These properties are set from the OOM charts and can referenced in pom.xml as 'env.<ENV_VARIABLE_NAME>'.
In CPS at present, few environment variables are used like : CPS_USERNAME, CPS_PASSWORD, DB_USERNAME, DB_PASSWORD
All these environment variables are currently being used in Application.yml.
Java System Properties
Maven exposes all properties from java.lang.System. Anything you can retrieve from System.getProperty() you can reference in 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.
Common properties to be used by the entire application should be defined as properties in cps-parent pom.xml. Eg: Version of 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.