-
Notifications
You must be signed in to change notification settings - Fork 160
Reintroduce buildinfo computation parallelism #275
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
Reintroduce buildinfo computation parallelism #275
Conversation
Doing so in non-Gradle-managed threads is in theroy unsafe, and Gradle logs a warning about that. To work around this: - use internal Gradle APIs to query only configuration in state ARTIFACTS_RESOLVED - Silence Gradle's warning, as what we do is actually read-only, and safe without locking the project state
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the pull request, @facewindu!
Unfortunately, I'm still getting the following errors:
java.lang.IllegalStateException: The configuration XXX was resolved from a thread not managed by Gradle
I tested it with this project, using the following configuration:
repositories {
mavenLocal()
jcenter()
}
dependencies {
classpath(group: 'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '4.9.x-SNAPSHOT')
}
Also - We have to consider Gradle 4 support.
@@ -366,16 +413,6 @@ public boolean apply(@Nullable Dependency input) { | |||
return dependencies; | |||
} | |||
|
|||
private ResolvedConfiguration getResolvedConfiguration(Project project, Configuration configuration) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without it I'm getting the following error with Gradle 4:
java.util.concurrent.ExecutionException: java.lang.NoSuchMethodError: org.gradle.api.publish.maven.internal.publisher.MavenNormalizedPublication.getAdditionalArtifacts()Ljava/util/Set;
Hi @yahavi |
@yahavi I've been looking into this issue and a couple of things are blocking me. You mention that it should work with Gradle 4, but the example project without any changes uses Gradle 4 and pulls the latest 4.x version from jcenter ( Secondly, if I try to run that example project with Gradle 5.6.4 and @facewindu's changes, I can't reproduce the issue reported above ( |
@ghale Thanks for looking into this.
And if something is not clear yet, please don't hesitate to ask more questions. |
Ok, I was just using the wrapper in the example project, which uses 4.3.1. I get the same error you reported now. Am I correct in assuming that Gradle 4 compatibility is limited to the latest 4.x version and not all 4.x versions? And I also get the Thanks for the clarification. |
I've submitted a separate PR (#287) which addresses the issues reported above and supersedes this PR. |
closing this as superseded |
Discussing it internally within Gradle, this PR reintroduces parallel computation of the build infos.
Doing so in non-Gradle-managed threads is in theory unsafe, and Gradle logs a warning about that.
To work around this:
- use internal Gradle APIs to query only configuration in state ARTIFACTS_RESOLVED
- Silence Gradle's warning, as what we do is actually read-only, and safe without locking the project state
This effectively replaces #270