On 2/22/21 12:53 AM, Svata Dedic wrote:
Hi,
sorry for contacting directly. I don't want to push too much, but I'd
need (for the LSP to proceed smoothly) to move on with the "trust"
thing in Gradle.
That's Ok, though I'm going to put the dev list in the cc. There is
nothing secret on this, and I do not mind if someone else would give
feedback on the topics. But at least these discussions are open.
In particular I need to finalize one of the solutions outlined in
https://github.com/apache/netbeans/pull/2769 -- if there's the changed
dialog - fine, that's something that we can teach LSP users to use
(they don't have much access to the LSP server = NetBeans settings
otherwise, yet). Or if you'd prefer the SPI way, I'll gladly implement
that.
Well, I'm not really fond of my code that handling the trust. At leas in
a way that I had to do it. I have two things to add:
1. NetBeans does not use tri-state checkboxes. Introducing one here
would be a bit alien. Combo box would be Ok for the UI.
2. I would go as simple as it can be detecting the LSP (or just
headlessness, by checking java.awt.headless property), for putting up
the trust dialog. Yes an SPI would be a nice solution for this technical
problem, but then there could be a malicious module easily developed,
that simply switch off the trust checking, so let's keep that in the house.
But https://github.com/apache/netbeans/pull/2769 in combination with
https://github.com/apache/netbeans/pull/2765 may result in endless
questions for LSP client (since the client can't see the checkmark in
the custom dialog, it can't properly mark the project).
I would appreciate your decision.
A small heads up. Following the work for Maven
(https://github.com/apache/netbeans/pull/273) that allows the Project
Action's caller to override arguments in the action mapping (or, for
maven, in the project file, but that probably does not apply to
Gradle), I'd like to implement the same approach in Gradle.
Do you have any objections against the approach ? The general idea is
that the caller provides explicit instructions / modifications in the
Aciton's context lookup (which was designed to pass additional info to
the action), and the gradle module will pick it up & use to decorate
parameters which would be otherwise passed.
That's a good question. First I'd like to ask what kind of usecases do
we want to support. If it just a generic Gradle build command line
decorator, then it's probably fine. What I would like to mention, that
this might add a parallel path to the existing ActionMappingProvider API.
Thanks for your support,
-Svata
---------------------------------------------------------------------
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
