sdedic opened a new pull request, #6868:
URL: https://github.com/apache/netbeans/pull/6868

   This PR is an iteration after private testing (closed) #6849 and should land 
in `master` branch. Side PRs are already part of the master, this PR contains 
consolidated changes from `sdedic/feature/project-dependencies-add_base` 
branch. I'll copy the description of the original PR here:
   ---
   
   ## Overview and heads-up
   The `project.dependencies` API is still private - intentionally. The plan 
was to first implement a prototype client as a validation of the APIs, then 
publish. This PR adds a prototype of abstract "add dependency" operation tot he 
APIs.
   
   I'll implement `remove` operation next. I think still need to (somehow) 
address the BOM and/or dependency-management concept. As a "Saturday project", 
I still plan to convert Maven graph dependency viewer into a general dependency 
viewer, so it will work for gradle too.
   
   I do not expect the project dependency API to mature in NB 21 timeframe; the 
target is NB 23.
   
   ## Gradle experimental module
   In order to implement project modification, I've added `gradle.dependencies` 
to Java cluster - this module has some dependencies that do not fit for 
`gradle.java` - and I do not want to mess the dependencies further. As the 
impementation progressed, it turned out that it could be beneficial to clean up 
`gradle.java` and move the dependency query implementation to 
`gradle.dependencies` as well. 
   
   ## Breaking change in a private API
   The `Scope` had abstract operations so the client can evaluate that some 
reported scope actually propagates to an abstract one, like `Scopes.COMPILE`. 
Imagine that the client gets a dependency declared in gradle's `compileOnly` 
and is interested to find out if it makes it to `runtime`. But it seems more 
useful to delegate this evaluation to the buildsystem-specific provider 
instead. In this PR I removed the `implies` and `includes` metods from the 
Scope, which become a simple extensible enum only.
   
   This breaking change was retrofitted to implementations. The API is not even 
`friend`, so no official compatibility was broken. The API will evolve as 
private for some time to incorporate feedback from early adopters and comments.
   
   ## Concept overview
   The operation is described in API as a `refactoring`: a `ModificationResult` 
is produced, with ***no changes to the documents and files***. Since textual 
difference structures are only part of `java` APIs, I decided to use `LSP ` API 
structures, that wel describe intended modifications: otherwise I would more or 
less copied them over.
   I propose using LSP APIs as a general communication mechanism, and even 
promote their usage to `refactoring.api` itself.
   So the result of dependency modification is a `ProjectModificationResult` 
that can be either `commit()`ed by IDE clients, or presented as a preview using 
`WorkspaceEdit` structure - and possibly it can be applied by a LSP client.
   
   ## Dependency add
   Currently add and remove is defined, and only add implemented. Add or remove 
can add/remove  a list of dependencies. Either with specific version, or omit 
the version - this is where the BOM included in the project is useful, but 
currently the client has no way how to even check that it can omit the version, 
or resolve an appropriate version -- I'll think about that in later phases and 
possibly add.
   
   The dependency add may fail if a dependency is already defined. It is 
possible to include optiosn to ignore such duplicates, so dependencies not 
present are added and those already present silently ignored.
   
   ## LSP operations
   Two LSP commands  are implemented:
   - `nbls.project.dependencies.find` that searches for dependencies in 
specified scope(s) and report dependencies that can reach to those scopes. 
Optionally with all children. The operation utilizes the 
`ProjectDependencies.findDependencies` API.
   - `nbls.project.dependencies.change` that acutally modifies the dependencies.
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Reply via email to