...

Each profile defined in an DDL document, can specify all of the elements that can be specified in the DDL model. When a profile is actiated activated all of the configuration it specifies is overlayed on top of the main DDL configuration. Values that alread already exist in the main DDL are overriden - for example if an <app> is defined in the DDL document and an <app> with the same name attibute attribute is defined in a profile, the then all of the elements and attributes in the profile are applied on top ot the <app> defined at the top level. 

Activated rrofiles profiles are applied before doing vairable variable substitution or templating. This means that any ${} variable substitution will pick up <env> elements defined in profiles. It also means that before any templates are applied template contributions for activated profiles are merged in. 

Activating DDL Profiles

By default, profiles don't augment DDL configuration, they must be activated in order to contribute to the DDL. This can be achieved either through explicit activation or via a profile's activation element. 

...

The property nv.ddl.profiles can be used to explicitly activate profiles by passing it in with the set of substituion values in the VMConfigurer. The value of nv.ddl.profiles is a comma separated string of profile names to activate. For example, one might configure a "test" profile that would set message buses to use loopback when running unittestsunit tests:

<model>

  <buses>
    <bus name="order-processing-bus" descriptor="activemq://activemq-host:61616">
      ...
    </bus>
  <buses>
 
  <profiles>
    <profile name="test">
      <env>
        <nv.discovery.descriptor>loopback://test&amp;initWaitTime=0</nv.discovery.descriptor>
      </env>
      <buses>
        <bus name="order-processing-bus" descriptor="loopback://order-processing"/>
      <buses>
    </profile>
  </profiles>
</model>

...