Breaking API change in 7.6: MinimalExternalModuleDependency interface adds lots of methods

[yogurtearl]

starting with 7.6-rc-1, MinimalExternalModuleDependency which is a public interface, now extends ExternalModuleDependency

This adds a lot of methods to the Minimal interface...

This will fail the build or fail at runtime for implementations of the MinimalExternalModuleDependency interface.

Build time error would look like this:

e: /Users/me/src/MyFile.kt: (129, 9): Object 'MinimalExternalModuleDependencyNullObject' is not abstract and 
does not implement abstract member public abstract fun getGroup(): String defined in
 org.gradle.api.artifacts.MinimalExternalModuleDependency

If plugins implement MinimalExternalModuleDependency they will fail at runtime.

Rather than change the public interface MinimalExternalModuleDependency, could you instead make a new NotVeryMinimalExternalModuleDependency ?

[rpalcolea]

Good catch!

I wondering if this falls into the @Incubating contract of things potentially changing until it is stable though hehe

Following this now!

[yogurtearl]

MinimalExternalModuleDependency is not marked as @Incubating

And if MinimalExternalModuleDependency has everything in ExternalModuleDependency plus 2 extra functions... Then minimal in the name is misleading. :)

[rpalcolea]

oh you are right! well definitely a breaking change :(

[yogurtearl]

Anyone trying to implement a custom impl of the VersionCatalog interface, will need to implement MinimalExternalModuleDependency for this method:

Optional<Provider<MinimalExternalModuleDependency>> findLibrary(String alias);

[yogurtearl]

MinimalExternalModuleDependency is marked with @HasInternalProtocol ...

but that is HasInternalProtocol is not visible from the javadoc, so not sure how anyone would know about that unless they read the source code. 🤔
https://docs.gradle.org/7.6-rc-3/javadoc/org/gradle/api/artifacts/MinimalExternalModuleDependency.html

Also, using @HasInternalProtocol on an interface MinimalExternalModuleDependency which is used in VersionCatalog, while VersionCatalog does not have @HasInternalProtocol, is also confusing.

[eskatos]

Thank you

This issue needs a decision from the team responsible for that area. They have been informed, response time may vary.

[yogurtearl]

@eskatos given that this is a breaking API change should it be marked for milestone 7.6, so it can be decided before that release?

IF they decide to fix, it should be fixed before a release. :)

[eskatos]

Good point, done!

[ljacomet]

Hi @yogurtearl, we have decided to go ahead and do the 7.6 release with these breaking changes. The main motivation is the new type safe dependency block for test suites, that we plan to make available in more places ... and maybe replace the project level dependencies one at some point.

Ideally, the above changes should have taken in consideration changes to public API interfaces, but that was missed. Designing an evolution instead of a total breaking changes was a difficult challenge, so we will keep this more constrained breakage.

I filed #22848 to improve the situation about types open for extension.

[yogurtearl]

Thanks for the response :)