apache
Initial implementation of (experimental) Dependency API in Gradle
Dependency tree is exported from Gradle, using still nonpublic project.dependency API. I admit I need it functioning for the NBLS server, so I propose to go short-term with implementation dependency on project.dependency module. I plan to stabilize and publish the project.dependency as a regular API in NB16 timeframe with ProjectArtifactsQuery that exposes project output artifact(s) for further analysis or processing. I hope I will be able to adapt Maven Graph module to serve for both Maven and Gradle connecting using the new APIs.
Part of this commit is an adjustment to the OCI enterprise feature so it is able to exploit this new Gradle ability to serve dependency tree. During testing it seems that an initial dependency graph of 100 nodes would explode to 10.000+ nodes when converted to a proper tree, so the Dependency API will receive some tweak to allow implementations to compute the nodes lazily and to indicate to the client that two nodes are truly equivalent. In the meantime, I've changed the ADM feature to send a graph instead of tree - it appears working.
Minor fix to Maven implementation.
Well, what I am curious is what the additional memory footprint of adding the dependencies into the GradleBaseProject the 10000+ nodes sounds scary. It would be good to know how essential this information would be. What I'm thinking about, that this info could be fetched/cached in a separate Model. Though that may require more work.
I'm fine to put the dependency info (if it is not that exploded) in the GradleBaseProject.
So it would be good to now what would it put on the IDE on memory and probably on CPU. If it could be expensive let's move it to another model. It can be done later though, if you do not expose the dependencies through GradleBaseProject.
@lkishalmi The structure in Configuration is just (currently) just a graph, not an unrolled tree, so in "usual" projects it is rather slim. No ArtifactSpec structures are created in advance and the graph contains target GradleDependency instances, which are created already anyway. The tree is made only when someone asks for the DependencyResult. I'd still think about a way how to indicate to the API client, that a graph node is equivalent to some other (which is the usual case - the subtree can differ if some transitive dependency is excluded, which is not that common), so the client may stop tree traversal.
2 approvals, only DebugRubyTest and DebugBaseTest tests are failing which are unrelated to this PR. Going to merge in a few hours.