I don't know if this is a Build Pipeline Plugin bug or a Fingerprint bug, or a Maven Plugin bug, but it is more in the way when using the BP Plugin. Or a feature.

I have a multi-module Maven3 project:

foo-parent
/foo (war module)
/foo-integration with a dep on "foo" (will contain Selenium tests in the future)

I have 3 Jenkins jobs:

• Foo (mvn clean install, restricted to /foo)
• Foo-Checks (mvn some:checks foo-parent, restricted to /foo)
• Foo-Integration (mvn some:things foo-parent, restricted to /foo-integration)

Everything is run against foo-parent. "restricted to /foo" means "-pl foo -am" mvn option.

Foo is triggered by SCM
Foo has a post build action: it triggers Foo-Checks
Foo has a post build action: Build Pipeline downstream job (allow to trigger Foo-Integration)

At this point, everything is perfect:

• Foo-Checks is a downstream job of Foo
• Foo-Integration is a downstream job of Foo-Checks
• The build pipeline view shows:

  Foo => Foo-Checks => Foo-Integration
  

If Foo is triggered, still OK.

But, if I manually trigger Foo-Integration in the Build Pipeline view:

• Foo-Integration becomes a downstream project of Foo
• The build pipeline view shows:

  Foo => Foo-Checks => Foo-Integration
      => Foo-Integration
  

I tried to delete some fingerprints, but I have the feeling there is some "magical" in the job tree algorithm using Maven dependencies.

Is this really a bug?

If not a bug, would it be possible to have an option to set the "upstream/downstream" tree ignore maven dependencies/modules? Or just in the Build Pipeline tree?