[ 
https://issues.apache.org/jira/browse/FELIX-6870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Rütter resolved FELIX-6870.
--------------------------------
    Resolution: Fixed

This can merge once [https://github.com/apache/felix-dev/pull/433] is merged.

> Integration tests across the repository run against released bundles, not the 
> code being built
> ----------------------------------------------------------------------------------------------
>
>                 Key: FELIX-6870
>                 URL: https://issues.apache.org/jira/browse/FELIX-6870
>             Project: Felix
>          Issue Type: Improvement
>            Reporter: Paul Rütter
>            Assignee: Paul Rütter
>            Priority: Major
>
> Most modules pin released versions of sibling Felix bundles as 
> {{{}test{}}}-scoped dependencies, and pax-exam then runs their integration 
> tests on those released artifacts rather than on the code in this repository. 
> So those tests cannot catch a regression introduced here, and several run on 
> a framework two major versions behind.
> Found while fixing FELIX-6869, where exactly this hid a real bug: 
> {{FilterImpl.WrapperCapability}} had {{Filter.matches(Map)}} throwing 
> {{UnsupportedOperationException}} for any non-empty map, which broke 
> whiteboard servlet registration. {{JettySniHostCheckIT}} passes on the pinned 
> framework 7.0.5 and fails with {{404}} instead of {{200}} on the framework in 
> this repository. The regression sat on master undetected until the HTTP tests 
> were pointed at the local build (FELIX-554 / FELIX-6869).
> Full survey, {{{}test{}}}-scoped pins of Felix artifacts:
> ||module||artifact||pinned||
> |{{configadmin}}|framework|7.0.5|
> |{{configadmin}}|framework.security|2.8.3|
> |{{eventadmin/impl}}|framework|6.0.3|
> |{{gogo/jline}}|gogo.command|1.1.2|
> |{{healthcheck/core}}|framework|7.0.5|
> |{{healthcheck/webconsoleplugin}}|healthcheck.core|2.0.0|
> |{{http/itest}}|framework|7.0.5|
> |{{http/jetty}}|framework|7.0.5 → fixed by FELIX-6869|
> |{{http/jetty12}}|framework|7.0.5 → fixed by FELIX-6869|
> |{{ipojo/manipulator/manipulator-it}}|configadmin|1.6.0|
> |{{ipojo/runtime/composite-it}}|configadmin|1.8.0|
> |{{ipojo/runtime/core-it}}|configadmin|1.8.0|
> |{{ipojo/runtime/core}}|framework|4.2.1|
> |{{resolver}}|utils|1.8.0|
> |{{rootcause}}|framework|6.0.5|
> |{{scr}}|configadmin|1.9.0|
> |{{scr}}|framework|7.0.1|
> |{{systemready}}|framework|6.0.5|
> Plus {{ConfigAdminSecurityTest}} provisions 
> {{org.apache.felix.framework.security}} *2.6.1* inline in the test source, a 
> third version of the same artifact.
> {*}Suggested approach{*}, following what FELIX-6869 did for the two Jetty 
> modules:
>  # Make the version a property, keeping the current release as the default so 
> each module still builds standalone — the modules here are built 
> independently, not through one reactor, so a {{SNAPSHOT}} default would break 
> a fresh clone.
>  # Have CI build and install the producing module first and override the 
> property with the version it just built, e.g. 
> {{{}-Dfelix.framework.version=$(mvn help:evaluate 
> -Dexpression=project.version ...){}}}.
>  # Order the CI steps accordingly, and make the producer step run when either 
> it _or_ a consumer changed — otherwise a consumer-only change finds nothing 
> to resolve.
> {*}Expect this to surface failures{*}, and that is the point. Switching a 
> module over should be verified per module rather than in one sweep. Two 
> things known in advance:
>  * {{org.apache.felix.framework.security}} is removed in the 8.0.0 framework 
> line (FELIX-6807), so {{{}configadmin{}}}’s pins of it — in both the pom and 
> the test source — have no counterpart there. {{ConfigAdminSecurityTest}} is 
> already excluded above JDK 17 because it needs 
> {{{}-Djava.security.manager=allow{}}}, fatal from Java 24 on (JEP 486).
>  * {{{}scr{}}}’s integration harness could not be verified locally on 
> Windows: {{ComponentTestBase.createBundleInputStream}} fails with 
> {{IOException: Access is denied}} on both the pinned 7.0.1 and the local 
> build, so that one needs checking in CI on Linux.
> Some of these are moot if the module is retired — {{ipojo}} has a removal PR 
> open and pins framework 4.2.1 — so it is worth triaging the list before 
> changing anything.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to