Federico Mariani created CAMEL-26534:
----------------------------------------

             Summary: camel-itest-spring-boot - nested Maven runs use -nsu, so 
version ranges resolve against stale cached metadata
                 Key: CAMEL-26534
                 URL: https://issues.apache.org/jira/browse/CAMEL-26534
             Project: Camel
          Issue Type: Bug
          Components: camel-spring-boot
            Reporter: Federico Mariani
            Assignee: Federico Mariani


{{CamelOpenfeatureIT}} fails in Camel-Spring-Boot Daily #439 (builds35):

{noformat}
Could not collect dependencies for project 
com.example:camel-openfeature:jar:1.0-SNAPSHOT
No versions available for 
dev.openfeature.contrib.tools:flagd-core:jar:[3.0.0,4.0.0) within specified 
range
{noformat}

Camel bumped {{dev.openfeature.contrib.providers:flagd}} from 0.14.2 to 0.15.0 
on 2026-11-02. flagd 0.15.0 declares {{flagd-core}} as {{[3.0.0,4.0.0)}} 
(0.14.2 declared {{[2.0.0,3.0.0)}}), and flagd-core 3.0.0 has been on Maven 
Central since 2026-10-15. The reactor build is not affected because 
camel-parent pins flagd-core; the generated archetype project only imports 
{{camel-spring-boot-bom}}, so it has to resolve the range.

{{ArchetypeGenerationExtension.runMaven}} passes {{-nsu}} to the nested Maven 
runs (CAMEL-25465). In Maven 3.9 {{-nsu}} sets the session update policy to 
{{never}}, and Maven Resolver applies it to release repositories as well as 
snapshot ones. So the range is matched against the 
{{maven-metadata-central.xml}} the agent's shared local repository already 
holds. On builds35 that file dates from before flagd-core 3.0.0 existed, and 
with {{-nsu}} it is never refreshed: the test keeps failing on any agent in 
that state, and any future version range in a starter's dependency tree can 
break the same way.

Fix: drop {{-nsu}}. With the default daily policy stale metadata is refreshed. 
The reactor build runs with {{-U}}, so the Camel core snapshots are already 
checked for the day; the remaining cost is about one metadata request per IT, 
for its own starter.

_Claude Code on behalf of Federico Mariani_



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to