Subject: Exported From Confluence
Content-Type: text/html; charset=UTF-8
Build profiles are an important concept for unifying configurati=
on differences between different environments. They also should capture inf=
ormation across all aspects of the POM.
- All profile information should be kept together to create a single v=
iew of it, rather than dispersing it throughout the POM
- Based on the design decisions below, the profile is a subset of a PO=
M that is applied onto the current POM as a form of inheritence.
- Each profile has a globally unique identifier.
Multiple profiles can be active simultaneously. Each profile selected is=
cumulative. This allows each profile to do specific things, and various co=
mbinations do not need to be created. There is no need for duplication or s=
pecial inheritence of profiles.
To activate a profile, they can be added to
r by the
-p profile(s) command line option. The specification =
settings.xml would be:
Profiles for Dependencies<=
This allows some dependencies to be OS specific, JDK specific, etc.
1. Map a defined dependency to a particular implementation based on profile=
2. Define new dependencies based on the profile.
Mapping would be as much work to specify and is less flexible, so the la=
tter is the best choice.
Defining the profile of a dependency is not done in the=
dependency definition itself for the following reasons:
- previous goal to keep all profile information together
- same reason as for elimination of dependency properties - hard to ma=
nage over transitive dependencies, and awkward to specify more than one wit=
hout making specification of just 1 verbose.
<id>jdk-1.4</id> <!-- Use the id of "default" if it i=
s the profile to use when none is given -->
<version>1.1.6-jdk14</version> <!-- The JDK portion =
may be part of the classifier instead (see other doc)
This section should be added to the POM at the top level.
Profiles for Plugin=
Plugin configuration and management can also be specified in the profile=
. Definitions here will add to the existing lists and merge as appropriate.=
For consistency - it behaves identically to inheritence, however regardles=
s of the <inherit> and @inheritByDefault flag, the plugins from the c=
urrent pom are always inherited into the profile as conceptually for the us=
er, it is just overlayed, not inherited.
This will always bind the plugin with this version. If a version is spec=
ified in both the main plugins section and one or more profiles, the versio=
ns must match or an error occurs.
Profiles for Repositories<=
When switching between repositories for profiles, its possible that the =
snapshot and release version information is quite different.
Rather than having to maintain multiple local repositories for the segme=
nts where an alternate repository is used, just the snapshot metadata needs=
to be in a different location when looking to a repository from a differen=
The resulting metadata path in the local repository is:
Another option is to write the information into one snapshot file, but t=
hat makes it different to the remote version which is undesirable and would=
affect timestamped checks.
The above information could possibly be duplicated in the remote reposit=
ory to allow different profiles to operate on the same repository. At this =
point, this is not being implemented.
All elements allowed =
in a profile
As previously mentioned, a profile is a subset of another POM. In modell=
o, this can be achieved by the model and profile inheriting a common base c=
The following elements will be supported by profile specifications in va=
rious locations (noted inline):
build is included for the benefit of the plugin d=
efinitions, and that will bring along other elements such as
outputDirectory. These can also be beneficial. On=
e of the unexpected behaviours may be the ability to override
irectory which will completely substitute a new tree. This is probab=
ly undesirable, and so may need to be forbidden by validation.
build as specified inside of a profile is not a full implem=
entation of the traditional
build POM element. This
d is really another class in the model - from which the POM build is=
derived - and only allows the
ent subelements when defined here. This sidesteps any issues with se=
condary validation after the pom.xml is parsed in this case.
Inheritence and Transit=
Note that the profiles are inherited, but only in such a way as they are=
applied to a parent POM before the inheritence of the parent and child is =
performed, so the settings required are already present. This ensures the p=
roper precedence occurs (child and its profiles win over the profile of a p=
For this reason it is unimportant if the IDs of profiles match or not, u=
nless they are to be specified on the command line.
Location of Profiles
The requirements listed that there would need to be all of the following=
- per user
- per project
Project based settings that apply to all users can be stored in
m.xml as previously shown.
For user specific settings that apply to a particular project, they shou=
ld use a
user-* profile ID. These can go into the POM (and be =
stored in SCM), or be in
profiles.xml in the same directory (w=
hich may not be stored in the SCM).
profiles.xml are transient profiles that are for per-user c=
ustomisations to an individual project. They are generally not stored in SC=
M, and are never deployed. Before of this, they are not inherited, except w=
hen a USD or reactor build is present that will locate them and match them =
to the parent POM.
For any settings that span multiple projects, the profiles need to be st=
settings.xml instead of
These should take on a similar format, however is restricted to:
- repositories (which are added to the list in the POM)
- plugin repositories (As above)
- general configuration properties
General configuration properties are used instead of allowing plugin con=
figuration to be given. This avoids a settings file circumventing a POM. Fo=
r example, the following general configuration may be given:
This will be made available to the POM interpolation, so could be used a=
s configuration in a plugin:
The main drawback to this is that it requires some consistency of proper=
ty naming - however this outways the problems of directly injecting plugin =
configuration from settings.
It should be possible to preset the activation of some profiles. Eg, JDK=
, OS, host and user profiles could all be made active based on the settings=
of the machine running the build. However, should any profiles be made act=
settings.xml, this will override all of the existing o=
nes, rather than add to them.
Likewise, specifying profiles on the command line will override all of t=
settings.xml as well as any predefined ones.
This will be done by some special activation tags (the format of which i=
s yet to be completely decided), for example:
Under the above design, filtering can simply be a configuration element =
on the resources plugin (as per Kenney's patch, already available). The pro=
files will allow the introduction of different filter sets.
The plexus use case requires that a different goal be bound to the lifec=
ycle. However, this does not entail any changes to the lifecycle design wit=
h the above solution. Instead, the goals would simply be added to the
<plugins> section as needed in each profile.
These are some thoughts on additional features that may or may not be ma=
m2 --display-profiles switch that will show all possibl=
e profiles from the pom, its parents, and transitive dependencies.
- features to disable transient profiles in a deployment/release scena=
rio to ensure the build is pure.