Message-ID: <187207340.891.1427911584473.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_890_1031474510.1427911584473" ------=_Part_890_1031474510.1427911584473 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
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.=20
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.=20
To activate a profile, they can be added to
r by the
-p profile(s) command line option. The specification =
settings.xml would be:
This allows some dependencies to be OS specific, JDK specific, etc.= =20
1. Map a defined dependency to a particular implementatio= n based on profile
2. Define new dependencies based on the profile.= p>=20
Mapping would be as much work to specify and is less flexible, so the la= tter is the best choice.=20
Defining the profile of a dependency is not done in the= dependency definition itself for the following reasons:=20
Proposed solution:=20 =20
This section should be added to the POM at the top level.=20
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.=20 =20
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.=20
When switching between repositories for profiles, its possible that the = snapshot and release version information is quite different.=20
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= t profile.=20
The resulting metadata path in the local repository is:=20 =20
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.=20
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.=20
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= lass.=20
The following elements will be supported by profile specifications in va= rious locations (noted inline):=20
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.
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= arent).=20
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.=20
The requirements listed that there would need to be all of the following= :=20
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:=20
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:=20 =20
This will be made available to the POM interpolation, so could be used a= s configuration in a plugin:=20 =20
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.=20
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:=20 =20 =20
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.=20
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= de available:=20
m2 --display-profilesswitch that will show all possible p= rofiles from the pom, its parents, and transitive dependencies.