Thanks for the kind word benzht. I don't know yet how we will be able to discover these runtime dependencies as they seem to not be catch by the org.apache.maven.project.DependencyResolutionResult event we are tracking.

The work-around for the WAR works: the WAR versions built with compile and runtime scope are identical.

Sadly, the build-trigger is still not working but that seems to be related to JENKINS-46313 and may require another ticket and some time to build a test scenario. My upstream project is multi-branch, multi-(maven)-module. The downstream WAR overlay basically depends on all branches with the right version number. But rom the point of view of the dependency-relationships, the branches all depend upon one another (but don't trigger each other).

Effectively, the downstream project depends on the upstream (branch) project directly (a–>b) and at the same time indirectly via other upstream branch projects (a–>a'–>b). And that seems to be the trigger-exclusion criteria of JENKINS-46313.

cleclerc, do you see here a misconfiguration on my side or should I build a ticket with demo projects for it?

I may have reproduced the problem. I'll add details to the recently introduced maven dashboard for build results (in master branch but not released yet) to help troubleshooting.

benzht can you install v3.5.0 and look at the "Maven" build details screen for your war pipeline and your war-overlay pipeline?

Please look at the "dependencies" of the war-overlay pipeline and at the "downstream pipelines" of the war pipeline

cleclerc, I have upgraded everything to 'current' including the 3.5 version.

The upstream project (on matrix level) list the following
Downstream Jobs

• Downstream1 » develop
• Downstream2 » develop
• upstream » develop
• upstream » feature/jenkinsWork
• upstream » feature/t6482_keycloak
• upstream » feature/testServer

The downstream projects Downstream1.develop and Downstream2.develop list the following
Upstream Builds

• upstream » feature/testNewServer #78
• upstream » feature/jenkinsWork #24
• upstream » develop #40        <—this is the most recent build number
• upstream » feature/t6482_keycloak #3

The downstream matrix project config has Build on Snapshot dependency set.

But Upstream-develop Build #40 did not trigger either of the Downstream projects. This is the end of the logs:

[withMaven] Not triggering Downsteam1 » develop because it has dependencies in the downstream project list
[withMaven] Not triggering Downsteam2 » develop because it has dependencies in the downstream project list
Finished: SUCCESS

Is there anything else I can test, log, or try to help you further?

My best guess would be to exclude all sister-branches in a multi-branch project from being considered as being downstream. That way they would not prevent the real downstream projects from being triggered.

benzht I haven't had time to look at the setup you described and compare it with ours, however, I am seeing the exact same message with a non-multibranch setup:

Basically, a module pipeline is included in a webapp pipeline, which is then overlaid in another pipeline. Building the module results in:

[withMaven] Not triggering webapp because it has dependencies in the downstream project list
[withMaven] Not triggering overlaid-webapp because it has dependencies in the downstream project list

To me the issue seems to be that both webapps are listed twice as dependency to themselves in the Maven dashboard. That doesn't look right, shouldn't self be excluded from being a possible dependency to any job?

Note: as war-overlay "dependency" is not a "standard Maven dependency", we may look at solving this problem in conjunction with solving JENKINS-50475 (Maven BOM Dependency) which is not either a "standard Maven dependency".

war-overlay and maven-bom dependencies are not "standard Maven dependencies", we may look at solving these 2 problems simultaneously.

A quick look at the code, I don't see "runtime"?

Wouldn't adding "runtime" work?

DependencyResolutionResultHandler

line 50:

private Set<String> includedScopes = new HashSet<String>(Arrays.asList("compile", "provided", "test"));

to

private Set<String> includedScopes = new HashSet<String>(Arrays.asList("compile", "runtime", "provided", "test"));