Open lizyxr opened 2 years ago
I have update cla but not sure how can I ask for a rescan?
Thanks Liz,
Few thoughts on my end
More thoughts:
Task :aspoet:test
com.google.androidstudiopoet.generators.ModuleBuildBazelGeneratorTest > generator applies dependencies from the blueprint FAILED org.mockito.exceptions.verification.junit.ArgumentsAreDifferent at ModuleBuildBazelGeneratorTest.kt:46
com.google.androidstudiopoet.generators.android_modules.AndroidModuleBuildBazelGeneratorTest > generator sets correct target name from the blueprint FAILED org.mockito.exceptions.verification.junit.ArgumentsAreDifferent at AndroidModuleBuildBazelGeneratorTest.kt:109
com.google.androidstudiopoet.generators.android_modules.AndroidModuleBuildBazelGeneratorTest > generator applies libraries from the blueprint FAILED org.mockito.exceptions.verification.junit.ArgumentsAreDifferent at AndroidModuleBuildBazelGeneratorTest.kt:65
com.google.androidstudiopoet.generators.android_modules.AndroidModuleBuildBazelGeneratorTest > generator sets correct android_binary rule class for Application module FAILED org.mockito.exceptions.verification.junit.ArgumentsAreDifferent at AndroidModuleBuildBazelGeneratorTest.kt:37
com.google.androidstudiopoet.converters.ConfigPojoToAndroidModuleConfigConverterTest > convert passes correct values to result AndroidModuleConfig FAILED java.lang.AssertionError at ConfigPojoToAndroidModuleConfigConverterTest.kt:109
com.google.androidstudiopoet.converters.ConfigPojoToAndroidModuleConfigConverterTest > convert result AndroidModuleConfig that has launch activity when index == 0 FAILED java.lang.AssertionError at ConfigPojoToAndroidModuleConfigConverterTest.kt:118
@lizyxr Thank you for your PR, I think this change is useful.
I'm not sure if "Dummy" prefix is actually needed. From the stand point of the Android Studio Poet, this is a legitimate jar lib dependency, since it is not responsibility of Android Studio Poet to generate the jar. If my understanding is correct, then I would suggest to remove the "dummy" prefix from everywhere and just call it "localJarLibsDependency".
I agree with Boris, it would be useful to have this functionality documented.
Thanks Boris & Nikita for reviewing! I have fixed the test, remove the prefix and add some description in README.md. Do you think we need another .md for detailed function description?
@lizyxr - thanks a lot @NikitaKozlov - please review
Added some comments
===========================================
What would be our thoughts on:
I also left a small comment about a typo. The rest - LGTM. Regarding generation of jars by ourselves - I think is might be a good idea, but outside of the scope of this PR.
Ok, once the review comments are fixed, I will merge the change. In addition will open a bug(features request) for jar generation.
I need to create a fake gradle project with a huge amount of jar libs as deps. So I create this change. I think this would be useful since it's common to encounter freeze due to a project with a huge amount of libs. And we need to create such fake project for debugging.
user can 1 dummy jar lib to module0 by using "dummyLocalJarLibsDependency": [{"moduleName": "module0", "count": "1"}]. It will make sure the dummy jar file is generated locally i.e. you can sync project without issue.