Initial implementation of (experimental) Dependency API in Gradle #4499
Conversation
sdedic
added
API Change
|
Well, what I am curious is what the additional memory footprint of adding the dependencies into the GradleBaseProject the 10000+ nodes sounds scary. 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. |
extide/gradle/src/org/netbeans/modules/gradle/api/GradleBaseProject.java
Outdated
Show resolved
Hide resolved
|
@lkishalmi The structure in Configuration is just (currently) just a graph, not an unrolled tree, so in "usual" projects it is rather slim. No |
extide/gradle/src/org/netbeans/modules/gradle/api/GradleBaseProject.java
Outdated
Show resolved
Hide resolved
| test.use.jdk.javac=true | ||
| spec.version.base=1.19.0 |
There was a problem hiding this comment.
Why are we moving the Specification-Version out of manifest.mf and use spec.version.base?
I'm just curious.
There was a problem hiding this comment.
https://netbeans.apache.org/wiki/DevFaqImplementationDependency.asciidoc -- it's a way how to autoincrease spec version when the implementation dependency changes. I will move it back when I finalize the project.dependency module (based on feedback / findings when implementing Gradle, I'd allow some laziness, still not unsure how).
| @@ -0,0 +1,708 @@ | |||
| /* | |||
There was a problem hiding this comment.
OMG. Just wanted to add an ANTLR4 Lexer and Parser for simple Groovy based Gradle projects. Anyway, I still have to do that, so this is welcome!
There was a problem hiding this comment.
Hm, I am working on output artifacts support and for that I'd need some other scanner, at least for simple name=value assignments to various task properties. I plan to supply the list of possible property names (and structure members) from introspecting the tasks / extensions in the project, so the scanner could better ignore 'the unknown' stuff without having to be a full parser.
Stay tuned, it's still in very rough state
| @@ -161,7 +166,7 @@ public Map<String, Dependency> getDependencyMap() { | |||
|
|
|||
| private void buildDependecyMap(Dependency dependency, Map<String, Dependency> result) { | |||
| String gav = createGAV(dependency.getArtifact()); | |||
| result.put(gav, dependency); | |||
| result.putIfAbsent(gav, dependency); | |||
| dependency.getChildren().forEach((childDependency) -> { | |||
There was a problem hiding this comment.
So the line above expect that there could be allredy pair gav : dependency in the result. In this case the dependency is not put again in the result but the children are recountned anyway.
| String n = getName(); | ||
| String g = getGroup(); | ||
| String v = getVersion(); | ||
| if (n == null || "".equals(n) || g == null || "".equals(g) || v == null || "".equals(v) || "unspecified".equals(v)) { // NOI18N |
There was a problem hiding this comment.
Just minor. Using n.isEmpty(), q.isEmtpy() and v.isEmpty would be better here than the equals approach. The null check is done in the condition anyway.
|
2 approvals, only |
Dependency tree is exported from Gradle, using still nonpublic
project.dependencyAPI. I admit I need it functioning for the NBLS server, so I propose to go short-term with implementation dependency onproject.dependencymodule. I plan to stabilize and publish the project.dependency as a regular API in NB16 timeframe withProjectArtifactsQuerythat 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.