Thanks. This appears to be a somewhat significant refactoring along with some behavioral changes to fix the issue reported here. I prefer to separate refactoring from bugfixes and features, to allow people browsing the history to understand what happened. As far as commit access goes, you can request it in the IRC room or on the developers mailing list, and it will be granted pretty much automatically.

In order to fix the issue, it was necessary to use a different kind of procedure to trigger downstream project, namely via the DependencyGraph. In order to do this I had to introduce most of the changes. Then I refactored the plugin to make it a little bit more concise. What kind of approach do you suggest? Should I apply for commit access and then make the changes to the join plugin? Or should I to only fix the bug and create a minimal patch, forgetting about the whole refactoring? I would prefer to have the refactored plugin in trunk, but then we should check if it is backwards compatible.

This issue is really critical as it breaks the parameter transmission when using Join.
This is particularly annoying when a complete build chain uses a property file which is used by all the atomic jobs. At the join, we need to pass again the file.

Let's assume the build chain is designed to be instantiated to build the whole project for different feature or CC/UCM stream... each "instance" has its own starting job with a specific property file. This bug prevents the possibility to use a unique set of jobs. At the join, the "use current job parameters is broken, and the job launched by the join has to read again the file property... but which one. No way to know it !

I'm aware that this is a pain point. wolfs and I have communicated via email, and a patch should be going in soon to address this issue. I have to say I appreciate the work he has done to track it down and put together a patch.

Code changed in hudson
User: : wolfs
Path:
trunk/hudson/plugins/join/pom.xml
trunk/hudson/plugins/join/src/main/java/join/JoinAction.java
trunk/hudson/plugins/join/src/main/java/join/JoinTrigger.java
trunk/hudson/plugins/join/src/main/resources/join/JoinTrigger/config.jelly
trunk/hudson/plugins/join/src/test/java/join/BasicJoinPluginTest.java
trunk/hudson/plugins/join/src/test/java/join/JoinTriggerTest.java
trunk/hudson/plugins/join/src/test/java/join/ParameterizedJoinTriggerTest.java
trunk/hudson/plugins/join/src/test/java/join/ResultSetter.java
http://jenkins-ci.org/commit/34513
Log:
JENKINS-5602

• Fix issue by triggering builds via DependencyGraph
• added some test

Code changed in hudson
User: : wolfs
Path:
trunk/hudson/plugins/join/src/main/java/join/JoinTrigger.java
trunk/hudson/plugins/join/src/test/java/join/BasicJoinPluginTest.java
trunk/hudson/plugins/join/src/test/java/join/JoinTriggerTest.java
http://jenkins-ci.org/commit/34640
Log:
JENKINS-5602: Make join project build even if there are no intermediate projects

I just released version 1.9 of the join plugin. Please check if the issue is fixed there.

Version 1.9 works perfect for me. Thanks!

Fixed in version 1.9

I too can confirm that 1.9 is working. Thanks a lot for fixing this!