On 2/25/21 3:06 AM, Svata Dedic wrote:
A sidenote: splitting the conversation, as it really deserves two
threads. This one should discuss the proposed "Run with Parameters
feature for gradle.
But the original thread ("Gradle fixes & heads up") contains also
other stuff related to the existing stalled PRs[2],[3] - Laszlo, would
you please look at the mail[1] again - I think there are still some
questions unanswered that would help me to finish the implementation.
=====
Dne 23. 02. 21 v 6:50 Laszlo Kishalmi napsal(a):
That was meant to be as, just another way of do the things which
already can be done. It is possible for modules to register their own
GradleActionMappingProvider which can return an command line for an
action. Right now the only issue that the usage at this provider the
GradleActionMappingProvider ... I could only find
ProjectActionMappingProvider and GradleActionsProvider; I suppose it's
ProjectActionMappingProvider as that one actually creates the
implementation.
I saw a complete replacement as quite heavyweight ... but looking at
the ProjectActionMappingProviderImpl, the impl is very lightweight
(unlike Maven ;)).
So at worst, a supposed "LSP Gradle" module would provide a
replacement for project run, debug, profile actions + suck (somehow)
the rest of actions from standard Gradle support ?
That's what I've meant, and yes fallback to the existing implementation
needs some love in the code to be possible.
Still I could need (somehow) to tunnel down to GradleDaemonExecutor so
I could eventually affect its buildLauncher.setEnvironmentVariables()
[see below]. Can you think of a feasible way ?
Also as you've checked, there is no way to set environment variables for
the GradleExecutor. We pass the JAVA_HOME, but that's it. If that
feature is required it had to be implemented.
code treats as only one provider can be active at a given time and
does not allow fallback chaining. (Probably introducing a lookup
merger would do for that)
Also in Gradle run task does not really take arguments unless
--debug-vm parameter processing shall be done in the Gradle build
file instead.
Well, I though that --args="application arguments" can be passed on
the commandline (documented since Gradle 4.9).
Well, I've learned something new here. Thank you!
For client JVM arguments, this will be tougher. Searching through
documentation, it MAY be possible to use JAVA_OPTS environemnt
variable. According to the documentation, gradle daaemon would use
that one when launching client JVM. Granted, this approach would be
only applicable for Java execution at the moment.
The question is how can the IDE know / parse the default JVM args
(applicationDefaultJvmArgs) so it can decorate it ?
The Java VM args processing is happening in the GradleCommandLine and it
is based on the org.gradle.jvmargs property. As far as I know it reads
the gradle.properties in order to find the proper one, however I guess
we miss processing the actual command line for that property, it has to
be checked. But if that would work specifying extra JVM arguments would
be as easy as adding a -Porg.gradle.jvmargs="<args>" in the command line.
Anyway, I am going to prototype it (somehow), maybe I've misunderstood
the docs.
Let me put the question other way around. Imagine an action that
allows the user to parametrize the application ad-hoc:
+-----------------------------------------------------+
| |
| Mode: [Run v] }
| App parameters: [.........................] |
| Extra VM params: [.........................] |
|
| [ OK ] [ Cancel] |
+-----------------------------------------------------+
but written in a way *that can be scripted, or automated* from another
module, so no GUI is displayed by the action itself (if it gets right
instructions) - perhaps the caller has its own GUI. Can execute run,
debug, profile, eventually even debug-single (if run on a file).
This action can now be implemented, depending on Project API +
Execution API only and will work for Maven projects. I guess I could
(and probably should, for consistency) change Ant projects to support
the abstract 'parameters' interface.
So let's try to explore how that could be achieved with Gradle. It may
even require some specific property to be introduced in the project
(its build.gradle), so this level of integration could work ! But
that's "just" a matter of documentation for the supposed action (well,
in our current case for the VSCode client).
Cheers,
-Svata
[1]
https://lists.apache.org/thread.html/rdcf2ce3f11ee4a46bdeb030f9b8309570d9f5007a8b099f77445c06c%40%3Cdev.netbeans.apache.org%3E
[2] https://github.com/apache/netbeans/pull/2769
[3] https://github.com/apache/netbeans/pull/2768
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
