On 12/28/23 08:49, Ulrich Mayring wrote:
I decided not to leak NetBeans internals into the Output window. That
probably would have confused more people, than hiding those things,
and again that would leak internals into the output window. I was
planning to add an option, that could enable dis
I decided not to leak NetBeans internals into the Output window. That
probably would have confused more people, than hiding those things, and
again that would leak internals into the output window. I was planning
to add an option, that could enable displaying the full command line, if
there wou
-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluen
On 12/28/23 01:34, Ulrich Mayring wrote:
I find that most unfortunate. I've been using Netbeans for many years
and the one clear advantage it always had for me over other IDEs is
that it was just a frontend to my build script. So everything would
behave exactly the same in the IDE as it would
On Thu, 2023-12-28 at 12:24 +0100, Ulrich Mayring wrote:
> then I would find it a valuable feature to be able to do that on the
> command-line as well. If the IDE is not able to do this via Gradle,
> then
> it should not pretend to do so by outputting gradlew scripts.
I am very sure, that somewh
1) you work with Gradle, where the Gradle Build file defines the build
logic (and Netbeans has to follow it)
Agreed.
2) but (respectfully!) you still seem to look at it with "Ant" glasses,
when Netbeans built the logic and the script for you (because no sane
person could be bothered to built
On Thu, 2023-12-28 at 11:48 +0100, Ulrich Mayring wrote:
> Does this select the correct class? The original command-line
> included
> -PrunClassName=package.MyMainClass as a parameter.
You can also forward the Class to run as a parameter.
>
> But anyway, I think with some tweaking and twiddling
Does this select the correct class? The original command-line included
-PrunClassName=package.MyMainClass as a parameter.
But anyway, I think with some tweaking and twiddling it will be possible
to write a task that replicates 99% of what the IDE does. But I'm not
sure whether that is the assi
On Thu, 2023-12-28 at 16:59 +0700, Andreas Reichel wrote:
> On Thu, 2023-12-28 at 10:48 +0100, Ulrich Mayring wrote:
> > Well, how would I know how to define this task? I want it to do
> > exactly
> > what "Run Single" in the IDE does. So how to write this task?
Please disregard, this one works c
On Thu, 2023-12-28 at 10:48 +0100, Ulrich Mayring wrote:
> Well, how would I know how to define this task? I want it to do
> exactly
> what "Run Single" in the IDE does. So how to write this task?
This should work as long as you have a simple single Java Application
which you would like to execut
Well, how would I know how to define this task? I want it to do exactly
what "Run Single" in the IDE does. So how to write this task?
Am 28.12.23 um 10:39 schrieb Andreas Reichel:
On Thu, 2023-12-28 at 10:34 +0100, Ulrich Mayring wrote:
I find that most unfortunate. I've been using Netbeans f
On Thu, 2023-12-28 at 10:34 +0100, Ulrich Mayring wrote:
> I find that most unfortunate. I've been using Netbeans for many years
> and the one clear advantage it always had for me over other IDEs is
> that
> it was just a frontend to my build script.
Greetings!
You still can very much achieve t
I find that most unfortunate. I've been using Netbeans for many years
and the one clear advantage it always had for me over other IDEs is that
it was just a frontend to my build script. So everything would behave
exactly the same in the IDE as it would later in the CI process.
Is this a newer
13 matches
Mail list logo
