Support ktargeter targets configuration through annotations about ktargeter

[Shpota]

Thank you, I will add it once I have time.

[Shpota]

Hi,

Thank you for opening this issue.

There are a couple of solutions for this. If you have a gradle plugin, you can include the ktargeter plugin as a dependency and pass ktargeter.annotations from the code of your plugin. I am not sure about the details, I would need to research about this, but it should be doable.

Another option, as you suggested, Ktargeter may expose its own set of annotations to be used with other annotations. Or even without exposing anything, we can define a naming convention for annotations that can be used to specify which use-site target to use. For instance, if your Open API annotation has an annotation called @Setter ktargeter can move this annotation to the setter method without having to specify it in ktargeter.annotations. This is just a matter of adding an if statement similar to this one.

[dzikoysk]

There are a couple of solutions for this. If you have a gradle plugin, you can include the ktargeter plugin as a dependency and pass ktargeter.annotations from the code of your plugin. I am not sure about the details, I would need to research about this, but it should be doable.

That's not an option as it's just annotation processor + runtime library, so I'm not really integrating this with build system. I'd like to just recommend your plugin to my users, so they could use your solution directly and it would work out-of-the-box with set of rules I'd provide with my library :)

Another option, as you suggested, Ktargeter may expose its own set of annotations to be used with other annotations. Or even without exposing anything, we can define a naming convention for annotations that can be used to specify which use-site target to use. For instance, if your Open API annotation has an annotation called @Setter ktargeter can move this annotation to the setter method without having to specify it in ktargeter.annotations. This is just a matter of adding an if statement similar to this one.

We have several annotations with different meaning, so I don't think it makes much sense to try to match some kind of naming convention as it'd be slightly limiting. The perfect solution would be if there would be a standalone annotation I could use on my annotations, I feel like it'd be the most generic approach to this issue and it could be also quite useful for your users in case of their own annotations, so they can manage this functionality at sources level, not build script scope.

[Shpota]

Thank you. Let me summarize what you suggest. Ktargeter can have a meta-library exposing annotations like the following: @KtargeterSet, @KtargeterGet, and @KtargeterField. They can be used to annotate other annotations, like the ones you shared. In this case, when Ktargeter is enabled in a Gradle script, it can automatically understand what the proper targets are by inspecting if a particular annotation (OpenAPI annotation in your case) is annotated with one of the ktargeter annotations. Did I sum it up correctly or you meant something else?

[dzikoysk]

That's exactly what I'd love to see :) I wonder if it wouldn't be better to create just one annotation with array of enum values (SET, GET, FIELD), so there would be a possibility to specify multiple targets at once, because technically that could be an option too.

[Shpota]

I would say it is a matter of taste. Personally, I prefer having a single annotation per target. This way it is more concise and easier to understand. At the same time, a user can add two annotations for the case when several targets have to be handled.

[dzikoysk]

Sure, it was just a suggestion, I'm fine with both approaches :)