Branch: refs/heads/XCOMMONS-3817-webjar-handler Home: https://github.com/xwiki/xwiki-commons Commit: ce9c98af86fc16e40adf17452966e5ecabb8d5a0 https://github.com/xwiki/xwiki-commons/commit/ce9c98af86fc16e40adf17452966e5... Author: Vincent Massol <[email protected]> Date: 2026-10-13 (Tue, 13 Oct 2026) Changed paths: M xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-repositories/xwiki-commons-extension-repository-maven/pom.xml M xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-repositories/xwiki-commons-extension-repository-maven/src/main/java/org/xwiki/extension/repository/maven/internal/handler/MavenArtifactHandlers.java A xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-repositories/xwiki-commons-extension-repository-maven/src/test/java/org/xwiki/extension/repository/maven/internal/handler/MavenArtifactHandlersTest.java Log Message: ----------- XCOMMONS-3817: Upgrade embedded Maven to 3.9.10 and Maven Resolver 2.0.24 * Make MavenArtifactHandlers#getByPackaging deterministic: when several handlers share a packaging, the one whose type is the packaging wins, whatever the order in which the handlers are added. Since Maven 3.10.0, DefaultArtifactHandler is a @Named @Singleton component of maven-core, so Sisu also exposes it under the "default" hint with the webjar packaging, and the per-session copy of the handlers could let that alias win for the webjar packaging: a webjar dependency was then resolved with the jar extension type (RuntimeAetherDefaultRepositoryManagerTest#downloadWebjarDependency failing in xwiki-platform). * Fill the handlers from the copy constructor through a private method instead of the overridable add(), to avoid a possible 'this' escape. * Add MavenArtifactHandlersTest and raise the module coverage threshold to 0.80. Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-commons/settings/notifications