Started working on this issue today after a long time (it's quite a storm outside anyway). Alas I couldn't find a good solution yet. Branch: https://github.com/jenkinsci/active-choices-plugin/tree/pipeline-support
Started by fixing the variables jenkinsBuild and jenkinsProject for pipeline builds (which also removes one deprecated method call at least).
Then created a few pipeline jobs to test the plug-in. As expected, when you add "This build is parameterized", everything works as expected.
But if you call another job, the cascaded parameters do not receive updates from other parameters. The behaviour is the same you would see by scheduling a job with AC cascaded parameters.
When a job is scheduled without the UI, we could - in theory - still create the values for parameters, and then notify other parameters about the update, or read the value of the referenced parameters. These are the two options we have I think.
Alternative 1) notify other parameters about the update
We are able to do that, because we basically hijack each parameter in the UI that we need, and add event listeners to notify parameters. But in the Java side, there is no option for doing the same.
We could modify our parameters in Active Choices to notify other parameters in the "default value" method, or even check what was the "Cause" that triggered the job, and identify when the UI/DOM is not available... but we don't have an option to update other parameters such as String Parameter. Nor we have any extension point in Jenkins for that.
Alternative 2) read the value of the referenced parameters
In this case, you have something like PARAM1 – is referenced by – > PARAM2. In the UI, you must have PARAM1 configured before PARAM2, so that PARAM1 is executed first.
The order is kept in timer scheduled builds. So PARAM1 is executed fine. But when PARAM2 (which is either a HTML referenced parameter, or a cascade choice parameter) is executed, the value of its referenced parameters is not updated.
Inside the PARAM2 execution, you can retrieve the project (we already do that, to put the jenkinsProject variable in the context for Groovy). And via the project, you can retrieve the other parameters. Amongst these parameters, you can find the one that is referenced by PARAM2, i.e. PARAM1.
However, there is no value associated with PARAM1. The value is never stored in some context or session that can be accessed by other parameters. I believe because Jenkins was not designed for that, which makes sense I think.