[gortazar]

parte_4/tema_4.2/aplicacion-java-enunciado was the last place in the repository still asking for Java 17, after #3 moved every pom and the CI workflow to 25. The container built fine, which is why nothing caught it: it just handed you a JDK that cannot compile the project it was made for.

The tag

The image family here was already the current one, so this is only the tag:

- "image": "mcr.microsoft.com/devcontainers/java:0-17"
+ "image": "mcr.microsoft.com/devcontainers/java:3-25-bookworm"

Same as the sibling in ejemplo-1. There is no 0-25 to move to — that series stops at 17, checked against the MCR tag list.

Two option values were strings where the feature wants booleans

-     "installMaven": "true",
-     "installGradle": "false"
+     "installMaven": true,
+     "mavenVersion": "latest"

installGradle was the riskier of the two. The feature definition declares it as a boolean with a default of false, and a non-empty string is the kind of value that reads as true depending on who parses it — so asking for no Gradle in quotes is a worse way of saying nothing at all. Dropping it says the same thing and cannot be misread.

installMaven stays, and it is not decoration: the project has no mvnw and no .mvn directory, so without Maven in the container there is no way to build it.

What the sibling had and this one does not

Worth saying explicitly, since it is what I went looking for: this file has no top-level settings or extensions keys, and no java.home pointing at /docker-java-home. Those were ejemplo-1's problems, not this one's. Nothing to fix there.

These are the only two devcontainers in the repository, and both are now on the same image and the same feature configuration.

Verification

The container was not opened, and nothing in CI builds a devcontainer, so the matrix on this PR says nothing about this change — it only confirms the 86 Maven projects are unaffected. What was checked statically:

• 3-25-bookworm exists in the MCR tag list, 0-25 does not.
• version, installMaven and mavenVersion exist in the feature definition, with the types used here.
• The file still parses as JSONC, and its root keys are name, image, features.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

[gortazar]

The first attempt of this run was red on parte_2/tema_2.6_despliegue/despliegue_ejem1, and it was not this change — Maven never reads devcontainer.json. Recording the cause here so the second attempt does not look unexplained.

Failed to execute goal maven-surefire-plugin:3.5.5:test: The following artifacts
could not be resolved: org.apache.maven.surefire:common-java5:jar:3.5.5 (absent):
Could not find artifact ... in central

That artifact does exist in Central — common-java5-3.5.5.jar answers HTTP 200. The (absent) marker means Maven had a cached negative result: a previous lookup failed, the local repository recorded the absence, and the shared cache carried that marker into this job, where Maven reported "not found" without going back to Central.

This is a side effect of the warm-cache job added in #3, and a sharper version of the caveat in that commit message. dependency:go-offline does not resolve what surefire pulls at test time, so common-java5 is fetched by the build jobs rather than by warming — and once a failure for it is recorded in a cache that all 86 jobs restore, it stops being transient and becomes sticky for whoever needs it.

The likely remedy is -U on the build step, which forces a re-check of previously failed lookups instead of trusting the cached absence. That belongs in its own change, not in a devcontainer PR.

Rerunning the one job passed, which is the signature of a cached absence rather than a build problem.