</plugin>
    </plugins>
    <resources>
      <resource>
        <directory>src</directory>
      </resource>
      <!-- src-super is copied to guava-gwt-sources (so that we can strip its @Nullable annotations), so we don't need to list it here. We may want to arrange something similar for test-super someday. -->
      <!-- TODO(cpovirk): Why do we have separate src and src-super directories, anyway? -->
      <resource>

concurrency:
  # On master/release, we don't want any jobs cancelled so the sha is used to name the group
  group: ${{ (github.ref == 'refs/heads/master' || github.ref == 'refs/heads/release' ) && format('contributor-pr-base-{0}', github.sha) || format('contributor-pr-{0}', github.ref) }}
  cancel-in-progress: false

env:
  # Set the DEVELOCITY_ACCESS_KEY so that a Build Scan is generated

        uses: actions/setup-java@dded0888837ed1f317902acf8a20df0ad188d165 # v5.0.0
        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: 24
          distribution: 'temurin'
          server-id: sonatype-nexus-snapshots
          server-username: CI_DEPLOY_USERNAME

          operations-per-run: 50
          ascending: true
          exempt-all-milestones: true

          # ISSUES (deactivated) ----------------------------------------------
          # This workflow should touch no issues, so times are set to -1
          # (see actions/stale documentation for the behavior)
          days-before-issue-stale: -1
          stale-issue-label: stale
          stale-issue-message: >

      We could probably have resumed it after https://github.com/google/guava/pull/6664.
      But it's always weird that published poms reference test-only libraries at all, so I'm not in any rush to do so.
      -->
    </dependencies>
  </dependencyManagement>
  <profiles>
    <profile>
      <id>sonatype-oss-release</id>
      <build>
        <plugins>
          <plugin>

      We could probably have resumed it after https://github.com/google/guava/pull/6664.
      But it's always weird that published poms reference test-only libraries at all, so I'm not in any rush to do so.
      -->
    </dependencies>
  </dependencyManagement>
  <profiles>
    <profile>
      <id>sonatype-oss-release</id>
      <build>
        <plugins>
          <plugin>

         *
         * 2a. If the resolved types are identical to the original types, then we can return the
         * original, identical JDK TypeVariable. By doing so, we sidestep the problem entirely.
         *
         * 2b. If the resolved types are different from the original types, things are trickier. The

   * AnnotatedElement}, which {@code TypeVariable} began to extend only in Java 8. Those methods
   * refer only to types present under Android, so we could implement them in {@code
   * TypeVariableImpl} today. (We could probably then make {@code TypeVariableImpl} implement {@code
   * AnnotatedElement} so that we get partial compile-time checking.)
   *
   * <p>This workaround should be removed at a distant future time when <a

         *
         * 2a. If the resolved types are identical to the original types, then we can return the
         * original, identical JDK TypeVariable. By doing so, we sidestep the problem entirely.
         *
         * 2b. If the resolved types are different from the original types, things are trickier. The

   * AnnotatedElement}, which {@code TypeVariable} began to extend only in Java 8. Those methods
   * refer only to types present under Android, so we could implement them in {@code
   * TypeVariableImpl} today. (We could probably then make {@code TypeVariableImpl} implement {@code
   * AnnotatedElement} so that we get partial compile-time checking.)
   *
   * <p>This workaround should be removed at a distant future time when <a