Hi Svata,
lets say project A sets a dependency on project B and project
dependencies are an IDE feature. How will project A build outside of the
IDE?
And why is it not sufficient to (mvn) install the dependency into the
local repo, and then depend on it the regular way?
I don't doubt that this can be useful but NB has a long tradition of not
creating IDE dependent project structures. Other IDEs became less
invasive too which makes picking an IDE no longer a team decision.
(I likely don't fully understand what the feature is since
refactoring+hints were also mentioned)
best regards,
michael
On 29.11.23 20:22, Svata Dedic wrote:
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
---------------------------------------------------------------------
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
