This issue is not solved.
We use version 1.443 with maven 2.

We have a project like this:

master project (pom.xml type pom)
– core project (pom.xml type jar)
– web project (pom.xml type war, depends on core)
– ear project (pom.xml type ear, depends on web)

In jenkins, we define 4 jobs, one for each module:
project-master > clean install -e -X -N (non recursive)
project-core > clean install -e -X
project-web > clean install -e -X
project-ear > clean install -e -X

And for each of them, we check the box "build whenever a snapshot dependency is built"

=> it works fine, for example, when the core is built, it triggers the web, then the ear.

The problem comes when we create a new job, let say "project-nightly" that will be executed each night on the complete project.
project-nightly > clean deploy -e -X

The creation of this last jobs breaks the triggering of all other jobs !!
So when the core is built, the web is not triggered.
And when the nightly is build, all other jobs are triggered !!!

Olivier, this works as designed. There's always only the dependency between one upstream project and the downstream project. So after configuring the "project-nightly" job, Jenkins decided that this job should be the preferred one, because deploy goals have prefeference over install.

I think, I've got an open ToDo to document the exact rules used to determine the up-/downstream relationship by Jenkins.

Note that there are several open issues (e.g. JENKINS-1295) which ask for a more fine-grained configuration of up-/downstream relationships.

The current automatic approach is one which works IMHO in most of the cases 'as expected', but there are surely always cases - like yours - were an automatic mechanism doesn't fit the expectations.

Ok. Right !

But let me explain the behaviour that I would like to have...

• I have one slave and the master.
• I would like to define jobs for each modules (so 4 jobs), that builds on the slave (clean install), and that are triggered by a commit (so polling). The goal is to check continuously that all components build fine with the modifications done by developpers during the day. So if a commit is done in project-core, then the project-web should also build ... aso => because it's just an install, developpers are not impacted by new snapshot artifacts during the day.
• I also would like to have a nightly build that is executed on the master (clean deploy) each night. This way, new snapshot artifacts will be available for download on the following morning. Pay attention that the nightly build should not trigger component jobs on the slave.

Do you have a solution or some tips to help me configuring this kind of behaviour ?

I guess a fix of JENKINS-1295 would be the right fix ....

There's one thing you could try, but no guarantees that it'll work - I've never tried it.

• Put the deploy goal (or a deploy:deploy) in an M2 post-build step while only having an install in the normal goals.
• Rename the deploy job so that it come alphabetically after all other jobs (i.e. put a 'Z' in front)

That way it could work

BTW: please redirect all further questions into the users list. This is not the right place for discussions

I dont know why this issue is marked as "not reproduceable"?

We are using 1.518 version of Jenkins, and the problem is still here.

Like "Olivier Lambert" described it... => The problem is that the automated downstream dependency triggering chain won't work, if you have any other newer job on the same Jenkins instance, where the same versioned SNAPSHOT-project gets built.

But that's a killer! We really need other jobs that build the same projects, because we have the module- Continous integration - build conecpt on the one hand and the monolothic build approach for release builds on the other hand.

so what would be the problem, that Jenkins just BUILDS ALL jobs with related project dependency versions? (instead of just the "newest" like it obviously does)

As stated in an earlier comment, this is currently working as designed.
If you want a different behaviour, you should open a new feature request with a concrete description what you like to have.

PS: it's not the 'newest' job which is triggering, but the one with the most relevance (e.g. deploying jobs)
PPS: maybe you can achieve what you want with explicitly configured dependencies between your jobs

kutzi - I suppose that when I check "Build whenever a SNAPSHOT dependency is built" I have no idea about the fact that Jenkins is going to choose just one upstream project for anything. The only proper behaviour of this option - is to build absolutely everything that depends on this job. At least, this is the most expected behaviour.
So you should first rename current option or at least give some self-explanatory hint about this fact.
And second - add another option that does what everyone expects.

Is this worth creating another issue? Maybe we can edit this issue to make it the feature request ?

Boris IMO there are several good reasons for having it the way as it is.
E.g. you could have a cascade of jobs building the upstream project, each one running longer and longer tests/reports.
E.g. build+unit tests -> component tests -> performance tests -> reports (FindBugs, Code Coverage etc.)
Usually you want only one of these jobs to trigger the downstream job(s) and not each one

That being said, I can also see that there may be other valid scenarios where you want each upstream job to trigger downstream jobs. And the documentation for the existing can certainly be improved.

Yes, as I said already: please create a feature request if you want this to change

My feature request - JENKINS-13390.
Anybody here - please vote.