@Andy_Wilkinson @graeme.rocher I believe Groovy deserves nearly zero blame for backward compatibility issues. There are 3 major contributing factors in my mind across the different major versions of Gradle:
- Shading different classes in Gradle JARs across different versions
- How we use ClassLoaders
- Changing Groovy versions over time
Groovy deserves zero blame for the last point. We had to know adopting a new major version of Groovy could break compatibility between Gradle versions in some ways. We took that risk for the great new features Groovy 2.x gave us.
Where possible, using Java seems like the most robust choice but when you want to provide a DSL some use of Groovy is required as far as I can tell.
For Gradle 2.13 and earlier, Groovy is more or less required for a DSL. We have had to eliminate this requirement so that we can enable build scripts written in other languages, starting with Kotlin.
If there’s a safe or lower risk way to do so, I think it’d be very helpful to document it somewhere.
Acknowledged. I cannot prematurely announce what we’re working on in order to help here, but I will solicit your feedback directly when we do. Soon.
Perhaps we can help initially by reviewing code changes in the above mentioned plugins that you have doubts about. If you’d rather have our input earlier, it would be best to create a new post in this forum stating the technical goal you’re trying to achieve and the Gradle team can advise.
@melix @lhotari I’m trying to support Gradle 1, 2, and 3 with the same binary. Is that overly ambitious? I’m currently building the plugin with Gradle 1.12. I also build and test with 2.x and 3.0.
As you and @CedricChampeau agreed, this is ambitious. It will become even more ambitious as we make progress in fixing this by moving stuff out of “internal” or providing new public APIs. I think you may end up limiting your plugin capabilites very much or alternatively have to provide a lot of code of your own to compensate. More on this below.
This sounds excellent and I would like to contribute to that discussion if I can.
Great. This very discussion can is a start.
I understand why you want to be able to support Gradle 1.x and forward with 1 binary. I wish I had a silver bullet here for you, but I don’t. I don’t think it is reasonable for you to live the amount of pain that would cause you and I further don’t expect to convince you to revert https://github.com/spring-gradle-plugins/dependency-management-plugin/commit/6f1c3d9686c542960977cecb6d2a337d91f11eae immediately.
The way I see it, there are 2 ways forward:
We try to ensure backward compatibility between 2.x and 3.x from your needs in the future
We convince you and everyone that Gradle 3.x is worth supporting. I see so many compelling features in Gradle 3.1 - 3.3 that if you still remain unconvinced… then I guess Gradle needs a significant pivot in strategy.
Other than plugin docs and compatibility avoidance, is there anything else that would help? Would it require releasing a Gradle 1.13 that made select classes available across all versions?
if all of Gradle’s own plugins were written purely against public API, it would things make it much easier for plugin developers to offer similar functionality and would also help to give users a more consistent experience across plugins if the underlying machinery was reusable.
You nailed it. I believe this is at the heart of the problem, but this is going to be very arduous to untangle.
My suggestion would be to separate Gradle-core functionality (plugins, DSL, generic model-space management, dependency management, etc.) from what are user visible plugins. And when I say user-visible, I mean visible to the Gradle user and to plugin developers (e.g., some software model plugins that other plugins use). I know this is a long-term request (Gradle 6?), but I think it will really improve Gradle’s prospects in the long road.
Nailed it again. I cannot make a single promise for when we do something like this, but I want you to know we have been talking about doing this exact thing for a few months at least. Furthermore, we have identified some quick wins here and I expect you won’t have to wait until Gradle 6 to see them.
Wow that is a long response already. If I missed addressing something, could you please reiterate it so we can make sure it didn’t get missed? We will continue work on the short-term items above.