This was using Gradle 6 and it seems after doing some more builds and then
configuring Gradle in the options NetBeans is able to load the project...
Odd thing is the IDE did detect the Gradle binary correctly so maybe the
repeat build finally produced something on disk?
It's a big project so I do
It seems there's a fair bit of "I thought it was just me" going around.
I've made an issue for this.
https://issues.apache.org/jira/browse/NETBEANS-4286
On 2020-05-01 02:00, James Ostrowick wrote:
I’m so glad someone else is having this problem! I thought it was just
me.
It drives me nuts tr
I’m so glad someone else is having this problem! I thought it was just me.
It drives me nuts trying to create a debug breakpoint as well, sometimes I have
to click several times to get it to acknowledge the breakpoint insertion.
What I have noticed is that it if you click, pause for about a seco
I think Scott is onto something. I've run 20 or so tests where I
experienced this by leaving my external mouse still and using the button
on the laptop touchpad to do the clicking, and there were no
"missed/ignored" clicks. Same story for a similar problem with opening
files via double-click.
Well, the user might not have the latest Maven installed. At least we know
for sure that they have the embedded version.
Gj
On Fri, 1 May 2020 at 01:38, Ty Young wrote:
>
> On 4/30/20 6:08 PM, John Mc wrote:
>
> Unless I'm mistaken, NetBeans uses the embedded NetBeans version, which
> for NetBe
I'd recommend to add an improvement request into JIRA. I do not think
that it can be solved in 11.3, some cumbersome workaround could be
overriding the test action.
Unfortunately 12.0 is almost ready so most probably this can be released
in August or some daily builds.
On 4/30/20 11:54 AM,
On 4/30/20 6:08 PM, John Mc wrote:
Unless I'm mistaken, NetBeans uses the embedded NetBeans version,
which for NetBeans 12.0 should have Maven 3.6.3 embedded.
There will be another beta version of 12.0 out soon I believe, so
maybe confirm this with that version?
What I'm suggesting is to a
Unless I'm mistaken, NetBeans uses the embedded NetBeans version, which for
NetBeans 12.0 should have Maven 3.6.3 embedded.
There will be another beta version of 12.0 out soon I believe, so maybe
confirm this with that version?
Regards
John
On Thu, 30 Apr 2020 at 20:16, Ty Young wrote:
> JIRA
That's a definite possibility... I'm a "drive by clicker", notorious for
small mouse shifts between down and up. I'll try testing that out.
On 2020-04-30 16:11, Scott Palmer wrote:
Same on macOS. It seems if the mouse moves a single pixel between
mouse down and mouse up then it may not count as
Same on macOS. It seems if the mouse moves a single pixel between mouse down
and mouse up then it may not count as a click.
Scott
> On Apr 30, 2020, at 11:59 AM, Darin Miller wrote:
>
>
> I also observe the "ultra precise" mouse behavior. Both on win7 and win10
> desktops.
>
> o__
> >/
JIRA: https://issues.apache.org/jira/browse/NETBEANS-4285
Netbeans should, assuming there are no blockers, always use the latest
Maven release for newly generated projects.
Can this be done? The only issue, IIRC, is that Maven and JUnit don't
work correctly... but that affects older version
The older G4NB plugin had smarts or something such that it looked at
pathing of where a test file was and adjusted the gradle invocation
accordingly.
So for example, a Spock spec in:
src/test/groovy/com/blah/blah/SomeSpec.groovy
would invoke gradle a bit like like:
./gradlew tests --tests com
Hi
Quick update, I down graded from java 13 to java 11 and the problem has
gone away so it looks like it is linked to Java 13.
Regards
Peter
On Sun, Apr 5, 2020 at 2:15 PM Peter Steele wrote:
> Hi
>
> Netbeans seems to cache compile errors and on startup immediate flags
> those compile errors
I also observe the "ultra precise" mouse behavior. Both on win7 and win10
desktops.
o__
>/
( )\( ) Darin | 208-991-4421
On Thu, Apr 30, 2020 at 9:52 AM Alan
wrote:
> Hi Eirik,
>
> No display scaling, everything is 100%. It's also monitor-independent. The
> problem is inconsistent, although
Hi Eirik,
No display scaling, everything is 100%. It's also monitor-independent.
The problem is inconsistent, although it's more prevalent with
breakpoints than with the document close. The highlight box is a good
indication that the mouse position is getting read right, it's the click
event
> I get the red box hover highlight around the "X" to close a document, but
> unless I click in exactly the right place within that box, the document
> doesn't close.
Hmm, odd--I'm on Windows 10 as well, and hadn't had this problem. Do you have
HiDPI scaling active by any chance? ("Display Sett
16 matches
Mail list logo
