Provide convenience annotation to exclude classes from dependency analysis report

[marcgs]

trafficstars

Is your feature request related to a problem? Please describe. We created an ExcludeFromDependencyAnalysisReport convenience annotation, to exclude certain classes from the analysis report (see plugin configuration).

It would be helpful to have such a convenience annotation from a library that works out of the box.

Describe the solution you'd like Provide an annotation to exclude classes from dependency analysis reports. The default configuration should pick this annotation and exclude marked classes.

[autonomousapps]

Thanks for the feature request. Can you clarify what you mean by "exclude classes from dependency analysis reports"? Is this on the consumer (project under analysis) or producer (dependency) side?

Do you mean, if a class has this annotation, consider it as if it had been added to one of the exclude() methods in the dependencyAnalysis DSL? Or something else?

[marcgs]

Thanks for the feature request. Can you clarify what you mean by "exclude classes from dependency analysis reports"? Is this on the consumer (project under analysis) or producer (dependency) side?

Do you mean, if a class has this annotation, consider it as if it had been added to one of the exclude() methods in the dependencyAnalysis DSL? Or something else?

Let me explain our use case a bit more in detail:

• The AuthenticationRequestFilter in the auth-spi module has an "api" dependency to NotAuthorizedException in the api-core module as this exception might be thrown if the user is not authenticated.
• The exception is not declared in the throws clause, since it is a RuntimeException. This leads to the dependency plugin to (IMO wrongly) suggest:

Advice for :extensions:api:auth-spi
Existing dependencies which should be modified to be as indicated:
  implementation(project(":extensions:api:api-core")) (was api)

• We would like to exclude any class declaring NotAuthorizedException as a dependency, to prevent this suggestion. One way would be to mark this exception with a meta-annotation that excludes any suggestions related to it.

Does this help?

Note: After a closer second look it seems that the solution I suggested in the issue does not work properly, as the excludeAnnotations block in the plugin configuration is not meant for this use case. The plugin keeps bringing the suggestion to move the dependency from "api" to "implementation".

[autonomousapps]

Let me repeat your situation in my own words to verify we're on the same page. You have a method that can throw an exception but doesn't declare that it can do so. Like this:

@Override
public void filter(ContainerRequestContext requestContext) {
    if (/* some condition */) {
        throw new NotAuthorizedException();
    }
}

Where the method filter(), and the exception type NotAuthorizedException, are in different modules. You want the exception to be considered part of the ABI (api configuration) of the module containing filter().

This is not unreasonable, but impossible for the plugin to detect without some help from you. Declaring that exception in the throws clause is one such way to provide that assistance. Another way is to just tell the plugin to not report that exception module as being on the wrong configuration (as described in the wiki). The latter is admittedly very coarse-grained.

You are requesting the plugin to support a new system for understanding this situation: using Java annotations in some fashion. What remains unclear to me is if you want that annotation to function as either (1) a hint that some class, if used, must be considered part of the ABI of the consumer; or (2) if you want such annotated classes to be excluded from the report in a way similar to the mechanism the wiki describes.

Whichever way you're thinking, I need to point out that either would be something of a lift to implement and I can't prioritize it now. I am, however, open to continuing the discussion to fully understand your goals, and maybe provide pointers if you or someone else would be interested in implementing such functionality.

[marcgs]

You did not only get it right, but you explained our situation way more elegantly than I did ;-)

We would like to prevent declaring the exception as it is uncommon to do so for RuntimeExceptions and as you mentioned, excluding the whole plugin is very coarse-grained.

Both (1) and (2) seem feasible solutions to the issue. I would personally lean towards (2) if this means that by using the annotation we can exclude the module in a more fine-grained fashion (exclude the annotated class only, any other class in the same module should be treated normally). I am not sure if that is even possible as there is probably not enough information in the model to implement this logic. If this is indeed not possible, then I think (2) is the best solution for our case.