*/
    ModelBuildingRequest setSystemProperties(Properties systemProperties);

    /**
     * Gets the user properties to use for interpolation and profile activation. The user properties have been
     * configured directly by the user on his discretion, e.g. via the {@code -Dkey=value} parameter on the command
     * line.
     *
     * @return The user properties, never {@code null}.
     */

    public String getExecutionRootDirectory() {
        return request.getBaseDirectory();
    }

    /**
     * @see MavenExecutionRequest#getTopDirectory()
     * @since 4.0.0
     */
    public Path getTopDirectory() {
        return request.getTopDirectory();
    }

    /**
     * @see MavenExecutionRequest#getRootDirectory()
     * @since 4.0.0
     */
    public Path getRootDirectory() {

     */
    @Nonnull
    Collection<Profile> getProfiles();

    /**
     * List of profile ids that have been explicitly activated by the user.
     */
    @Nonnull
    List<String> getActiveProfileIds();

    /**
     * List of profile ids that have been explicitly deactivated by the user.
     */
    @Nonnull
    List<String> getInactiveProfileIds();

    /**

    protected String component() {
        return "deployer";
    }

    @Test
    void testArtifactInstallation() throws Exception {
        sessionScope.enter();
        try {
            sessionScope.seed(MavenSession.class, mock(MavenSession.class));

            String artifactBasedir = new File(getBasedir(), "src/test/resources/artifact-install").getAbsolutePath();

    validations:
      required: true

  - type: markdown
    attributes:
      value: >
        Did you *actually* encounter the need for this enhancement in a real-world scenario, or does
        it just seem like a sensible behavior for the feature to have?


        Before we make significant changes to existing features in Guava, we really want to be sure

     */
    Map<String, String> getSystemProperties();

    /**
     * Gets the user properties to use for interpolation and profile activation. The user properties have been
     * configured directly by the user on his discretion, e.g. via the {@code -Dkey=value} parameter on the command
     * line.
     *
     * @return The user properties, never {@code null}.
     */

You can change/extend these stubs, and tests should not be breaking too much, since most tests
assert using expected values from the stubs. Normally, when you try to use data from the stubs that
have not been properly populated, you'll get a nullpointer in your test and you then have to
identify which stub creates that specific piece of data.

The most important stubs are:
LifecycleExecutionPlanCalculatorStub

// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU Affero General Public License for more details.
//
// You should have received a copy of the GNU Affero General Public License
// along with this program.  If not, see <http://www.gnu.org/licenses/>.

package sql

import (
	"errors"
	"fmt"
	"strings"

  }

  interface HashFn {
    byte[] hash(byte[] input, int seed);
  }

  static void verifyHashFunction(HashFn hashFunction, int hashbits, int expected) {
    int hashBytes = hashbits / 8;

    byte[] key = new byte[256];
    byte[] hashes = new byte[hashBytes * 256];

    // Hash keys of the form {}, {0}, {0,1}, {0,1,2}... up to N=255,using 256-N as the seed
    for (int i = 0; i < 256; i++) {
      key[i] = (byte) i;

  SampleElements<E> samples();

  /**
   * Creates a new container containing the given elements. TODO: would be nice to figure out how to
   * use E... or E[] as a parameter type, but this doesn't seem to work because Java creates an
   * array of the erased type.
   */
  T create(Object... elements);

  /**
   * Helper method to create an array of the appropriate type used by this generator. The returned