• Please test beta version 3.6.4-beta-1
• To verify, please enable logs org.jenkinsci.plugins.pipeline.maven.listeners.DownstreamPipelineTriggerRunListener at the FINE level and see message such as

  [withMaven] downstreamPipelineTriggerRunListener - Skip triggering my-multi-jar-project » PR-1 for 
  MavenArtifact{com.example.multi-jar:shared-core:jar:0.0.1-SNAPSHOT(version: 0.0.1-20181202.224248-35, snapshot:true) } 
  because it generates artifact with same groupId:artifactId 
  MavenArtifact{com.example.multi-jar:shared-core:jar:0.0.1-20181202.224107-34(version: 0.0.1-SNAPSHOT, snapshot:true) }
  

• Please ensure that you use a MySQL database instead of the embedded H2 database as documented in "Using a MySQL Database"

To download 3.6.4-beta-1: https://github.com/jenkinsci/pipeline-maven-plugin/releases/tag/pipeline-maven-3.6.4-beta-1

Hello!  

 Thank you for your efforts so far.  It might take a few more days for us to test, but I will answer you here.

Thanks thorsten_langer_sla

Shipped in v3.6.4

Unfortunately, my downstream pipelines do generate the same artifact ( just not deploy to  maven repo). am I toasted?

Use case:  one main pipeline ( mvn deploy) triggers a number of pipeline using same source to run integrations in parallel ( mvn install). See 

1. JENKINS-53382

dantran we brainstormed with aheritier and we felt that a reasonable default behaviour would be to not trigger pipelines that work on the same pom.xml. The implementation we chose, as we don't capture for the moment the pom.xml details (1), is to not trigger pipeline that generate the artifact that would be the reason of the trigger.

This solution is fixing all the problems of multi-module Maven projects with multiple git branches but is unfortunately excluding your scenario.

How frequent in your organisation is this scenario of chaining pipeline using same pom.xml? How many Maven apps do you build? How many Maven pipelines do you have? How many of such chain of pipelines do you have?
Did you consider merging these chained pipelines in a single pipeline job? Did you face problems trying this?

(1) SCM details + path in the SCM repo + introducing a POM entity in our data model between the builds and the dependency

Fixed in 3.6.4

We have one large repo with 400+ maven modules including both production and integration test sources.  Main repo build (~60min)  does build integration test modules abut not running them.  We also have many wrapper repos clone the main repo at build time and run

  * subset of integration tests at each repo ( ie main build trigger a number of parallel integration test builds

  * Platform sanity builds ( windows, etc)

Merge them into a single pipeline are big, complex, and long.

is there a way to disable maven pipeline event listener after we clone the main repo at the test pipelines?

on the second thought, i am going to create a delegate job to invoke my sub jobs directly.  So we good ( a --> b --> delegate --> c,e,f   etc )

but, it would be great to have this fix  https://issues.jenkins-ci.org/browse/JENKINS-53382

We can confirm, that the triggering from master to branches does not occur anymore.

We tested this using the standard DB, because changing the DB to the MySQL version mentioned above was a bit tricky in our setup.

In the log-file we cannot see any of these skip-messages you expected.

Please note, that the branches (jobs) are still listed as downstream jobs of master job in the maven tab in the classic website.

 Thank you very much!