dependency-analysis-gradle-plugin icon indicating copy to clipboard operation
dependency-analysis-gradle-plugin copied to clipboard

Print out where in the source code specific classes are exposed in a module

Open landicefu opened this issue 2 years ago • 5 comments
trafficstars

Is your feature request related to a problem? Please describe. I don't find document mentioning how I can get more detailed messages. Sometimes it shouldn't be fixed by suggesting moving from implementation to api dependency. Instead, lots of cases are we should fix the wrong accessibility modifier or do the encapsulation better by extracting interfaces or base implementations.

The problem is if it's only telling me my module is exposing something, I need to search a lot for where it's exposed, and for some legacy modules, it can be hundreds of places.

Describe the solution you'd like Adding some parameters like "verbose" to print out more detailed information like where those dependency are exposed. The path and line number of the source file would be very helpful.

Thanks in advance.

landicefu avatar Jul 27 '23 07:07 landicefu

Have you tried the reason task?

autonomousapps avatar Aug 03 '23 04:08 autonomousapps

@autonomousapps Yes! I've tried reason task, but the format is like this (copied from your link).

./gradlew lib:reason --id com.squareup.okio:okio:2.2.2 (1)
> Task :lib:reason

----------------------------------------
You asked about the dependency 'com.squareup.okio:okio:2.2.2'.
There is no advice regarding this dependency.
----------------------------------------

Shortest path from :lib to com.squareup.okio:okio:2.2.2:
:lib
\--- com.squareup.okio:okio:2.2.2

Source: main
------------
* Exposes class okio.BufferedSource (implies api).

It only says Exposes class okio.BufferedSource, but if I want to find out where in the source I exposed BufferedSource class, I have to search for it and figure it out on my own. This may be easy for most of the projects, but for some legacy projects that misuses the visibility modifier all the time, this problem maybe more serious. There can be hundreds of usage of a simple class, and it's a pain to figure out where to fix the problem.

As I said, moving from implementation to api dependency isn't always the correct solution. When I should make changes for visibility modifiers, this plugin is still not helpful currently.

landicefu avatar Aug 08 '23 03:08 landicefu

Ok. This would probably be a useful feature for some users, but it's not something I can prioritize now given time constraints. If you or your company are interested in sponsoring it, however, please let me know and we can discuss that. Alternatively, PRs are welcome.

autonomousapps avatar Aug 08 '23 06:08 autonomousapps

Understood. I think I will find time to try contributing to this project. Thanks for your work. This is a very useful plugin! You can close this issue now if it's supposed to be.

landicefu avatar Aug 15 '23 05:08 landicefu

Off topic, for this ticket. But would it be possible to print classes that are exposed but not used by other modules?

This has probably zero value for library authors. However, in our multi module project it would be handy to find and reason classes that appears to be exposed and should not.

emartynov avatar Apr 24 '24 08:04 emartynov