binary-compatibility-validator icon indicating copy to clipboard operation
binary-compatibility-validator copied to clipboard

Avoid using project.name for ignored projects check

Open Goooler opened this issue 1 year ago • 4 comments

  • Closes #16.
  • Closes #257.

The project's name is not necessarily unique within a project hierarchy. You should use the getPath() method for a unique identifier for the project.

See https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html#getName().

Goooler avatar Jul 24 '24 10:07 Goooler

2 tests failed, seems they are related to #261.

kotlinx.validation.test.MultiPlatformSingleJvmTargetTest > testApiCheckFails FAILED
    java.lang.AssertionError at MultiPlatformSingleJvmTargetTest.kt:84


* What went wrong:
Execution failed for task ':jvmApiCheck'.
> API check failed for project :.
  --- /private/var/folders/_8/1blqtzds07g8p1zsy_t8_lsc0000gn/T/junit8648894727794548688/api/testproject.api
  +++ /private/var/folders/_8/1blqtzds07g8p1zsy_t8_lsc0000gn/T/junit8648894727794548688/build/api/testproject.api
  @@ -1,9 +1,9 @@
  -public final class com/company/subsub2/Subsub2Class {
  +public final class com/company/subsub1/Subsub1Class {
   	public fun <init> ()V
   	public final fun getProp ()I
   }
   
  -public final class com/company/subsub1/Subsub1Class {
  +public final class com/company/subsub2/Subsub2Class {
   	public fun <init> ()V
   	public final fun getProp ()I
   }
  
  You can run :::apiDump task to overwrite API declarations
kotlinx.validation.test.MultipleJvmTargetsTest > testApiCheckFails FAILED
    java.lang.AssertionError at MultipleJvmTargetsTest.kt:99


* What went wrong:
Execution failed for task ':jvmApiCheck'.
> API check failed for project :.
  --- /private/var/folders/_8/1blqtzds07g8p1zsy_t8_lsc0000gn/T/junit8084192555986675768/api/jvm/testproject.api
  +++ /private/var/folders/_8/1blqtzds07g8p1zsy_t8_lsc0000gn/T/junit8084192555986675768/build/api/jvm/testproject.api
  @@ -1,9 +1,9 @@
  -public final class com/company/subsub2/Subsub2Class {
  +public final class com/company/subsub1/Subsub1Class {
   	public fun <init> ()V
   	public final fun getProp ()I
   }
   
  -public final class com/company/subsub1/Subsub1Class {
  +public final class com/company/subsub2/Subsub2Class {
   	public fun <init> ()V
   	public final fun getProp ()I
   }
  
  You can run :::apiDump task to overwrite API declarations

Goooler avatar Jul 24 '24 10:07 Goooler

@Goooler thanks for taking care of the problem!

While paths are better for identifying projects, there's already plethora of projects using BCV and relying on ignoredProjects property. We can follow the suggestion from #16 on how to preserve compatibility, and treat each of ignoredProjects values either as a project name, or as a project path depending on the first character (assuming that only the project path could start with :). Additionally, it would nice to print a warning for every ignoredProjects entry that is no a project path (so that users gradually migrate to project paths and we can drop project names support in the future).

fzhinkin avatar Aug 19 '24 17:08 fzhinkin

This might be a breaking change, but it would be worth breaking in the next release, users who want to update should update their ignoredProjects instead of treating it as a warning.

Yeah, we can remove : prefixes for path checks, but there will be more complex cases for us to treat, such as the root project, path as :. I suggest we should retain the original paths for checks.

Goooler avatar Aug 19 '24 23:08 Goooler

This might be a breaking change, but it would be worth breaking in the next release, users who want to update should update their ignoredProjects instead of treating it as a warning.

It's better to provide a smooth and graceful migration path when possible. Those who already use ignoredProjects are fine with how it works. They'll have to switch to paths at some point, but it should not block them from updating a BCV. In some cases, a breaking change is required to fix a problem that could not be fixed otherwise. But in case with path/name checks, behavior could be updated smoothly, without breaking what already work.

We just need to transform

if (project.path in extension.ignoredProjects) { ... }

into something like

fun Project.isIgnored(extension.ignoredProjects: ApiValidationExtension) = path in extension.ignoredProjects || name in extension.ignoredProjects

if (project.isIgnored(extension)) { ... }

And also update Project.validateExtension to check that ignoredProjects values are either existing names, or paths (printing a warning for names along the way).

fzhinkin avatar Aug 20 '24 16:08 fzhinkin

As part of the migration of separate BCV functionality to Kotlin Gradle Plugin, the addition of new features to a separate plugin has been discontinued.

shanshin avatar Jun 16 '25 11:06 shanshin