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

  Currently, mojo configuration is done externally to the container, in the
  DefaultPluginManager in the maven-core API. In order to get from here to
  there, we need to do several things to add capability to the default
  configuration of plexus. This document will detail those changes.

Container Enhancements

* ExpressionEvaluator

            // 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");

    /**
     * This is the case where the Mojo wants to execute on every project and then do something at the end
     * with the results of each project.
     */
    @Test
    void testAggregatorMojo() throws Exception {}

    /**
     * This is the case where a Mojo needs the lifecycle run to a certain phase before it can do
     * anything useful.
     */
    @Test

          </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).

        }

        if (version == null) {
            // use the local copy, or if it doesn't exist - go to the remote repo for it
            version = artifact.getBaseVersion();
        }

        // TODO also do this logging for other metadata?
        // TODO figure out way to avoid duplicated message
        if (getLogger().isDebugEnabled()) {
            if (!version.equals(artifact.getBaseVersion())) {

if exist "%USERPROFILE%\mavenrc.cmd" call "%USERPROFILE%\mavenrc.cmd" %*
:skipRc

@setlocal

set ERROR_CODE=0

@REM ==== START VALIDATION ====
if not "%JAVA_HOME%"=="" goto javaHomeSet
for %%i in (java.exe) do set "JAVACMD=%%~$PATH:i"
goto checkJavaCmd

:javaHomeSet
set "JAVACMD=%JAVA_HOME%\bin\java.exe"

if not exist "%JAVACMD%" (

        // respectively. Using a simple replacement of these patterns will allow them
        // to specify the absolute path to these files in a customized components.xml
        // file. Ideally, we'd do full pattern-evaluation against the sysprops, but this
        // is a first step. There are several replacements below, in order to normalize
        // the path character before we operate on the string as a regex input, and

        Artifact artifact = request.getArtifact();

        //
        // If we have a system scoped artifact then we do not want any searching in local or remote repositories
        // and we want artifact resolution to only return the system scoped artifact itself.
        //