Skip to content

Plugin is incompatible with the "java-platform" builtin plugin #121

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
eyalroth opened this issue Oct 27, 2019 · 2 comments · Fixed by #122
Closed

Plugin is incompatible with the "java-platform" builtin plugin #121

eyalroth opened this issue Oct 27, 2019 · 2 comments · Fixed by #122

Comments

@eyalroth
Copy link
Contributor

One way to align versions of dependencies in a multi-module project is via the java-platform builtin plugin. The plugin is applied on a specific sub-project and declares all the dependencies' versions there. This is explained in the official documentation.

The problem arises when this plugin -- scoverage -- applies itself to all the sub-projects automatically, which causes an incompatibility error in the dependencies sub-project, as the java-platform plugin cannot be applied simultaneously with a java plugin such as scoverage.

I believe the only viable solution here is to remove the behavior of automatically applying the plugin on sub-projects. This was also requested in #118, so I think this really is the way to go.

The only problem with this approach is that it might silently break users' builds. This may not even raise any errors but only change the coverage statistics without users understanding why. Perhaps it is enough to raise a warning whenever the plugin is applied only for the purpose of aggregation (on root projects with no source code) but without the plugin applied on any sub-project with code (scala plugin applied as well).

@maiflai
Copy link
Contributor

maiflai commented Oct 28, 2019

I'm not overly worried about requiring users to change their builds - I think this is what the major version number is for.

Could we detect the presence of the java-platform plugin? I suspect this would then require users to order their plugins, which also seems bad.

eyalroth added a commit to eyalroth/gradle-scoverage that referenced this issue Oct 28, 2019
…n by removing auto-apply on subprojects
@eyalroth
Copy link
Contributor Author

We could detect the presence of any plugin, but I don't believe that's necessary. The java-platform is intended to be applied on non-code modules, of which this plugin has no interest in.

eyalroth added a commit to eyalroth/gradle-scoverage that referenced this issue Oct 28, 2019
eyalroth added a commit to eyalroth/gradle-scoverage that referenced this issue Oct 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants