Comments (11)
@bigdaz here's a repo reproducing what I'm seeing and explaining what I think should be happening https://github.com/brianmcgee/github-dependency-graph-plugin-bug
from github-dependency-graph-gradle-plugin.
Essentially, if you have a dependency of the form :-plugin-gradle: you can reasonably assume the plugin marker to be :.gradle.plugin:.
Unfortunately, I don't think it's quite this straightforward. The plugin marker artifact has:
group = "${plugin-id}"
artifact = "${plugin-id}.gradle.plugin"
version = "${version}"
This can point to a jarfile dependency with arbitrary coordinates. For example you could publish a single jarfile with coordinates com.gradle:plugins:1.0
containing multiple plugins like com.gradle.awesomeplugin
and com.gradle.otherplugin
.
I don't think there's any way to determine the plugin id given the dependency coordinates.
from github-dependency-graph-gradle-plugin.
If it's important to you, I'd be open to a PR that made it possible to retain the plugin marker artifacts via some sort of env var.
Here's where the code is:
Any PR would require test coverage.
from github-dependency-graph-gradle-plugin.
Why do you believe these dependencies are not being captured? My testing indicates that they are.
Can you please provide a project that allows me to reproduce this issue?
from github-dependency-graph-gradle-plugin.
Hi @bigdaz, thanks for responding. I'll put together a reproducer.
from github-dependency-graph-gradle-plugin.
Thanks for the reproducer. I'm not sure what's happening on your end, but when I run the exact command against that repo I do see the Spotless Gradle plugin listed in the dependencies:
![image](https://private-user-images.githubusercontent.com/179734/330966829-968dacb4-0ffc-4581-8efe-ea3bb0e6e5b7.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjM5MDg1NzQsIm5iZiI6MTcyMzkwODI3NCwicGF0aCI6Ii8xNzk3MzQvMzMwOTY2ODI5LTk2OGRhY2I0LTBmZmMtNDU4MS04ZWZlLWVhM2JiMGU2ZTViNy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwODE3JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDgxN1QxNTI0MzRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0wNGNiYzRhYzI5MzUwM2IzMGNmYWM3MTZmODA4NDg3N2RjYjZiYTRkMjU5NDEzNzkxM2VmNTRjZGNlYmUzOWFlJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.MKNjtAYVhT8uEGhZawxjHSPxEhiKGESqOBQaF105Gfw)
from github-dependency-graph-gradle-plugin.
You might find it useful to add --scan
to your invocation: the generated build scan captures all resolved dependencies and is a good way to share your results.
from github-dependency-graph-gradle-plugin.
I updated my reproducer to include the report I'm generating, which matches what you listed above. I also added a second plugin to demonstrate the issue better.
The report above shows an entry for com.diffplug.spotless:spotless-plugin-gradle:6.25.0 which is sourced from https://repo.maven.org.
But it does not include an entry for com.diffplug.spotless:com.diffplug.spotless.gradle.plugin:6.25.0 which is sourced from https://plugins.gradle.org.
Similarly, you will see in my updated example that com.github.johnrengelman.shadow:com.github.johnrengelman.shadow.gradle.plugin:8.1.1
is not included in the report.
Here is a scan report for the latest run: https://scans.gradle.com/s/iitusscge3aao
from github-dependency-graph-gradle-plugin.
The specific dependencies you mention are referred to as plugin marker dependencies. The don't contain any code, and simply help gradle resolve a plugin id to an actual plugin dependency artifact.
These are deliberately and explicitly excluded from the report: #111
Is there a reason that you want to have these included in the report? Or were you just concerned that not all plugin dependencies are reported and weren't sure which ones were missing?
from github-dependency-graph-gradle-plugin.
Ah, that makes sense.
Essentially, if you have a dependency of the form <group>:<module>-plugin-gradle:<version>
you can reasonably assume the plugin marker to be <group>:<group>.gradle.plugin:<version>
.
In answer to why I'm interested in these, I'm using the dependency report from the plugin to construct a lock file for use with Nix that allows me to construct a local maven repository containing all the build dependencies so the build can be run in offline mode within the Nix sandbox.
This was the last piece of the puzzle and it looks like I have it working.
Thanks for your help 🙏
from github-dependency-graph-gradle-plugin.
I think my immediate use case is covered, but I'm happy to look at creating a PR to capture them properly.
I'll try and find some time next week to give it a go.
from github-dependency-graph-gradle-plugin.
Related Issues (20)
- Port to kotlinx-serialization HOT 10
- handleBuildOperationTypeRaw masks failed build operations HOT 3
- `ForceDependencyResolutionPlugin` incompatible with Project isolation HOT 2
- Include Gradle version in generated dependency graph
- Exclude plugin marker dependencies from generated graph
- Exclude the github-dependency-graph-gradle-plugin from the generated graph HOT 1
- Log each resolved dependency and associated configuration path
- Incomplete dependency-graph generated on build failure
- Excluded configurations should not be resolved
- Locked and non-resolving configurations fail with an error in Gradle 7.x with a single project HOT 1
- Stale dependencies in Dependency graph HOT 8
- DependencyExtractorBuildService$Inject cannot be cast to class org.gradle.dependencygraph.extractor.DependencyExtractor HOT 3
- Failed to stop service 'gitHubDependencyExtractorService' HOT 3
- Error message on missing required input param prompts user to "Please report this issue"
- gradle jvm toolchain support HOT 2
- Failures during dependency resolution seem to be swallowed HOT 3
- Circular dependency error when build includes itself HOT 8
- Annotate PRs that merging will resolve or introduce Dependabot alert HOT 3
- Plugin doesn't seem to work with projects that use `dependencyResolutionManagement` HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from github-dependency-graph-gradle-plugin.