Add support for Typesafe Project Accessors

[ivanalvarado]

Description

• Adds support for typesafe project accessors through extension configuration
• Addresses: Use Generated Project Accessors #844

Usage

dependencyAnalysis {
   projectProperties {
     // (Optional) Specify whether to print advice in typesafe-project-accessors format
     // Example: project(":foo:bar:baz") vs. projects.foo.bar.baz
     useTypesafeProjectAccessors(true)
   }
 }

Example

If this property is set to true, the console report will output:

Existing dependencies which should be modified to be as indicated:	
  implementation projects.account.impl (was api)
  implementation projects.account.public (was api)	

instead of

Existing dependencies which should be modified to be as indicated:	
  implementation project(':account:impl') (was api)	
  implementation project(':account:public') (was api)

[autonomousapps]

Thank you for this contribution!

I feel like this value should simply default to true if the project is using typesafe project accessors. I don't know why we'd want it configurable. Is there a way to just detect that and enable this output automatically in that case?

[autonomousapps]

Not sure about this method name or using this as the access point.

[ivanalvarado]

Yeah, I wasn't 100% confident on the name either. I mainly didn't want to piggy back on one of the existing handlers as it didn't really "fit" into any of them. I'm in between "GradleFeature" and "ProjectFeature" because in order to enable this "feature", one has to specify:

enableFeaturePreview("TYPESAFE_PROJECT_ACCESSORS")

I feel like this value should simply default to true if the project is using typesafe project accessors. I don't know why we'd want it configurable. Is there a way to just detect that and enable this output automatically in that case?

My initial goal was to autodetect if the project was using type-safe project accessors. I dug into the Settings object API, but could not find any indicators on whether or not this feature was enabled. I asked in Gradle Community Slack and the feedback was "there is no way to detect". The suggestion was to expose a configurable boolean through the Extension. (Wish I could grab a reference to the convo, but the thread is older than 90 days and not discoverable anymore 😞)

[autonomousapps]

I would be ok with exposing this new property in the top-level DSL object (dependencyAnalysis).

If you file (or discover) an issue for auto-detecting this, please link it to this PR.

[autonomousapps]

Gradle has confirmed to me directly that there is no API to detect this. Nevertheless I think it would be a better user experience if it were automatic. How do you feel about parsing the settings script with regex, looking for that specific line that enables the feature?

I also wonder if we can inspect the buildscript classloader for a specific jar or class file, where these accessors would live?

[autonomousapps]

I've thought about this some more and decided that, since this is an experimental gradle feature, I am in favor of the current approach of requiring users to opt-in. I don't want to tie DAGP to some hacky approach to detecting it that is likely to change at any time.

That said, let's move the property to the top level dependencyAnalysis extension. Thanks!

[ivanalvarado]

Sounds good. Yeah, my worry was that Gradle would remove the need for the enableFeaturePreview syntax once typesafe project accessors were promoted to stable.

I'll go ahead and move the property to top level.

[autonomousapps]

Same comment as earlier, unsure about this.

[autonomousapps]

Does this regex work in all possible cases? Does gradle only permit ASCII characters or is a wider character range available?

[ivanalvarado]

Good catch, will follow up on this.

[alllex]

Ideally, the error should provide the suggestion compatible with the corresponding build script DSL, i.e. Groovy vs Kotlin.

For Kotlin DSL it should be:

Existing dependencies which should be modified to be as indicated:	
  implementation(projects.account.impl) (was api)
  implementation(projects.account.public) (was api)	

[alllex]

Given that it's not possible to detect whether type-safe accessors are enabled and that it might not be easy to detect the correct DSL, I suggest adding those as formatting options in the plugin configuration.

This will already be immediately useful for projects using the plugin because the errors will provide a better UX.

On that note, even if the type-safe accessors become stable and are ON by default, the users might still prefer the stringy project coordinates. This means they would still prefer to see the errors displayed in the format matching theirs. Thus, the plugin would still require configurability in this aspect.

[autonomousapps]

Given that it's not possible to detect whether type-safe accessors are enabled and that it might not be easy to detect the correct DSL, I suggest adding those as formatting options in the plugin configuration.

The plugin currently does detect whether the project is using Groovy or Kotlin based on the file extension (.gradle or .gradle.kts), and formats the output accordingly. All the tests here use Groovy DSL for historical reasons.

[eygraber]

Is there anything that still needs to be done here?

[autonomousapps]

At least it needs to be rebased and the conflicts fixed.