Resolver repos are not source control friendly

[bklooster]

Currently, when a plugin (such as Firebase's Unity plugin) defines its own repository for the library the resolver will create an entry in the resolver path that is user specific. This makes source control very painful because it is defined to the user's file path.

Would it be possible to manually embed only the .aar files that are in their own repository so that the mainTemplate.gradle doesn't need to be hooked up to an absolute path name? The only work around
Currently, to get around this problem, every user needs to force resolve on their machine prior to making a build. This is is very error prone. Also as part of the resolve process these files are recreated, which causes a change to appear in git due to the .meta files changing.

Any recommendations or fixes in new versions would be appreciated, thanks!

[stewartmiles]

Looks like the problem is here:

unity-jar-resolver/source/PlayServicesResolver/src/PlayServicesResolver.cs

Line 1885 in c1b77e3

"file(rootProject.projectDir.path + \"/../../\").absolutePath",

Since the code injected calculates the project path it should probably be using the unityProjectPath variable if the repo is located in the project directory.

[stewartmiles]

Oh now I'm confused, the resolver already does this here:

unity-jar-resolver/source/PlayServicesResolver/src/PlayServicesResolver.cs

Line 1894 in c1b77e3

"(unityProjectPath + \"/{0}\")",

[stewartmiles]

@bklooster which version are you using?

[bklooster]

I just tested this with the latest I could find 1.2.118.0 and it is still happening.

Thank you for the code link.

Looking at the code you have a mechanic that says only do this relative path if export project is disabled. Our build process exports a Google project, and doesn't use the built-in gradle build system because company/project specific reasons (basically, we do some post-build modifications to the studio project similar to what we do with the xcode project) which needs to have the android studio project exported.

The exported project though is in the same relative path as the unity project. However, if the project is moved obviously the local repo will break. Is there a better route for this that you can think of?

There is also still a problem with the dirtying of the meta files every time that the resolver triggers.

[stewartmiles]

@bklooster how are you hooking the Android project export in Unity? I'm wondering whether the Android Resolver could copy the local maven repos into the exported project as well that way the paths could simply be relative to the exported gradle project in all cases.

[stopiccot]

I really suggest to move firebase-xxxx-unity aars to maven instead of continuing to maintain these hacks. Would be so simple, straightforward and version control friendly.

[stopiccot]

I've also noticed that running resolution creates m2repository/com/google/firebase/firebase-app-unity/6.1.1/firebase-app-unity-6.1.1.aar next to m2repository/com/google/firebase/firebase-app-unity/6.1.1/firebase-app-unity-6.1.1.srcaar and this aar copied by Unity to libs folder of exported android studio project.

[stewartmiles]

@stopiccot yes the copy to an aar is intentional, see https://github.com/googlesamples/unity-jar-resolver/blob/master/source/PlayServicesResolver/src/GradleTemplateResolver.cs#L87

As I mentioned we have no intention of publishing this to public Maven, instead TBH it would be nice to go the other way and support redistribution of Maven repo for all artifacts that plugins require, at the moment the build process is not friendly to hermitic builds or build servers that are locked down with limited internet access.