This message was deleted.

Try https://github.com/autonomousapps/dependency-analysis-gradle-plugin.

that's awesome

Im curious, how should it decide when to recommend

api

and when

compileOnlyApi

?

That's probably a good question... 😂, I'm actually not sure I know the answer to that. I'm not sure how it does what it does now so... Depending on how it works now... If I'm using for example a nullable annotation that is mimicking the old JSR 305 API... That's a type annotation and if you're looking at the annotation you can tell it's a type annotation. Those have to be written a certain way, also I believe annotations define whether or not they're available at runtime. Basically JSR 305 is always going to be a compile only API dependency. Error prone as far as I know is only used for a compiler plug-in, thus its annotations would also only ever be compiled only API. I wouldn't expect it to match those specifically but I suspect that if you were doing enough introspection on those annotations that are imported you could actually say that that dependency was used in a compile only way. That all assumes that it works in a way that could actually do that.

I think you confuse

compileOnlyApi

with

compileOnly

.

So it seems that when you decorate things with these annotations that the consumer of these things also ends up needing access to them to compile. So I'm not actually confusing it I have actually seen compilers and warnings when the downstream doesn't have access to that jar because they're on public methods Also those annotations are never needed at run time. Only the compiler cares about them.

As for the other cases, the plugin analyses your code / classes. And based on that it recommends on where something should be. For example if something is in your public API (parameter types, return types, super types, ...) it should go to

api

. And for example If something is only used in private API or method implementations it should go to

implementation

. And if something is nowhere used, it should be removed, or maybe sent to

runtimeOnly

for example.

Really then how do you expect non-null to work? When the compiler downstream then determines if it's safe to call your API without null checks

I cannot imagine where you would need to put an annotation to

compileOnlyApi

Maybe I'll come up with an example tomorrow

Which compiler?

No promises

Is that the name of the compiler?

The Java compiler with something like the error prone plug-in

The Java compiler does not care about nullability as Java does not have that concept. I don't know the "error prone plug-in". But from what you say I can guess what it does.

You are familiar with type annotations right? Which is not the same as most annotations you work with

But in my opinion no library author should care about downstream projects that use "obscure" compiler plugins. If a downstream project wants to use it, it should imho also make sure the necessary annotation jars are present on the compile classpath. 🙂

I don't know man... I'll see if I can't come up with an example for you tomorrow

Which died unfortunately.

It did and yet the null safety has lived on in several projects

👋

on a related topic, can this plugin, or perhaps a related one, use the same information to generate a semantic version? if it knows how my ABI changed then it could in theory create one

That's out of scope of that plugin. It also does not know how things changed, it just knows what the current state is. I don't say it couldn't by letting you specify two paths or having a file for persisting last state or whatever, just saying it does now currently know the difference. And I think this is out of scope of that plugin. Iirc it provides the information it gathered for further processing, so you could maybe knit something around that if there is not something that does already. Besides that, I guess there is also some tool to determine semver changes, but I don't know them. I just usually increase the version accordingly right when doing that breaking change or adding that additional feature. But I'm sure there are tools or plugins for that already that either warn you that you need to increase the version (my preference), or calculate the version dynamically from that information.