I am experiencing the exactly same issue here with my Hudson installation (same plugin versions).

Do you get any stack traces in the console output when the parameterized build is supposed to start, but doesn't?

I see the same problem with XP Pro SP2, Hudson 1.349, Join 1.8 and Hudson Parameterized Trigger 2.3. No stack track in the logs (loglevel FINEST).

I'm seeing this behavior too. XP Pro SP3,same Hudson and plugin versions, no stack traces. If I check the 'aggregate downstream archives' option, that one does fire (I think I got a log saying 'nothing to aggregate'). I took a brief look through the code, and it looked like both plugins were triggered using the same mechanism, which makes me wonder if the issue is in the Parameterized Trigger plugin, rather than the Join plugin.

I'd like to say that this used to work when I started using Hudson (which was about a month or so ago) and stopped working after some upgrade, but I can't say for sure.

I posted a repro here before I knew that I wasn't supposed to post in that forum.

I also do not get any stack traces.

JENKINS-5981, filed against the parameterized trigger plugin seems to suffer from a similar underlying issue.

JENKINS-6141 may have discovered the reason for this error.

Just for info:
I am using a "free style software project" (not Maven) when experiencing this problem.

Exactly same situation as repro from sauravsengupta.
Join plugin (version 1.8) and Hudson Parameterized Trigger plugin (version 2.3)

Same situation on a Solaris10 machine with Join 1.8 and Parameterized 2.4, for a Free style Project.
I have nothing related in in log or console.
But ... it appears that it finally correctly fire after I've made too many trials to be able to understand what has finally made it works !
Probably not a trivial bug....

I have the same situation. After analyzing the source code of both the join and the parameterized trigger plugin it seems to me that the parameterized trigger uses only the "new" DependencyGraph feature of Hudson to trigger builds, while the join plugin still tries to trigger the build via perform. This happens on Hudson versions later than 1.341.
I modified the source code of the join plugin accordingly. Is there the possibility to replace the current join plugin by my modified version?

If you have commit access, go ahead and commit it, otherwise attach the patch here.

I don't have commit access but I would like to have I'm still writing some test cases, when I am done with it I will attach the files here.

A refactoring of the join plugin which should fix this bug. Contains also some integration tests.

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

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!