final String message = MessageFormatter.format(
                            "The requested profiles {} could not be activated or deactivated because they do not"
                                    + " exist.",
                            notFoundRequiredProfiles)
                    .getMessage();

        this.defaultLifeCycles = requireNonNull(defaultLifeCycles);
    }

    // These methods deal with construction intact Plugin object that look like they come from a standard
    // <plugin/> block in a Maven POM. We have to do some wiggling to pull the sources of information
    // together and this really shows the problem of constructing a sensible default configuration but
    // it's all encapsulated here so it appears normalized to the POM builder.

                } else {
                    /*
                     * NOTE: Other configurators like the map-oriented one don't call into the listener, so do it the
                     * hard way.
                     */
                    validateParameters(mojoDescriptor, configuration, expressionEvaluator);
                }
            }

                        new ArtifactResolutionException("Resolution interrupted", rootArtifact, e));
            }
        }

        // We want to send the root artifact back in the result but we need to do this after the other dependencies
        // have been resolved.
        if (request.isResolveRoot()) {
            // Add the root artifact (as the first artifact to retain logical order of class path!)

 implement it and then I disappeared for 8 months so it never came to pass.

 So I guess it's important to figure out what people are using properties
 files for and see if we can't incorporate it all into the POM. Or if we do
 have properties file (something I would like to avoid) say they don't
 contribute in any meaningful way to information in the POM. For example a
 properties file could be used the specify $ so it can be interpolated in

            // which may cause some re-entrance in the build() method and can
            // actually cause deadlocks.  In order to workaround the problem,
            // we do a first pass by reading all rawModels in order.
            List<ProjectBuildingResult> results = new ArrayList<>();
            boolean failure = false;
            for (InterimResult r : interimResults) {

    // to validate the properties. We also need a way to navigate from the Tex specification documents to
    // the test in question and vice versa. A little Eclipse plugin would do the trick.
    public void testThatExecutionsWithoutIdsAreMergedAndTheChildWins() throws Exception {
        PomTestWrapper tester = buildPom("micromailer");

          </description>
          <type>String</type>
        </field>
        <field>
          <name>checksumPolicy</name>
          <version>4.0.0+</version>
          <description>
            What to do when verification of an artifact checksum fails. Valid values are
            {@code ignore},
            {@code fail} (default for Maven 4 and above) or
            {@code warn} (default for Maven 2 and 3).

/**
 * Interface representing a Maven project which can be created using the
 * {@link org.apache.maven.api.services.ProjectBuilder} service.
 * Such objects are immutable and plugin that wish to modify such objects
 * need to do so using the {@link org.apache.maven.api.services.ProjectManager}
 * service.
 * <p>
 * Projects are created using the {@code ProjectBuilder} from a POM file
 * (usually named {@code pom.xml}) on the file system.

 without limitation  the rights to  use, copy, modify,  merge, publish,
 distribute,  sublicense, and/or sell  copies of  the Software,  and to
 permit persons to whom the Software  is furnished to do so, subject to
 the following conditions:

 The  above  copyright  notice  and  this permission  notice  shall  be
 included in all copies or substantial portions of the Software.