"Property '...' is not annotated with an input or output annotation..." warning

[green-green-avk]

It makes no impact. Just for information.

> Task :app:gatherReleaseRawStrings
Property 'gatherRawStringsAction' is not annotated with an input or output annotation. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0.

> Task :app:gatherReleaseStringTemplates UP-TO-DATE
Property 'gatherTemplatesAction' is not annotated with an input or output annotation. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0.

> Task :app:resolveReleasePlaceholders UP-TO-DATE
Property 'resolvePlaceholdersAction' is not annotated with an input or output annotation. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0.

[LikeTheSalad]

This is very interesting, I wasn't aware of this deprecation. Thanks for letting me know about it :) I'll address it for the next release.

Btw, I'm curious about the previous issue you've found regarding the "tools" prefix on XML, I could see it on an email I got from Github. I think you found an interesting issue there as well, which most likely is related to the fact that I configured the plugin so that, the resolved strings contain the exact same parameters as the template ones. But based on your example, I think that maybe not all of them should be passed to the resolved strings, or at least not the "tools" ones. So I think I'll add that change as well into the next release.

Cheers,
Cesar.

[green-green-avk]

Actually it was about https://developer.android.com/studio/build/shrink-code.html.
tools:discard and tools:keep must be in <resources>, not <string> (so, my mistake).
However finally I found the whole resource shrinking functionality broken somehow in my build environment independently of your plugin.

Though it would be good to have some additional attribute to exclude templates unneeded after substitution from a resulting resource set. Just to have cleaner debug builds.

[LikeTheSalad]

I see, thanks for your detailed response. In that case, I guess I won't be removing the params for now. Regarding your idea of making it configurable, it sounds good though so far I don't have a clear view of how it could be implemented, and also, there doesn't seem to be a need for it on a real use case. So I won't discard it, but I'll give it some time just to see what use cases may appear regarding it in the future and then take them as reference for an appropriate API.

Thanks again for your feedback,

Regards,
Cesar.

[LikeTheSalad]

Hi @green-green-avk - this issue should be fixed in the new version 1.2.2. Thanks again for your feedback!

Regards,
Cesar