handler -->> client: HTTP error response
        dep -->> dep: Raise other exception
    end
    dep ->> operation: Run dependency, e.g. DB session
    opt raise
        operation -->> dep: Raise HTTPException
        dep -->> handler: Auto forward exception
        handler -->> client: HTTP error response
        operation -->> dep: Raise other exception
        dep -->> handler: Auto forward exception
    end

              <!-- Fix OutOfMemoryError under Travis. -->
              <extraJvmArgs>-Xms3500m -Xmx3500m -Xss1024k</extraJvmArgs>
              <sourceLevel>1.8</sourceLevel>
              <!-- Keep these timeouts very large because, if we hit the timeout, the tests silently pass :( -->
              <testTimeOut>86400 <!-- seconds --></testTimeOut>
              <testMethodTimeout>1440 <!-- minutes --></testMethodTimeout>

      this.bounds = ImmutableList.copyOf(bounds);
    }

    @Keep
    public Type[] getBounds() {
      return toArray(bounds);
    }

    @Keep
    public D getGenericDeclaration() {
      return genericDeclaration;
    }

    @Keep
    public String getName() {
      return name;
    }

    @Keep
    public String getTypeName() {
      return name;
    }

      this.bounds = ImmutableList.copyOf(bounds);
    }

    @Keep
    public Type[] getBounds() {
      return toArray(bounds);
    }

    @Keep
    public D getGenericDeclaration() {
      return genericDeclaration;
    }

    @Keep
    public String getName() {
      return name;
    }

    @Keep
    public String getTypeName() {
      return name;
    }

fun promotionBuildParameters(
    dependencyBuildId: RelativeId,
    extraParameters: String,
    gitUserName: String,
    gitUserEmail: String,
): String =
    listOf(
        "-PcommitId=%dep.$dependencyBuildId.build.vcs.number%",
        extraParameters,
        "\"-PgitUserName=$gitUserName\"",
        "\"-PgitUserEmail=$gitUserEmail\"",
        PLUGINS_PORTAL_URL_OVERRIDE,

	// is too large we are basically just thrashing the CPU D-cache.
	// So if the result length is larger than an empirically-found
	// limit (8KB), we stop growing the source string once the limit
	// is reached and keep reusing the same source string - that
	// should therefore be always resident in the L1 cache - until we
	// have completed the construction of the result.
	// This yields significant speedups (up to +100%) in cases where