Initial implementation of Project Dependency API #4149
Conversation
sdedic
added
enhancement
API Change
sdedic
force-pushed
the
maven/dependency-api
branch
from
b96970e
to
a516850
Compare
| @NonNull String versionSpec, boolean optional, @NonNull V data) { | ||
| return new ArtifactSpec<V>(VersionKind.SNAPSHOT, groupId, artifactId, versionSpec, type, classifier, false, data); | ||
| } | ||
|
|
There was a problem hiding this comment.
And VersionKind.Latest? We don't need it now?
There was a problem hiding this comment.
will remove. Can be added later.
| "vscode-debugadapter": "1.51.0", | ||
| "vscode-languageclient": "8.0.1" | ||
| "vscode-debugadapter": "1.42.1", | ||
| "vscode-languageclient": "7.0.0" |
There was a problem hiding this comment.
Is it intended to downgrade the versions? There are downgraded versions for more modules.
There was a problem hiding this comment.
Unintentional - seems as leftovers from local experiments were committed, no change to vscode should be made here. Will clean up.
There was a problem hiding this comment.
Changes removed (= same as master) in f3ee411
|
Maybe, Some files are missing the license header? ( |
|
It's an interesting start. Too "mavenly" though at the moment. I'd let give it a go, though when applying to Gradle there would be some interesting questions how would could we handle includedBuild substitutes, and different outgoing variants. Also the question is there, should we handle these at all? |
…s to pristine local repo.
I guess I may need your expertise in Gradle area here. Just OTOH (given the API), we might not even care, as the includedBuild (if I understood correctly) just replaces dependency with project dependency, but the project product artifact is still there. The dependency graph is also a snapshot of the final artifact resolution, so (IMHO) no change with included builds. I thouhgt about adding extension services for the additional queries (e.g. one could determine build segments / included builds), which could be project-type-dependent or (if we find a suitable abstraction) project independent - that's why raw (unspecified) data is exposed from ArtifactSpec / Dependency. I thought about adding a BTW - maybe the Maven Graph could be adapted to this API to see graph dependency for Gradle too ;) |
|
Just unreliable tests fail, merging. |
We have API to get inter-project dependencies, but we do not have an API to get a view on dependencies incl. external resources. There's a possibility to get a ClassPath (for Java) enumerating all necessary resources as a flat list, but if one would like to get structure information ... there's probably no way.
This PR is an attempt to define some abstractions, which could eventually become part of
project.api. They probably won't fit to good old ANT projects (but if someone finds a suitable adjustment that would makeArtifactSpecmore Ant-like, please share your thoughts !!), but for example NetBeans modules (although ant-based) could make it.The initial goal is to provide a structured view, a dependency tree, such as
maven dependency:treeorgradle dependencies. The project may start to report its product (artifact, or artifacts ?) and later a project-type-neutral way can be offered to map a resource (e.g. jar) to an artifact known to a project. All this is TBD.The API is initially implemented as private;
implementation dependencyis reuquired to use/implement it. This will change after the constructs are validated on more project types.