IssueTracker

The ToT dependency was coming from compose:test-utils. Jeremy raised aosp/2254837 to pin this to a prebuilt.

Alternatively, we could have added explicit androidTestImplementation dependencies on ToT to ensure it's available during dependency resolution.

TL;DR If we express a constraint on androidx.thing:thing:$TOT_VERSION which maps to the tip-of-tree version for :thing:thing, then any occurrence of androidx.thing:thing:$VERSION where the constraint is present must also include :thing:thing somewhere in the transitive dependencies.

My understanding of this issue is:

• Project A's library code depends on prebuilt B.

• Project A's test depends on prebuilt B and also library C.

• Library C declares a constraint saying that B must be the same version as Library C.

• When resolving dependencies for Project A's tests, these tests depend on prebuilt B and library C, so library C's dependency information is also considered.

• Library C says it requires B of the same version.

• To reconcile:

  • these requirements:
    • the dependency on prebuilt B
    • the constraint for B to match the version of C
  • Gradle looks for a prebuilt of B with version matching C.

• No prebuilt of B exists with the same version matching Library C, so Gradle fails to resolve the dependency.

Is this right?

The request in b/146802533 is that libraries should publish this constraint information (rather than that Gradle should know how to automatically update prebuilt dependencies into project dependencies), so I think this issue is probably different

No prebuilt of B exists with the same version matching the prebuilt of C, so Gradle fails to resolve the dependency.

Just to make sure we're aligned, this should read "library C" rather than prebuilt? It's library C (e.g. project(C) with version $X) that expresses a constraint on prebuilt B at version $X.

Assuming we're aligned...

Yes however if library B (e.g. project("B")) exists in the set of dependencies and its version matches C, then Gradle will successfully resolve the dependency by "upgrading" prebuilt B to library B.

No prebuilt of B exists with the same version matching the prebuilt of C, so Gradle fails to resolve the dependency.

Just to make sure we're aligned, this should read "library C" rather than prebuilt? It's library C (e.g. project(C) with version $X) that expresses a constraint on prebuilt B at version $X.

Yes! Fixed, thanks

The request in b/146802533 is that libraries should publish this constraint information (rather than that Gradle should know how to automatically update prebuilt dependencies into project dependencies), so I think this issue is probably different

Slightly different. Fixing b/146802533 will necessarily involve fixing this issue, since emitting constraints into all projects will cause this issue.

Given that this was caused by tests using different dependency versions than the library's runtime dependencies, though, maybe this is broken-as-intended? The fix that Jeremy implemented was to pin the tests to the same version.

Marking as Fixed even though the general problem can still occur. Unclear that we need a systemic fix.

Hello Team,

I added the ‘activate’ command for dhttpd in the CMD line, this activates the dhttpd package before it runs. RUN is an image build step, the state of the container after a RUN command will be committed to the container image. CMD is the command the container executes by default when you launch the built image, a Dockerfile will only use the final CMD defined.

Also I changed the port to 8082 but it works in 8080 as well, you can use the one that is best for you. Please try with this Docker File:

FROM docker.io/dart

WORKDIR /flutter

ENV PATH $PATH:$HOME/.pub-cache/bin

COPY build/web ./
COPY start.sh ./
EXPOSE 8082

CMD dart pub global activate dhttpd && dart pub global run dhttpd --port=8082 --host=0.0.0.0

I confirm that your proposed changes work.

Thank you!