gradle-6 compat

[masc3d]

resolves #69

[dlew]

I don't really have time to do an in-depth review this week, but it looks like a much further-reaching PR than just fixing #69. Removing source set support, for example, is a backwards-incompatible change and I wouldn't remove it we absolutely have to in order to support Gradle 6.x.

[masc3d]

except for compat, why would you want to keep it around / what's the use case

[masc3d]

breaking change is rather minor and it will make maintenance easier now and in the future.
you can verify via PluginTest.testRasterize

[dlew]

Up until this point, the only way to define where the SVGs go is by using source sets. Changing its location is a breaking change for everyone using the plugin.

Additionally, there are reasons for having it linked to source sets: for apps that have multiple build configurations, source set support is vital. That way you can include one set of SVGs for, say, a debug build vs. a release build.

[masc3d]

set of SVGs for, say, a debug build vs. a release build.

why would someone ever want to do this?

[masc3d]

anyway, since I (and no project I have ever seen or could think of) would ever need this, so I rather stick with my fork, which will also be more robust considering future gradle releases.

[dlew]

set of SVGs for, say, a debug build vs. a release build.

why would someone ever want to do this?

I can think of a few reasons:

1. Apps which use a different launcher logo for dev vs. release (I've seen this quite a bit actually).

2. White label apps where it's the same core codebase made to look like multiple different brands.

3. Apps which withhold features in certain builds, and thus the resources that come along with them.

anyway, since I (and no project I have ever seen or could think of) would ever need this, so I rather stick with my fork, which will also be more robust considering future gradle releases.

If this version of Victor does not work for you, then I am glad you can make your own - I wish you the best going forward.

[masc3d]

despite there's alternative ways to accomplish this, you have a point there.

but like you, I don't have much time to spare for niche features, while gradle-6 compat is much more important, especially considering that agp-4 requires it.

[masc3d]

as you may remember, plugin is broken because source set support was never properly implemented to begin with.

        // We can either implement our own SourceDirectorySet (which is a PITA)
        // or we can suffer the lesser pains of accessing internal APIs

so I believe it's better to remove it for now in favor of a functional plugin and re-implement it later when there's time.

[dlew]

SourceDirectorySet having no implementation was a real thorny thing in Gradle for many years, I'm glad to see it's been fixed.

Here's how it looks now; it was fairly easy to keep source set support while upgrading to Gradle 6: ba0d29a

Closing this in favor of work on #71.

[masc3d]

looks good. I wasn't aware of it.