* class to begin with but rather something returned from a static factory method whose declared
   * return type is plain FilenameFilter. If we made such a change, then the annotation we choose
   * here would have no significance to end users, who would be forced to conform to the signature
   * used in FilenameFilter.)
   */
  @Override
  public boolean accept(File dir, String fileName) {
    return pattern.matcher(fileName).matches();
  }

      Object candidateKey = entry.getKey();

      /*
       * Assume that equals uses the == optimization when appropriate, and that
       * it would check hash codes as an optimization when appropriate. If we
       * did these things, it would just make things worse for the most
       * performance-conscious users.
       */
      if (key.equals(candidateKey)) {
        return entry.getValue();
      }

         * inserts checks automatically for non-private functions (which are the only kind that we
         * check).
         *
         * We *would* just check such functions redundantly, but kotlinc emits its nullness
         * annotations in the form of JetBrains annotations, which have only class retention and

    "groups" : [ {
      "testProject" : "largeJavaMultiProject",
      "comment" : "We only test the multi-project here since for the monolithic project we would have no cache hits. This would mean we actually would test incremental compilation.",
      "coverage" : {
        "per_commit" : [ "linux" ]
      }
    } ]
  }, {

         * inserts checks automatically for non-private functions (which are the only kind that we
         * check).
         *
         * We *would* just check such functions redundantly, but kotlinc emits its nullness
         * annotations in the form of JetBrains annotations, which have only class retention and

        with:
          # For discussion, see the first setup-java block.
          # The publish-snapshot workflow doesn't run tests, so we don't have to care which version Maven would select for that step.
          java-version: 25
          distribution: 'temurin'
          cache: 'maven'
          server-id: central
          server-username: CI_DEPLOY_USERNAME

pushd "${TFCI_OUTPUT_DIR}"

# Unpack the wheel to get all the file contents. The pure python wheel we built
# above is tagged with "py3-none-any". We cannot change the tags by simply
# renaming the wheels as uploading to PyPI would fail with "File already exists"
# error. In order to upload to PyPI, we unpack the wheel and change the tag
# inside a metadata file to the one we want (e.g cp38-cp38-win_amd) and then

            try (Writer writer = Files.newBufferedWriter(resumeProperties)) {
                properties.store(writer, null);
            }
        } catch (IOException e) {
            String message = "Could not create " + RESUME_PROPERTIES_FILENAME + " file.";
            throw new BuildResumptionPersistenceException(message, e);
        }
    }

ECL0105=Rethrew {0} as a runtime exception.
ECL0106=IOException occurred, because {0}
ECL0107=InvalidKeyException occurred, because {0}
ECL0108=The path is null.
ECL0109=Could not create a parent directory of {0}
ECL0110=A parent directory of {0} is not a directory.
ECL0111={0} is not a file.
ECL0112=Could not store {0}
ECL0113=NoSuchPaddingException occurred, because {0}
ECL0114=NoSuchAlgorithmException occurred, because {0}

 * This is not correct as it should do this with the built distribution instead.
 *
 * Doing it correctly would require running a Gradle build with the full
 * distribution and extracting the generated api jar from its Gradle user home,
 * slowing down building documentation.
 *
 * All this would be so much simpler if the Kotlin extensions to the Gradle API
 * were generated at build time instead.
 *