Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add android library subproject dependencies to the report #134

Merged
merged 2 commits into from
Dec 30, 2020

Conversation

mkubiczek
Copy link
Contributor

@mkubiczek mkubiczek commented Dec 22, 2020

For some reason dependencies that come from android library subproject were not collected. There must be something different between java-library and com.android.library plugins. I observed though that all the dependencies can be found in xxxRuntimeClasspath configuration so I used that one instead.
This works for my setup and for all the existing tests. But gradle dependency resolution is not my area of expertise so I would appreciate a review of this change.

…ows/129-update-readme

jaredsburrows#129 - update readme to include correct maven repositories
@ened
Copy link

ened commented Dec 22, 2020

@mkubiczek fantastic - can you please share instructions on how to integrate a pre-release build of this PR into a project to test things out?

@mkubiczek
Copy link
Contributor Author

mkubiczek commented Dec 22, 2020

@ened
Yes I actually did it myself so here you go:

  1. Clone my fork of this repository and switch to the branch dev/mkubiczek/67
  2. Deploy the plugin to your local maven repository ./gradlew publishToMavenLocal
  3. In your project's settings.gradle put this at the very top to tell gradle where to find plugins
pluginManagement {
    repositories {
        mavenLocal()
        gradlePluginPortal()
    }
}
  1. Change the plugin version you use to the one deployed to your local maven
plugins {
    id 'com.jaredsburrows.license' version '0.8.90-SNAPSHOT'
}

And last but not least. Please share your feedback ;)

configurationSet.add(configurations.getByName("${flavor.name}Implementation"))
}
}
configurations.find { it.name == "${variant}RuntimeClasspath" }?.also {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is much cleaner, we no longer need to check for any "special" flavors?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what do you mean by "special" flavors. This is based on my observations that all the dependencies can be found in ${variant}RuntimeClasspath configuration, including subproject dependencies which were missing in the other ones. I've seen there are some tests for flavored builds and since they have passed I assumed we should be fine.

Actually I've seen Google is doing it bit differently in their oss licenses plugin. Instead of specifying configuration that should be taken into account in license generation, they're taking all the configurations and excluding only some of them like the ones that cannot be resolved or tests. Not sure which approach is better though.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok thanks. I did not know about that plugin.

Copy link
Contributor Author

@mkubiczek mkubiczek Dec 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried that plugin but it has its flaws. Eg it cannot only be applied to a project of type com.android.application but not when it's com.android.library which is my use case.

project.dependencies.add(pomConfiguration, gav)
)
set.resolvedConfiguration.lenientConfiguration.allModuleDependencies.forEach {
if (it.configuration == "runtime") {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why only runtime?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again this was based on my observations that some dependencies like 'runtimeElements' couldn't be resolved due to some ambiguity. But after thinking more about it I'm not convinced to this check. I am not sure if there can be other configurations besides 'runtime' that are fine as well. So I changed the approach based on what google is doing in oss license plugin. Please check the fixup.

@jaredsburrows
Copy link
Owner

Does this PR not affect other "subproject" tests I already wrote in this project?

@mkubiczek
Copy link
Contributor Author

Does this PR not affect other "subproject" tests I already wrote in this project?

I only added extra test for android multimodule project with android module (as there was only one with java-library). I didn't change anything in existing tests so I guess they should be fine.

} else {
resolvedArtifacts.addAll(resolvedDependency.allModuleArtifacts)
}
} catch (exception: Exception) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename exception to e?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

resolvedDependencies: Set<ResolvedDependency>
): Set<ResolvedArtifact> {

val resolvedArtifacts = HashSet<ResolvedArtifact>()
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you make this hashSetOf?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@jaredsburrows
Copy link
Owner

@mkubiczek Doesn't this plugin already support subprojects? For example, here is a test I wrote a while ago - https://github.com/jaredsburrows/gradle-license-plugin/blob/master/src/test/groovy/com/jaredsburrows/license/LicensePluginAndroidSpec.groovy#L832.

@mkubiczek
Copy link
Contributor Author

@mkubiczek Doesn't this plugin already support subprojects? For example, here is a test I wrote a while ago - https://github.com/jaredsburrows/gradle-license-plugin/blob/master/src/test/groovy/com/jaredsburrows/license/LicensePluginAndroidSpec.groovy#L832.

It works when the subproject is of type java-library but not when it is com.android.library.

@jaredsburrows
Copy link
Owner

@mkubiczek Thanks! Can you fix/update this PR based on my last 2 previous comments and I can merge this?

@jaredsburrows jaredsburrows merged commit 204f6da into jaredsburrows:master Dec 30, 2020
@jaredsburrows
Copy link
Owner

Thanks!

@mkubiczek
Copy link
Contributor Author

mkubiczek commented Dec 30, 2020

@jaredsburrows Are you going to publish new version of the plugin in the coming days?
Edit: I see now there should be a snapshot available already.

@jaredsburrows
Copy link
Owner

Sure!

@jaredsburrows
Copy link
Owner

Done!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants