You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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 default src/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

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

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.



  • No labels