Use variant-aware dependency management

[jjohannes]

This is a larger update of the plugin discussed with @wolfs. Following the discussions on #128 and beyond.

It uses the new variant-aware dependency management capabilities of Gradle and Gradle Module Metadata to better model the different variants of component (jar vs. jpi) in the Jenkins ecosystem.

This is WiP for further discussion for now.

[sghill]

Thanks so much for this @jjohannes! 🎉

At first glance it looks like there are some significant changes that aren’t backwards compatible. I’d prefer to deprecate the old components and bridge to the new ones in order to simplify upgrading and migrating for consumers.

I’ll take me some time to look through all the changes here, but wanted to make sure you knew I saw the PR.

[jjohannes]

Thanks @sghill! I have also discussed some more things today with @wolfs and found some issues. So I am still working on this. And yes there are some fundamental changes (for the better).

But I agree that we have to discuss compatibility. Once this is in a state where we think it is good on its own, we can have a look at compatibility to assess what we want and how hard it is to do.

[wolfs]

Some more feedback.

[jjohannes]

Thanks for the feedback @wolfs. I think this is now in a quite good state.

The main thing that remains to be discussed is what to do in terms of compatibility. From my point of view, there are two items:

1. Can we move to Gradle 6.0 as min Gradle version?
2. Should we keep the 'old' configurations (jenkinsPlugins, optionalJenkinsPlugins , jenkinsTest) around?

I think (1) will be quite hard to do. But if, I think the easiest would be to keep two separate implementations around of all classes that were modified in this PR.
For (2) jenkinsPlugins and jenkinsTest would be easy to add just as "aliases" for api and testImplementation. optionalJenkinsPlugins would be more tricky to do and make the code more complicated - also the metadata produced from this would not be ideal.

I think I would prefer one of two options:

• Not keep compatibility - You could do a 0.38 release with this and users who can't move to Gradle 6, or don't want to update their dependency declarations, need to stay on 0.37.x - you could do more 0.37.x bugfix releases if it becomes necessary.
• Keep two implementations (as suggested above). And then, when users switch to Gradle 6, they also have to switch to the "new way" of declaring dependencies. And if they can't, they can stay on Gradle 5 for now. (There should be a plan to eventually remove the old implementation.)

Once a decission is made, we should describe it in the README (as suggested by Stefan #132 (comment)).

@sghill what is your take on this? You can also ping Stefan and me on the Gradle Slack if you want to discuss directly.

[sghill]

Thanks for all the updates, and the effort around asserting that the data in the new module files is correct.

I added a few questions, and would prefer to at least explore keeping backwards compatibility with the configurations and Gradle versions.

[wolfs]

@sghill Thank you for bringing up your concerns about backwards compatibility. I wonder though what is blocking folks from upgrading their plugin builds to Gradle 6. I would say that isn't a problem given that the gradle-jpi-plugin supports Gradle 6 and normally not much else is used in a plugin build.

How about we issue PRs to all the plugins under the jenkinsci organization to upgrade to Gradle 6(.1.1)?

If the plugin would support both Gradle 6 and earlier versions, then my fear is that features need to be implemented in two different ways, two different sets of tests need to be maintained, etc. For maintainability I think it would be better to keep a 0.x line which is compatible with Gradle 4.x - 6.x and a 1.x line which is compatible with Gradle 6.x and later. If there is a bug found in the 0.x line it is easier to fix it on the corresponding branch. Though I don't see what bugs could appear now, given that the plugin seems to work quite well for most people.

[sghill]

I would say [upgrading to Gradle 6] isn't a problem given that the gradle-jpi-plugin supports Gradle 6 and normally not much else is used in a plugin build.

This is a good point @wolfs.

@jjohannes said in #132 (comment):

Can we move to Gradle 6.0 as min Gradle version?

Yes, I'm OK with making Gradle 6.0 the minimum version for these reasons:

• As @wolfs alluded to, if anyone wanted to upgrade incrementally as I described in Use variant-aware dependency management #132 (comment), they'd really just need to first bump to gradle-jpi-plugin 0.38.0 and move to latest once on Gradle 6.0.
• The simplification of the plugin by removing the branching logic is nice
• This opens the door to getting rid of the bespoke source jar and javadoc jar tasks later on, since those have been added in Gradle 6.0.

How about we issue PRs to all the plugins under the jenkinsci organization to upgrade to Gradle 6(.1.1)?

That'd be really appreciated, but to be clear I don't think it's a requirement for merging this excellent change.

If the plugin would support both Gradle 6 and earlier versions, then my fear is that features need to be implemented in two different ways, two different sets of tests need to be maintained, etc.

Not a big sticking point since we're making the minimum version Gradle 6.0, but I do think Gradle Test Kit changes this equation, making backwards-compatibility cheaper to implement in general. One of the nice things I saw about this approach of (1) create a build file, (2) execute a task, and (3) assert on the outcome meant that different implementations for different versions of Gradle just needed to make the same test pass.

For maintainability I think it would be better to keep a 0.x line which is compatible with Gradle 4.x - 6.x and a 1.x line which is compatible with Gradle 6.x and later. If there is a bug found in the 0.x line it is easier to fix it on the corresponding branch. Though I don't see what bugs could appear now, given that the plugin seems to work quite well for most people.

I'm thinking something similar to this, though I'll probably stay on 0.x for the time being. I agree there is a low likelihood of needing bugfixes on the older plugin.

[jjohannes]

Thanks for the additional feedback @sghill. I think the plan you outlined here - #132 (comment) - sounds good.

[wolfs]

LGTM!

[sghill]

This was published in a prerelease today: v0.39.0-rc.1

[jjohannes]

Thank you for moving so quickly with this @sghill!

[wolfs]

@jjohannes I tried it out in the gradle-plugin, and it seems that the tests can't be compiled any more: https://scans.gradle.com/s/dyyhfbrlqaie6

Moreover, there are quite some warnings that spotbugs doesn't find some classes.

Can you take a look?
jenkinsci/gradle-plugin#99

[sghill]

The changes in #135 have been pre-released as v0.39.0-rc.2 today.