Extension: Add providers overload

[hfhbd]

Use-case:
We want to set the allowed SPDX ids based on another task/file input (from our internal OSS tool), so it should support a provider overload to support CC.

Question: Should we add providers overloads for all possible inputs?

We could switch to Property inputs only and also remove the interface/expose the Gradle collections directly . This would be a breaking change but adds the overloads for free (and also allows more use-cases for other users).

Adding all overloads manually would keep source compatibility but is annoying.

[JakeWharton]

What would it look like if the collections were exposed directly?

Something like

licensee {
  allowed.add("Apache-2.0")
}

?

[hfhbd]

Yes, exposing the collections would be my favorite design too, but what about allowedUrls, allowedDependencies and ignoredDependencies?

// kotlin
licensee {
  val allowed: SetProperty<SpdxId>
  allowed.add(SpdxId.MIT)

  val allowedUrls: NamedDomainObjectContainer<AllowedUrl>
  allowedUrls.register("https://example.com/license.html") {
    it.reason.set("is Apache-2.0")
  }

  val allowedDependencies: NamedDomainObjectContainer<AllowDependency>
  allowedDependencies.register("asdf:asdf:0.0.1") {
    it.reason.set("foo")
  }

  allowedDependency(libs.asdf) { // custom function
    it.reason.set("foo")
  }
  allowedDependency("asdf", "asdf", "0.0.1") { // custom function
    it.reason.set("foo")
  }

  val ignoreDependencies: NamedDomainObjectContainer<IgnoreDependency>
  ignoreDependencies.register("asdf:asdf") {
   it.reason.set("asdf")
   it.transitive.set(true)
  }
  ignoreDependencies.register("asdf") {
   it.reason.set("asdf")
   it.transitive.set(true)
  }

  violationAction.set(ViolationAction.FAIL)
  unusedAction.set(UnusedAction.LOG)
}

With Groovy, it and set would be not needed, as always.

And I also think, if we break api, we could also generate a sealed class at build time:

// Auto-generated by Gradle :generateSpdxID from json file
sealed class SpdxId(val id: String, vararg val urls: String) {
  data object MIT : SpdxId("MIT", "")
  ;

  companion object {
    fun getById(id: String): SpdxId? = when(id) {
      "MIT" -> MIT
      else -> null
    }
    fun getByUrl(url: String): SpdxId? = when (url) {
      else -> null
    }
  }
}

[JakeWharton]

I think that could be a regular enum, which your semicolon leads me to believe you may have also thought of.

I'm unsure as to whether we should do a 2.x for this, or just evolve the API over a few versions and slowly deprecate and hide the old things.

[hfhbd]

Yes, I did but you can't override valueOf using the id and having valueOf and getById is confusing IMHO.

I am okay with both.

[JakeWharton]

Right, makes sense. We can probably just do a single class, though, and vals on the companion + @JvmStatic to get at the constants. I don't want 600 subtypes.

[hfhbd]

What's wrong with the 5316 lines of code? :D