The latest (2.15.6) version of the config-file-provider plugin provides an extension point to define an own custom implementation of Config so that the content, MIME type and jelly UI controls can be customized.

Actually I customise the way to produce the contents of my extension, for example by including the credentials in a format of some kind.
The only configurations handled are those Maven, because are shipped with the config-file-provider plugin. This is big deal when I would get my custom configuration by use of ConfigFileBuildWrapper because he miss of my custom logic to fill the content.

To solve this issue in some extension class like ConfigProviderImpl or Config should be added an abstract method that takes in input at least these parameters Run <?,?> Building and TaskListener listener needed to provide the right content at build time with a fallback to the standard Config.content. This changes allow (do not force) also to centralise the provisioning of the configuration file in the right way (token replace, workspace@tmp folder and so on), instead copy/paste the same logic of ManagedFileUtil.provisionConfigFiles to the custom builder/buildwrapper because potentially error prone and are not updated with bug fixes.

The call sequence in practices

ManagedFileUtil#provisionConfigFile (can also handle a single ManagedFile)
-> Config.supplyContent(build, listener)
-> do the custom elaboration
-> back content
-> return the FilePath to the file