Hi,
I am working (finishing) on an extension of (still private) Project
Dependency API that would allow to *add* dependency to a project (and
also remove). This is a change that will span both Maven and Gradle
modules, so I thought I'll put a note in advance, but PR will be landing
shortly in Github.
The reason is the ability to add technology libraries, i.e. add
monitoring to an application, add JDBC driver etc, which all requires
(among other things) to add a set of artifact(s) to a project. I would
like to have that ability for our company product, primarily, but the
API to do _basic_ dependency changes in both major supported build
systems. Only basic operations (add, remove) and only projects that use
some artifact repositories are considered (maven, gradle, possibly mx),
not ant-based projects.
In order to get a reasonable API outcome, I decided to work jointly with
Refactoring API and LSP API: the changes are best described as text
changes to project files - and in case of our LSP client use-case,
perform them. And rectoring API allows to commit() them in NetBeans
case. Note that while *java* refactoring API describes text
modifications in its result, the generic refactoring API does not. It
does not seem beneficial to invent yet another text-changes description
now, when LSP APIs are here, and basically do what's needed (even for Java).
Gradle implementation: I do not want to pollute basic gradle modules
more, so I decided to create a small java.gradle.dependencies module; I
am thinking about migrating the dependencies part out of java.gradle
module to the new one, which should clean up java.gradle module a bit.
Maven implementation: For Maven, I'd work this into maven.hints. All
dependencies are there except refactoring.api.
Some more steps are IMHO needed until the dependency API is mature
enough to get out of private:
- the Scope is not designed well; it was anticipated (and that's why the
API is not public) the introduction of modifications shed a little more
light on it. I'll be working on that, keeping Micronaut support module
as a early adopter (with necessary updates).
- the Dependency children ought to be generated lazily; this gives the
client the option not to traverse / expand subtrees for dependencies
already seen. But some clients need exhaustive traversal.
- improve the interaction with BOMs
Cheers,
-Svata
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists