Consider rollback jenkins configurations and mark them as deprecated

[rpalcolea]

Hi folks,

I was looking at removals for the next version:

Removed
jenkinsPlugins configuration (use implementation)
optionalJenkinsPlugins configuration (use Gradle feature variants)
jenkinsTest configuration (use testImplementation)

Wondering if this could be added back and extend those configurations instead and have them as deprecated for a while so folks can move on their own pace instead of introducing the breaking change?

Thoughts? // cc @rahulsom

[sghill]

Definitely worth considering @rpalcolea. The change in optionalJenkinsPlugins doesn’t have a straightforward path forward without breaking, but the other two do. The original discussion was here: #132 (comment)

Discovering the impact of this breaking change was mentioned here as a reason to publish the candidates before making a decision on releasing: #132 (comment)

One other option is if it’s simpler/faster to define the configuration inheritance in an intermediate plugin.

[rahulsom]

The warning idea sounds good, but this is a 0.x plugin, so I wouldn't want to burden it with having to maintain backwards compatibility. I wonder if there is a way to break the build and explain the new approach at the same time...

[rpalcolea]

configurations could be restored but fail the build when used

[wolfs]

configurations could be restored but fail the build when used

I don't see this a big improvement, given that in the current state the build fails as well.

Regarding backwards compatibility: The RC candidate currently only works on Gradle 6.0. Is this also a problem? Or is it enough to have the old configurations working for a few more releases until they are removed?

[rpalcolea]

It is more of a migration other than gradle compatibility + error messaging could be more helpful than configuration not found, with plugin specifics on how to migrate

[rpalcolea]

This is what I had in mind: #150