public void testPutPresentKeyDifferentValue() {
    getMap().put(k0(), v0());
    getMap().put(k0(), v1());
    // verify that the bimap is changed, and that the old inverse mapping
    // from v1 -> v0 is deleted
    expectContents(mapEntry(k0(), v1()));
  }

  @MapFeature.Require(SUPPORTS_PUT)
  @CollectionSize.Require(ZERO)
  public void putDistinctKeysDistinctValues() {
    getMap().put(k0(), v0());

       the task as up-to-date, because these two files, which are based on
       the generated index.xml, are outputs, not inputs. We can be sure of
       this because they are deleted in the @BeforeEach method of the
       OsgiTest test class.

       - To enable the benefit of incremental builds, we can ask Gradle
       to ignore these two files when considering whether the classpath

 * Manages the class realms used by Maven. <strong>Warning:</strong> This is an internal utility interface that is only
 * public for technical reasons, it is not part of the public API. In particular, this interface can be changed or
 * deleted without prior notice.
 *
 */
public interface ClassRealmManager {

    /**
     * Gets the class realm hosting the Maven core.
     *
     * @return The class realm hosting the Maven core, never {@code null}.

    }

    public CurlRequest put(final String path) {
        return request(Method.PUT, path).header("Content-Type", "application/json");
    }

    public CurlRequest delete(final String path) {
        return request(Method.DELETE, path).header("Content-Type", "application/json");
    }

    public CurlRequest request(final Method method, final String path) {

      assertThat(temp.isDirectory()).isTrue();
      assertThat(temp.listFiles()).isEmpty();
      File child = new File(temp, "child");
      assertThat(child.createNewFile()).isTrue();
      assertThat(child.delete()).isTrue();

      if (!isAndroid() && !isWindows()) {
        PosixFileAttributes attributes =
            java.nio.file.Files.getFileAttributeView(temp.toPath(), PosixFileAttributeView.class)

    public static void deleteTestToken() {
        final String testToken = System.getProperty(TEST_TOKEN);
        if (testToken != null) {
            return;
        }
        given().contentType("application/json").delete(getEsUrl() + "/fess_config.access_token/_doc/" + DEFAULT_TEST_TOKEN_ID);
    }

    public static void refresh() {
        given().contentType("application/json").post(getEsUrl() + "/_refresh");
    }

            if (Files.exists(upgradedPropertiesJson)) {
                Files.copy(upgradedPropertiesJson, to.getAsFile().get().toPath(), StandardCopyOption.REPLACE_EXISTING);
            } else {
                to.getAsFile().get().delete();
            }
        } catch (IOException e) {
            throw new UncheckedIOException(e);
        }
    }

secretKey - `svcaccts[].user` - name of the parent user to assign to service account ## Uninstalling the Chart Assuming your release is named as `my-release`, delete it using the command: ```bash helm delete my-release ``` or ```bash helm uninstall my-release ``` The command removes all the Kubernetes components associated with the chart and deletes the release....

secretKey - `svcaccts[].user` - name of the parent user to assign to service account ## Uninstalling the Chart Assuming your release is named as `my-release`, delete it using the command: ```bash helm delete my-release ``` or ```bash helm uninstall my-release ``` The command removes all the Kubernetes components associated with the chart and deletes the release....

secretKey - `svcaccts[].user` - name of the parent user to assign to service account ## Uninstalling the Chart Assuming your release is named as `my-release`, delete it using the command: ```bash helm delete my-release ``` or ```bash helm uninstall my-release ``` The command removes all the Kubernetes components associated with the chart and deletes the release....