What is the best practice to handle the frequently API signature changes in Gradle? We need to compile our plugin for different Gradle versions again.
Without the recompile or if you use the wrong plugin version the users receive a java.lang.NoSuchMethodError at runtime. Currently we have already 4 different plugin versions for different Gradle versions. Can the plugin portal handle this?
Please don’t get me wrong by the way. I’m sure there are things that are only possible with internal Apis at the moment. We should talk about those use cases and then publish the necessary minimal Api.
But what I saw so far in the plugin could definitely be done with far less internals. So the first step should be refactoring to use as little internals as possible. The second step would be to look at the remaining internals together to see what needs to be public.
The “content” variable look not like typical Gradle code. The calling of a copy() method will produce a very large performance decrement. It is very bad practice to copy hundreds of megabytes to receive the directory structure and then delete it.
But we have lost touch the original question. It there any good option to handle the version of plugins depends on the Gradle version?
I don’t know what you mean. The distribution plugin does the same and this is how all copying/bundling tasks should look like.
As I said, you shouldn’t need to. Only use public APIs and tell us about the specific situations that don’t work, so we can fix them. How is Gradle supposed to get better if we don’t know the things that don’t work for you?
I’ve forwarded the bundling use case to the team. I’m sure we can make something happen there.