...
As previously mentioned, a profile is a subset of another POM. In modello, this can be achieved by the model and profile inheriting a common base class.
The following elements should be a part of the profile as well as the modelwill be supported by profile specifications in various locations (noted inline):
build
(pom.xml
)plugins
pluginManagement
dependencies
(pom.xml
)dependencyManagement
(pom.xml
)distributionManagement
(pom.xml
)repositories
(pom.xml
,profiles.xml
,settings.xml
)pluginRepositories
(pom.xml
,profiles.xml
,settings.xml
)modules
(pom.xml
)reports
(pom.xml
)configuration
(profiles.xml
,settings.xml
)
Note that build
is included for the benefit of the plugin definitions, and that will bring along other elements such as finalName
and outputDirectory
. These can also be beneficial. One of the unexpected behaviours may be the ability to override sourceDirectory
which will completely substitute a new tree. This is probably undesirable, and so may need to be forbidden by validation.
UPDATE NOTE: build
as specified inside of a profile is not a full implementation of the traditional build
POM element. This build
is really another class in the model - from which the POM build is derived - and only allows the plugins
and pluginManagement
subelements when defined here. This sidesteps any issues with secondary validation after the pom.xml is parsed in this case.
Inheritence and Transitivity
...