I regenerated the list of dependencies using the exact instructions in the updated projects/common/how-to-create-gradle-dependencies-list.txt file. I also verified that firefox and tor-android-service projects already have the dependencies file generated from these instructions.
I regenerated the list of dependencies using the exact instructions in the updated projects/common/how-to-create-gradle-dependencies-list.txt file. I also verified that firefox and tor-android-service projects already have the dependencies file generated from these instructions.
Do we really need to bump gradle_dependencies_version? After all it's just a sorting of dependencies which should not affect the gradle dependencies themselves.
Alright. Looking at gradle-dependencies-list.txt as we have it on master results in 277 entries we need to download. Looking at the same file in your branch after sorting results in 313 entries to download. So, there is something going wrong here. If we only need 277 entries to build (TOPL) then we should take those (maybe we need even less). Either way, this needs revision.
Alright. Looking at gradle-dependencies-list.txt as we have it on master results in 277 entries we need to download. Looking at the same file in your branch after sorting results in 313 entries to download. So, there is something going wrong here. If we only need 277 entries to build (TOPL) then we should take those (maybe we need even less). Either way, this needs revision.
The resolver can download more than it actually needs at compile time. So its possible that it needs less. I can look at what's going on with the extra entries but the method used to generate the lists from the logs is different between these two lists.
I checked the method I was using in August (from the link below) and it generates 493 URLs from the logs. The program I use for downloading and creating the gradle-dependency list downloads 313. So the most recent method and the method is August match. So 313 is the correct count. 277 must have come from some earlier version that I was working in (possibly different gradle plugin/version) entirely.
So the logs to tor-onion-proxy was unique in the sense it does download the same artifact twice from two different locations. These downloads occur on different threads so I think one resolver is unaware of what the other resolver is doing.
To be able to remove these duplicates, we do need to rev the characters in each line that then match multiple fields (since artifacts with different groupIds have the same artifact name and version). So I added that to the documentation and tested it out. We are back to the 277 artifacts after this.