https://bsky.app/profile/andresalmiray.com/post/3mq2xbtlatc2e yet again

Well, getProperties is mutable and uses parent lookup if the property is not found on the current project breaking project isolation. https://docs.gradle.org/current/userguide/upgrading_version_9.html#deprecated_get_properties

And PI is experimental, so yes, any patch version can introduce breaking changes, that's the price you pay for using an experimental feature. Even for an incubating one of would be acceptable. Without breaking changes, no evolution.

I read about isolated project and I understand why

getProperties

is a problem in that case. But really, the issue is more like a few years ago when API was changing so regularly it was difficult to maintain a build. I already spend too much time on the build that would spend on other matters.

He hates it because he worked for them I guess 😄 Breaking changes were always only in major releases and always with a deprecation cycle. So to just maintain a build I never had real problems, unless I wanted to do things differently. 🤷‍♂️

He hates it because he worked for them I guess

😰

Delegate properties are going away. What else?

Yeah, well, not everyone agrees with every decision, I also think this is a bullshit decision. But then on the other hand you have the same people that complain that they are removed complaining about having multiple ways to do the same thing which is exactly the opposite. 🤷‍♂️

Yeah this balance is hard to get, but removing public APIs is hard sell in general. The JDK team still have the very bad

Date

for a reason. I stumbled on this one as well, so not there yet, but who knows for Gradle 10 : github.com/gradle/gradle/issues/38434

The JDK team

And had very slow evolution over very long timespan. Gradle has a clear deprecation strategy that makes sense.

I stumbled on this one as well, so not there yet, but who knows for Gradle 10 :

I don't think

Task.getProject

will or should be deprecated. You must not use it at execution time with CC on and that indeed is already deprecated. But you can use it just fine without CC, or at configuration time like when initializing properties of the task and so on.

You must not use it at execution time with CC on and that indeed is already deprecated.

That I know. But it can follow the same path as other APIs just to prevent use.

And even if they deprecate

Task.getProject

, you can just

@Inject

the

Project

instance and use that just the same, so the deprecation would imho be quite useless. Except of eradicating another case of "two ways to do it"

With CC, at runtime the tasks are deserialized from the cache. Ideally, the TaskAction would not be a method of the task, but a separate class without access to configuration time APIs, like Project. But the core problem is the different design choice of Gradle 1.0 and Gradle nowadays. In the past, a task could access everything at runtime, but with CC, access is limited. Restricting a flexible system is always hard.