Support packaging and extracting protos in Android aar (take 2) #443
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Something was messed up in #440, which changed to have an ExtractIncludeProto task for each source set in Android build. However, ExtractIncludeProto tasks need to match dependency variants before pulling them in (this is configured by configurations created by the Android plugin, so the problem doesn't exist in
protobuf
dependencies and ExtractProto tasks). So it does not work if ExtractIncludeProto tasks are per source set basis, the build will not be able to determine the right variant of dependencies.The original approach works. That is, getting dependencies from
variant.compileClasspath
for each variant. So this makes the way of extracting included protos different for Java projects and Android projects:compileProtoPath
configuration (which inherits fromimplementation
andcompileOnly
) as SourceSets are compilation units for Java projects.compileClasspath
as variants are compilation units for Android projects.So we will not create
compileProtoPath
configurations for Android source sets.We could change Java projects to extract included protos from each SourceSet's
compileClasspath
with a similar approach to filter dependencies with a RESOURCES ArtifactView. With that, we can get rid of thecompileProtoPath
configuration, and we would no longer need the extra operation to put main sourceSet's proto into test sourceSet:protobuf-gradle-plugin/src/main/groovy/com/google/protobuf/gradle/ProtobufPlugin.groovy
Line 394 in 5291031
Majority changes in this PR is for adding test coverage for consuming protos defined in Android library dependencies.
testProjectAndroidLibrary
is a standalone Android library project that provides some proto definition.testProjectAndroidDependentBase
is similar totestProjectAndroidBase
but depends ontestProjectAndroidLibrary
and its proto definitions imports protos defined intestProjectAndroidLibrary
. It covers that for all of application/unitTest/androidTest variants (#447 is created to do the same coverage for existing tests that covers Android applications consuming protos from Java projects, it's important to be covered that test variants can still import protos from dependencies of the variant-under-test).Dependencies pulled from variant's compileClasspath has a view with "jar" attributes, so they include packaged protos.