RE: Editor tab control UI replacement

[Eirik Bakke]

I tried it on Windows 10--I must say I strongly prefer the previous tab 
appearance (which you also wrote, so no shame in that! :-)

UIs are usually improved by removing unnecessary "bling", not adding more of 
it. The existing tab controls look simple and professional, and attract just 
about the right amount of attention to them: enough to clearly indicate which 
tab is active, but not enough to be distracting. Perhaps things are different 
on Darcula? If so, maybe some smaller Darcula color tweaks would achieve the 
same?

Animations also quickly get tiring. They tend to take something that was 
previously an instantaneous operation, like selecting a tab or even just 
hovering over one, and make it into something that is now perceived to take 
500ms of time. There are a few cases where animations _can_ be warranted, e.g. 
to show that a window is being minimized to a hidden taskbar on MacOS. But 
there is no such need here.

(That said, I love the existing NetBeans tab control! It looks a lot better 
than the Eclipse ones, and I use it in my NetBeans Platform application.)

-- Eirik

-Original Message-
From: Tim Boudreau  
Sent: Wednesday, April 10, 2019 3:57 PM
To: d...@netbeans.apache.org
Subject: Editor tab control UI replacement

Back in 2003/4, I wrote the tab control for the NetBeans 3.6 window system, 
which is still in use - the thing JTabbedPane should have been if it had been 
written with the needs of applications like NetBeans in mind (i.e.
model driven, not using the AWT hierarchy as its model, capable of complex 
transforms on its contents with minimal redraws, etc.).

Some time after that, NetBeans' Visual Library came into being, which makes 
easy a lot of things that are otherwise very hard in Swing - animation, glows 
around components that extend beyond the bounds of the component, smooth 
scrolling and more.  So I've had it in my head for years that someone ought to 
write a replacement UI delegate for the editor tabs which uses it.  Needing to 
take a break from another project, the other day I finally wrote that.  It 
should work on any Swing look and feel (and I tested it on a bunch) - it 
derives its colors from those of the look and feel.  And all of the gradient 
painting logic is carefully memory managed using cached BufferedImages (10-40x 
faster than caching GradientPaint in my tests and far more consistent in its 
performance).

What it does differently are mainly animation and bling, and highlighting for 
the selected tab that sits outside the tab.  It does have really lovely 
built-in tab-dragging support, but since drag support in the window system is 
implemented via an AWTEventListener in core.windows...I can disable that with a 
not-too-evil hack (have the UI delegate implement Tabbed.Adapter and then 
return null for its Tabbed instance), but then model changes aren't known to 
the window system, so it "corrects" them, undoing the drag on the next move.  
But the existing tab dragging support (with its ugly polygons) works fine, so 
that's disabled by default.

So, two things:
1.  If you'd like a little more (gratuitous?) bling in your editor tabs, please 
test it (download link below) 2.  I'd be happy to contribute it to NetBeans if 
there's interest - it's already licensed compatibly

Screen shot (running on my own Dark Look and Feel plugin):
https://timboudreau.com/files/screen/04-10-2019_15-48-36.png

Binary download compatible w/ JDK 8 and up, NetBeans 8.2 and up:
https://timboudreau.com/files/visual-library-tabbedcontrol-0.3.1.nbm

Github repo w/ source code:
https://github.com/timboudreau/visual-library-tabcontrol

Feedback appreciated.

Thanks,

Tim

--
http://timboudreau.com

NetBeans GUI icons, who drew them?

[Eirik Bakke]

There are over 3000 bitmap icon images in the NetBeans codebase. Probably at 
least several hundred of these are frequently seen by everyday NetBeans users. 
The page below shows all the unique "gif" or "png" files that existed in the 
NetBeans mercurial repo prior to the Apache transition:

htps://people.csail.mit.edu/ebakke/misc/icons.html

THE QUESTION: Does anyone know who actually designed and drew these icons?

I assume some were cobbled together from various sources, but on the other 
hand, many of the frequently visible ones (e.g. the ones in the toolbars) seem 
to follow a quite consistent visual style.

(This question relates to the effort of making NetBeans look better on 
HiDPI/Retina screens; see separate email thread.)

-- Eirik

HiDPI/Retina improvements, confluence page

[Eirik Bakke]

There has been recurring discussions about making NetBeans look better on HiDPI 
(retina) screens. This is a large umbrella issue, touching all three major 
operating systems (Windows, Linux, and MacOS), with many subtasks involved. I 
have created a Confluence page which summarizes the current state of 
HiDPI/Retina on NetBeans, and the high-level TODOs:

https://cwiki.apache.org/confluence/display/NETBEANS/HiDPI+%28Retina%29+improvements

The biggest unknown here is probably how to replace the old bitmap icons 
(several thousands, or at least hundreds) with scalable equivalents. But before 
that is done, SVG icons must be supported from the NetBeans Platform APIs 
(ImageUtilities, Node etc.).

-- Eirik

RE: Feedback: Release Management of Apache NetBeans (incubating) 11.0

[Eirik Bakke]

Hear, hear--thank you for the great work, Laszlo!

Maybe the "Update titlebar version" issue ( 
https://issues.apache.org/jira/browse/NETBEANS-2111 for 11.0, with associated 
pull request as an example) should also be added to the release process list at 
https://issues.apache.org/jira/browse/NETBEANS-2052 ?

-- Eirik

-Original Message-
From: Antonio  
Sent: Friday, April 5, 2019 2:17 PM
To: dev@netbeans.incubator.apache.org
Subject: Re: Feedback: Release Management of Apache NetBeans (incubating) 11.0

Hi all,

Thanks, Laszlo, for this great work.

Regarding the release process [1], I think we could change steps 24 and 25.

What we have now:

24. Update the WebSite for the new Release 25. Send out release announcement-s

The proposal:

24. Prepare a PR with the website for the new Release and some screenshots for 
Twitter.
25. Publish the website, send out release announcements to mailing lists and 
post to Twitter/elsewhere.

In step 25 we could coordinate to send announcements to mailing lists, update 
the website and make some noise in Twitter and elsewhere. This is something 
that involves many people, and we could coordinate in advance. 
For instance, by sending an email to the mailing lists 24h in advance 
(something like "we'll announce the new release on monday at 12:00 UTC").

Kind regards and thanks again,
Antonio


[1]
I love this process as documented at:
https://issues.apache.org/jira/browse/NETBEANS-2052


El 5/4/19 a las 13:22, Laszlo Kishalmi escribió:
> Dear all,
> 
> I would like to thank you to be able to be the Release Manager of 
> Apache NetBeans 11.0!
> 
> Thank you all, who contributed in this release either by code, 
> documentation, advice, or shared opinion!
> 
> This cycle started a bit sleepy, either due to the new year's duties 
> or due to the exhaustion from over-carrying the 10.0 release. After we 
> were over the shock everything started to shape up nicely by end of February.
> 
> As a release manager I found it a good practice not to do a release to 
> staging for every vote candidate we made and we could use the 
> artifacts from Jenkins directly. I still hope that it did not cause 
> any trouble for the Apache Infrastructure. I'd keep that for the 
> future releases as well.
> 
> I'm still not fond of the vote candidate name. The release actually 
> matured nicely vc1 - alpha, vc2 - beta 1, vc3- beta 2 and vc4 is an 
> rc1 quality. If I were not traveling through the world just at the end 
> of our cycle, I would have cut a vc5 as well to address the minor 
> non-technical concerns were found out during the voting cycle.
> 
> Some Numbers:
> 
> In this release we were resolving ~64 issues. 38 bugs, 13 improvement,
> 13 tasks
> 
> The release process right now consists of ~30 steps (two steps more 
> than 10.0), about the half of these steps requires changes in the 
> release branch. This sets our limit to about four releases in a year, 
> which is not bad, but we have that limit.
> 
> I hope, I was documenting our work well enough, to make the job of the 
> next Release Manager easier.
> 
> This was a though, but wonderful journey! Thank you everyone for their 
> work and support!
> 
> Laszlo Kishalmi
> 
> Volunteer Release Manager of Apache NetBeans 11.0
> 
> P.S.: Constructive feedback on the process and on my work are , as 
> always, welcome!
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: 
> dev-h...@netbeans.incubator.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.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: [VOTE] Apache NetBeans graduation to Top Level Project

[Eirik Bakke]

+1

-- Eirik

-Original Message-
From: Jan Lahoda  
Sent: Monday, March 11, 2019 3:47 PM
To: d...@netbeans.apache.org
Subject: Re: [VOTE] Apache NetBeans graduation to Top Level Project

+1!

Jan

On Mon, Mar 11, 2019 at 11:48 AM Geertjan Wielenga 
 wrote:

> Hi all,
>
> After a discussion amongst the Apache NetBeans community on the dev 
> mailing list[1], voting on a PMC chair[2], checking the podling status 
> page[3], and working through the maturity model[4], I would like to 
> call a vote for Apache NetBeans graduating to a top level project.
>
> Apache NetBeans entered the incubator on October 1, 2016. Since then, 
> we have announced 2 releases, nominated several new committers, 
> participated in conferences and events, have 99 contributors with 
> 2,423 commits, and -- most importantly -- have grown and diversified 
> our community. Apache NetBeans is a healthy project that is already 
> acting like an Apache top level project, so we should take the next step.
>
> If we agree that we should graduate to a top level project, the next 
> step will be to draft a Resolution for the PPMC and IPMC to vote upon.
>
> Please take a minute to vote on whether or not Apache NetBeans should 
> graduate to a Top Level Project by responding with one of the following:
>
> [ ] +1 Apache NetBeans should graduate.
> [ ] +0 No opinion
> [ ] -1 Apache NetBeans should not graduate (please provide the reason)
>
> The VOTE is open for a minimum of 72 hours. Per Apache guidelines[5] I 
> will also be notifying the incubator mailing list that a community 
> vote is under way.
>
> Thanks,
>
> Geertjan
> on behalf of the Apache NetBeans PPMC
>
> [1]
>
> https://lists.apache.org/thread.html/8724c66eb22c1ceea81160968cb5ae68f
> dc2180f46fbbfaab16b4ce9@%3Cdev.netbeans.apache.org%3E
> [2]
>
> https://lists.apache.org/thread.html/e0ecae84ac6e4a097a34ce7b2afe0e987
> e403fe32269fb3903895bbc@%3Cdev.netbeans.apache.org%3E
> [3] https://whimsy.apache.org/pods/project/netbeans
> [4]
>
> https://cwiki.apache.org/confluence/display/NETBEANS/Apache+Maturity+M
> odel+Assessment+for+NetBeans
> [5]
>
> https://incubator.apache.org/guides/graduation.html#community_graduati
> on_vote
>

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: [VOTE] PMC chair for Apache NetBeans

[Eirik Bakke]

+1

-- Eirik

-Original Message-
From: Glenn Holmer  
Sent: Friday, March 1, 2019 9:29 AM
To: dev@netbeans.incubator.apache.org
Subject: [VOTE] PMC chair for Apache NetBeans

This voting thread is to confirm Geertjan Wielenga as the first PMC chair of 
NetBeans as we leave incubation and begin our journey as a top-level Apache 
project. As an Oracle employee, Geertjan has been in a unique position to help 
guide the project to independence and is the best choice to complete that 
process.

As a reminder, here are the duties of the PMC chair:

http://www.apache.org/dev/pmc.html#chair

Please indicate your vote with +1, 0, or -1.

--
Glenn Holmer (Linux registered user #16682) "After the vintage season came the 
aftermath -- and Cenbe."

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: Find Bugs Integration - which donation?

[Eirik Bakke]

> FindBugs is effectively dead, but SpotBugs has becomes its successor, and 
> supports up to Java 9 and is in active development.

To clarify, it seems that SpotBugs is a fork of FindBugs, cloned November 2016, 
with some light branding changes. So it's really the same piece of software 
from an IDE integration standpoint.

(The explanation at 
https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/004337.html 
was informative.)

-- Eirik


-Original Message-
From: John McDonnell  
Sent: Tuesday, January 1, 2019 5:28 AM
To: dev@netbeans.incubator.apache.org
Subject: Re: Find Bugs Integration - which donation?

Yes,

FindBugs is effectively dead, but SpotBugs[1] has becomes its successor, and 
supports up to Java 9 and is in active development[2].

My curiosity about the integration arose when I spotted this "new" project 
earlier (that being said I still use Java 8 - mostly for work purposes...)

[1]: https://spotbugs.github.io/
[2]: https://github.com/spotbugs/spotbugs

Regards

John

On Tue, 1 Jan 2019 at 02:59, Laszlo Kishalmi 
wrote:

> Well, just adding some note: FindBugs is not maintained and cannot 
> process bytecode from Java 9 and above.
>
> On 12/31/18 3:01 PM, John McDonnell wrote:
> > Hi All,
> >
> > Just looking at the transition page[1] and I notice theres no 
> > reference
> to
> > the find bugs integration (When you selection Source->Inspect and 
> > select FindBugs as an analyser) page.
> >
> > Is there any update on this? Was it missed in the confluence page - 
> > relegated to a later drop?
> >
> > Thanks in advance
> >
> > [1]:
> https://cwiki.apache.org/confluence/display/NETBEANS/Apache+Transition
> >
> >
> > Regards
> >
> > John
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: 
> dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

RE: How to get NetBeans 10 as maven dependencies

[Eirik Bakke]

Hi, Sergio.

I have updated my comment in https://issues.apache.org/jira/browse/NETBEANS-467 
to include some more instructions about the nb-repository-plugin. I actually 
had to build it myself from sources as well. Sorry to cause confusion!

-- Eirik

-Original Message-
From: Sérgio Lopes  
Sent: Friday, December 28, 2018 6:22 PM
To: dev@netbeans.incubator.apache.org
Subject: How to get NetBeans 10 as maven dependencies

Hi,

I'm trying to build/update a NetBeans IDE module to work with the latest 
release, the module was created for NetBeans 8.2 using Maven. It was not 
created by me and I have no experience with Maven, so I'm struggling to update 
the dependencies to use NetBeans 10.

If I'm not mistaken, there are no maven repositories for 10 available yet, so 
I'm trying to build the release branch and populate my local maven repository. 
I was trying to follow the details on
https://issues.apache.org/jira/browse/NETBEANS-467 but can't get the 
nb-repository-plugin to install/download.

Now, should I keep following those details or are there any set of instructions 
that are more up to date? And how can I specify the location of the 
nb-repository-plugin so maven can install it?

The command I'm using is:

mvn org.codehaus.mojo:nb-repository-plugin:1.4-SNAPSHOT:populate
-DdeployUrl=file:Users/sergio/.m2/repository/ -DgeneratePom=true 
-DnetbeansNbmDirectory=./nbbuild/nbms
-DnetbeansInstallDirectory=./nbbuild/netbeans
-DnetbeansSourcesDirectory=./nbbuild/build/source-zips
-DforcedVersion=RELEASE100 -DgroupIdPrefix=org.apache.netbeans
-Ddetail=true -e
I tried using the repositoryUrl to specify the plugin's URL but not sure what 
to put in it.

Thank you,

Sérgio Lopes

--
http://www.sergiolopes.eu
https://twitter.com/sergiomnlopes
http://www.linkedin.com/in/sergiomnlopes
Skype: sergiomnlopes

RE: Publish a fixed version of a plugin on the portal

[Eirik Bakke]

> And if we are lucky we can have the nb-darcula as an integral part of the 
> platform for the Next release (post 10.0).

Does that mean moving the plugin into the official Apache NetBeans project? 
(The incubator-netbeans github repository?) That would be lovely.

The next (post 10.0) NetBeans release will also have proper HiDPI/Retina icons 
in the window system (TopComponent tabs etc.), on the Windows and MacOS LAFs 
[1]. It shouldn't be too hard to do the same on Darcula, which bases its icons 
on the Windows ones.

-- Eirik
[1] https://github.com/apache/incubator-netbeans/pull/859 

-Original Message-
From: Laszlo Kishalmi  
Sent: Monday, December 3, 2018 9:55 AM
To: dev@netbeans.incubator.apache.org
Subject: Re: Publish a fixed version of a plugin on the portal

Hi there!

I've just talked with Revivius yesterday. That is the reason why I started the 
thread for mentors on Donation.

He is working on his code now. And if we are lucky we can have the nb-darcula 
as an integral part of the platform for the Next release (post 10.0).

Though I hope that the current LaF plugin would be updated as well for the time 
being

On 12/3/18 6:20 AM, Jean-Marc Borer wrote:
> Hi community,
>
> I am stumbling into a problem I never had before. Lastly I fixed and 
> improved the Darcula plugin. I cloned it, fixed it, and made a PR. The 
> owner of the plugin seems to have disappeared in the void, because my 
> PR has never touched since several month.
>
> So now I have a fixed and improved version that is running also with 
> NB 9.0 that I really want to share with the community.
>
> What should I do? Publish it as with the original owner info 
> (Revivius)? I doubt I can update the existing plugin ( 
> http://plugins.netbeans.org/plugin/62424/darcula-laf-for-netbeans).
> Unfortunalely Revivius is not showing any sign of life concerning this 
> project (https://github.com/Revivius/nb-darcula/pulls).
>
> This is situation may happen regularly when the code of a pluging is 
> on github, but the author somehow no longer maintains it or disappears 
> and someone want to take over the plugin support.
>
> What to do in that case?
>
> Cheers,
>

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: Lexer and LexerInput woes w/ dynamically created LanguageHierarchy

[Eirik Bakke]

Just in case it's useful: A while back I wrote a very carefully implemented 
adapter from NetBeans' org.netbeans.spi.lexer.LexerInput class to ANTLR's 
org.antlr.v4.runtime.CharStream class:

https://gist.github.com/eirikbakke/51cf4c9375880acd4741/c83dd7e64b91674c6c2bf9d8473c7249a6d66ceb

The equivalent class in the repo you point to seems to be this one:

https://github.com/timboudreau/ANTLR4-Plugins-for-NetBeans/blob/master/1.2.1/ANTLR4PLGNB82/src/org/nemesis/antlr/v4/netbeans/v8/grammar/code/coloring/ANTLRv4CharStream.java

I remember jumping through various hoops to deal with EOF correctly... you 
could always try to replace the existing CharStream implementation with mine 
and see what changes.

-- Eirik

-Original Message-
From: Tim Boudreau  
Sent: Friday, November 30, 2018 6:29 PM
To: dev@netbeans.incubator.apache.org; d...@netbeans.apache.org
Subject: Lexer and LexerInput woes w/ dynamically created LanguageHierarchy

As I mentioned breifly a while back, I decided to do some patching of the Antlr 
module on Github.  I'm hoping the outcome of this is both

 1. Better Antlr support - in particular
   1a. add a bunch of missing features, like code formatting and semantic 
highlighting
   1b. the ability to associate a file extension with a grammar and actually 
edit files with syntax and error highlighting (a preview window lets you tie 
colorings to specific token types and rules) - 
https://timboudreau.com/files/screen/11-30-2018_18-17-53.png
   1c. Much improved cycle time between making an edit to your grammar and 
seeing if you broke something - as in, instantaneous  2. Some modules that make 
integrating languages based on Antlr grammars really easy - there are a lot of 
identical adaptering boilerplate everyone needs for that, and some impedance 
mismatches everyone has to discover the hard way, such as:
   2a. If your grammar doesn't consume EOF, it may not tokenize the entire 
file, and that will make your netbeans lexer explode horribly in the middle of 
painting the main window, making the IDE unusable
   2b. Antlr EOF tokens may actually contain some text, which, if you don't 
consume it, also detonates a bomb in the middle of painting

In particular, doing the dynamic syntax highlighting means programmatically 
registering new languages that appear, disappear, and have their set of tokens 
change on the fly, persisting the mime-type:grammar mappings across restarts, 
*and* doing something reasonable in the case that the grammar was deleted or is 
in an unusable state.  Not to mention generating Java source files with Antlr 
into an in-memory filesystem, running javac against all that and invoking the 
result in an isolated classloader, extracting a complete lex and parse, and 
feeding that into all of that language machinery (believe it or not, on my 
laptop, all of that can run in 82 milliseconds for a fairly complex grammar - 
you really can run antlr generation, compile, load and invoke a parser on every 
keystroke - though it was a lot of work getting there).

NetBeans has some very nice infrastructure for declarative registration of 
languages, most of which is not terribly useful for this. Fortunately, 
registering a MimeDataProvider and a no-arg-constructor MIMEResolver solve most 
of that.

However, getting the Lexer integration solid - i.e. a lexer that has to work 
even with a completely hosed grammar driving it - seems to be my Waterloo.  
Part of the problem is that the initialization order is necessarily backwards:  
Ordinarily in NetBeans, you register a language, the LanguageHierarchy knows 
the token types it has, the editor infrastructure pokes at that at its leisure, 
and when it's ready, asks for a lexer to chew on some text.  But in this case, 
the language hierarchy doesn't know anything about the language until it has 
generated, compiled and invoked it - i.e. *during lexer initialization* is the 
first chance the language hierarchy has to actually get the set of tokens ids 
for the language (to a degree I can hack around this with per-mime-type 
ThreadLocal, for cases where I can wrap the entry point that triggers 
lexer invocation).

So, some issues I'm wondering if anyone has guidance on (is Mila Metelka still 
around?  He would know this stuff inside and out):

 - LexerInput - for this case, I need to, on the first invocation of the 
lexer's nextToken(), or in its constructor, extract the entire text to be 
parsed, feed it through a generated Antlr lexer and build a list of tokens
- nextToken() will simply return them:
   - It is non-obvious from the code and Javadoc, whether you should call
readText() without first making calls to read() to sequentially read tokens
- it appears to work, most of the time (in which case, what is calling
read?) and is what examples generally do.
   - Sometimes you get a LexerInput which has already had some, but not all, 
characters read from it.  It is not at all clear what causes that (or whether 
rewinding is appropriat

RE: Profiler crash for NB10

[Eirik Bakke]

I tested again with some more JDK versions. The new DLL works for me without 
crashing on all of the following:
* Java 8.0.181
* Java 9.0.7.1
* Java 10.0.2
* Java 11.0.1
* Java 12ea

(I'm on Windows 10.)

Note that when testing, I used the DLL with NetBeans 9.0-vc3 (rather than the 
latest NetBeans 10 candidate, which I haven't migrated to yet).

-- Eirik

-Original Message-
From: Emilian Bold  
Sent: Monday, November 26, 2018 10:54 AM
To: NetBeans Dev@ ; peterhul...@gmail.com
Subject: Re: Profiler crash for NB10

Peter, is it OK to consider your binaries under the Apache license for 
redistribution?

I have yet to check this but I'm happy about Eirik's report.

So, just to confirm, does profiling still work with Java 8?

--emi

On Mon, Nov 26, 2018 at 5:42 PM Eirik Bakke  wrote:
>
> I tested the new DLL--it works!!
>
> Here's what I did:
> 1) Start a Java profiling session via the "-agentpath" JVM argument and 
> invoking "Attach to External Process". Shortly thereafter the JVM crashes 
> with the "SUREFIRE-859: #  EXCEPTION_ACCESS_VIOLATION (0xc005) at 
> pc=0x5f131f25, pid=10112, tid=23396" error (and a long JVM dump).
> 2) Download Peter Hull's recompiled profiler binaries from 
> https://github.com/pedro-w/incubator-netbeans/releases/tag/v0.1-alpha , and 
> paste the two files (profilerinterface.dll and profilerinterface.map) into 
> NetBeans\profiler\lib\deployed\jdk16\windows-amd64 (overwriting the two 
> existing files).
> 3) Repeat (1) again. No crash this time, everything works fine!
>
> This is great. Very happy that the profiler functionality will be working 
> again, for newer JDKs. Thanks, Peter!
>
> -- Eirik
>
> -Original Message-
> From: Peter Hull 
> Sent: Friday, November 16, 2018 5:58 AM
> To: dev@netbeans.incubator.apache.org
> Subject: Re: Profiler crash for NB10
>
> On Thu, Nov 15, 2018 at 6:02 AM Emilian Bold  wrote:
> > PS: @Peter: if you could also make a recompiled .DLL available 
> > together with the branch it would be great.
> Right, I have put changes into a fork here:
> https://github.com/pedro-w/incubator-netbeans/tree/profiler-tmp
> and the binaries (just the native code dll) 
> https://github.com/pedro-w/incubator-netbeans/releases/tag/v0.1-alpha
>
> I have tested it and it seems to be working on Windows 64. I've tested 
> it compiles on Windows 32. I have not tested or looked at any other 
> platform (though I don't think my changes should cause problems)
>
> I speculate the problem was some incorrect casting (can't cast a 64 bit 
> pointer to long on Windows?) which maybe didn't manifest on previous JDKs 
> because the values of jmethodid.
> I don't know enough about the internals of the JVM but I'm still not sure if 
> the method used to convert a jmethodid to a jint is robust going forward.
>
> Please let me know what you think,
> Pete
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: 
> dev-h...@netbeans.incubator.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.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: Profiler crash for NB10

[Eirik Bakke]

I tested the new DLL--it works!!

Here's what I did:
1) Start a Java profiling session via the "-agentpath" JVM argument and 
invoking "Attach to External Process". Shortly thereafter the JVM crashes with 
the "SUREFIRE-859: #  EXCEPTION_ACCESS_VIOLATION (0xc005) at 
pc=0x5f131f25, pid=10112, tid=23396" error (and a long JVM dump).
2) Download Peter Hull's recompiled profiler binaries from 
https://github.com/pedro-w/incubator-netbeans/releases/tag/v0.1-alpha , and 
paste the two files (profilerinterface.dll and profilerinterface.map) into 
NetBeans\profiler\lib\deployed\jdk16\windows-amd64 (overwriting the two 
existing files).
3) Repeat (1) again. No crash this time, everything works fine!

This is great. Very happy that the profiler functionality will be working 
again, for newer JDKs. Thanks, Peter!

-- Eirik

-Original Message-
From: Peter Hull  
Sent: Friday, November 16, 2018 5:58 AM
To: dev@netbeans.incubator.apache.org
Subject: Re: Profiler crash for NB10

On Thu, Nov 15, 2018 at 6:02 AM Emilian Bold  wrote:
> PS: @Peter: if you could also make a recompiled .DLL available 
> together with the branch it would be great.
Right, I have put changes into a fork here:
https://github.com/pedro-w/incubator-netbeans/tree/profiler-tmp
and the binaries (just the native code dll) 
https://github.com/pedro-w/incubator-netbeans/releases/tag/v0.1-alpha

I have tested it and it seems to be working on Windows 64. I've tested it 
compiles on Windows 32. I have not tested or looked at any other platform 
(though I don't think my changes should cause problems)

I speculate the problem was some incorrect casting (can't cast a 64 bit pointer 
to long on Windows?) which maybe didn't manifest on previous JDKs because the 
values of jmethodid.
I don't know enough about the internals of the JVM but I'm still not sure if 
the method used to convert a jmethodid to a jint is robust going forward.

Please let me know what you think,
Pete

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: NetBeans 9+ frequently corrupting target .class files in large Maven projects

[Eirik Bakke]

Yes, corrupted class file bugs (Absent Code attribute, Duplicate method name 
etc.) was the one major problem for me going from NetBeans 8.2 to 9.0.

> I'd try to make a fix, but this is one of those bugs that involves an 
> interaction between several far-flung components (maven project plugin, 
> java.source.nbjavac OnePassCompileWorker, nb-javac, possibly java.source.base 
> CacheClassPath), and I really don't know enough about the architecture of 
> compilation to even say which one is at fault.

A fix would be really lovely. There's a related patch at 
https://github.com/apache/incubator-netbeans/pull/504 ; if I understand 
correctly, that one does not solve the underlying problem, but rather makes 
NetBeans handle class file corruption bugs more gracefully. That patch might 
touch some of the same source files, so it might be useful to look at that 
patch and the associated discussion, as a starting point.

-- Eirik

-Original Message-
From: Jeffrey Morlan  
Sent: Wednesday, November 21, 2018 7:18 PM
To: dev@netbeans.incubator.apache.org
Subject: NetBeans 9+ frequently corrupting target .class files in large Maven 
projects

Hi,

There's a bug in NetBeans 9 and 10 that I think deserves some attention:
https://issues.apache.org/jira/browse/NETBEANS-531

Between 8.2 and 9, the Maven project plugin changed such that the compilation 
classpath now includes the current project's own compiled classes.

With the "SuperOnePassCompileWorker" strategy used when compiling small numbers 
of files, this doesn't seem to cause any problems, but with the 
"OnePassCompileWorker"
strategy used when compiling 500+ files, the inclusion of previous compilations 
on the classpath can pollute the resulting class files with bogus members.

The usual symptom is a "Duplicate method name" ClassFormatError, from a lambda 
or other synthetic method, but I've also seen "Absent Code attribute" from a 
code-less static initializer method (unclear where it came from; the class in 
question is typically an interface that doesn't have any static initializers)

So whenever 500 or more files are compiled, usually because of a pom.xml 
change, the target/classes/ directory is effectively corrupted and the project 
needs a manual Maven clean+rebuild.

This is the main issue that keeps us stuck with NetBeans 8.2. I'd try to make a 
fix, but this is one of those bugs that involves an interaction between several 
far-flung components (maven project plugin, java.source.nbjavac 
OnePassCompileWorker, nb-javac, possibly java.source.base CacheClassPath), and 
I really don't know enough about the architecture of compilation to even say 
which one is at fault. Anyone know what the proper approach to fixing this 
would be?

Thanks,
Jeffrey

RE: Openjdk Quality Outreach

[Eirik Bakke]

It's already possible to submit OpenJDK bugs at 
https://bugreport.java.com/bugreport/ , it's just that we don't get direct 
access to the OpenJDK JIRA. If they opened it up completely, they would 
presumably get spammed with thousands of Minecraft-related complaints...

The following bugs were all submitted via the above link:
https://bugs.openjdk.java.net/browse/JDK-8156182
https://bugs.openjdk.java.net/browse/JDK-8211715
https://bugs.openjdk.java.net/browse/JDK-8211999
https://bugs.openjdk.java.net/browse/JDK-8212226

In my experience it takes about month from you submit the bug until they appear 
in the OpenJDK JIRA.

-- Eirik

-Original Message-
From: Antonio  
Sent: Friday, November 2, 2018 11:28 AM
To: dev@netbeans.incubator.apache.org
Subject: Re: Openjdk Quality Outreach

Hi all,

So, would it be possible to report OpenJDK bugs then? Or what's the exact 
purpose of that initiative?

Yesterday I found what seems to be a bug in the GTK Plaf, that makes NetBeans 
10 hang while installing nb-javac [1] on Linux.

Would that allow us to report bugs to OpenJDK? Or do we still need an "OpenJDK 
Author status or above" to report bugs [2]?

Cheers,
Antonio

[1]
https://issues.apache.org/jira/browse/NETBEANS-1584

[2]
https://bugs.openjdk.java.net/secure/Dashboard.jspa


El 1/11/18 a las 22:45, Sven Reimers escribió:
> Hi all,
> 
> following up after our latest discovery of some JDK issue, I thought 
> it may be good to join
> 
> https://wiki.openjdk.java.net/display/quality/Quality+Outreach
> 
> Any opinions?
> 
> Any takers?
> 
> -Sven
> 

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: NetBeans 10.0 vc2

[Eirik Bakke]

I'd love to get a few more Windows users reporting whether the trackpad 
behavior has improved or worsened for them in VC2. We can revert the patch, 
though I suspect this will improve the situation for some users while making it 
worse for others. (On my Thinkpad X1 Carbon 6th gen, the previous behavior was 
unusable.)

Do you see the same issues in scroll panes other than the editor? E.g. the 
Projects pane? (You might need to open up a big project and expand all the 
packages to make it scroll.)

The GIFs are a bit too choppy to see what's really going on (even Chrome does 
not appear smooth). Ideally it would be nice to see how fast your fingers are 
moving as well--maybe you could do a cell phone video showing both your fingers 
on the trackpad and the NetBeans editor scrolling?

I'd love to fix the scroll issue, but I can't think of a way to debug the 
issues you are seeing without having your exact brand of laptop. If you have a 
chance, you could try to instrument 
org/netbeans/swing/plaf/util/SmoothScrollPaneUI.java yourself and see if you 
can find out what's going on. (See 
https://github.com/apache/incubator-netbeans/pull/881 for the original patch). 
But if you don't have time I'm fine with reverting.

-- Eirik

-Original Message-
From: Christian Lenz  
Sent: Wednesday, October 31, 2018 6:12 PM
To: dev@netbeans.incubator.apache.org
Subject: AW: NetBeans 10.0 vc2

And unfortunately the smooth scroll doesn’t work well.
https://imgur.com/a/OmDTmdg (Smooth scrolling NB 10.0 VC2)

It is not that it is not real smooth or doesn’t feel smooth, this is another 
Problem. Here you can see what smooth should be:
(1) https://imgur.com/a/VXoyEGP (Smooth Scrolling in Chrome)
(2) https://imgur.com/a/yVZtX3Z (Smooth Scrolling in VS Code)

Unfortunately, smooth Scrolling doesn’t work in IntelliJ, so I can’t Show it to 
you.

But it is hacky/jitty, it sometimes jumps and the parts, where you can see it 
scrolls only minimal, this is the part where I scroll real wide and not only in 
small steps. So all in all, it should be reverted and needs more investment 
IMHO.

So the implementation doesn’t fit well of what it was shown here: 
https://youtrack.jetbrains.com/issue/IDEA-76396

I have to say, that I use a Surface Book with a touchpad, so no mouse Wheel 
only to let you know.

Cheers

Chris


P.S. if the Screencasts are not working well, I will try to create a Video.



Von: Eirik Bakke
Gesendet: Mittwoch, 31. Oktober 2018 22:01
An: dev@netbeans.incubator.apache.org
Betreff: RE: NetBeans 10.0 vc2

> Well, that's strange. AFAIK I still used the old 9.0 launcher in 
> 10.0vc2
Oh, right. Hmm. Not sure why it happened, then.

-Original Message-
From: Laszlo Kishalmi 
Sent: Wednesday, October 31, 2018 4:59 PM
To: dev@netbeans.incubator.apache.org
Subject: Re: NetBeans 10.0 vc2

Well, that's strange. AFAIK I still used the old 9.0 launcher in 10.0vc2

The new launcher just has been merged into master today. So it will be part of 
vc3

On 10/31/18 1:52 PM, Eirik Bakke wrote:
> I think the Windows Defender thing pops up whenever someone runs an 
> executable that no one (or very few Windows users) has ever run before. Since 
> the launcher executable has recently been updated, this is the case here, but 
> was not the case for the previous launcher (which had been used by many 
> NetBeans users previously).
>
> "Checking downloaded files against a list of files that are well known 
> and downloaded by many Windows users. If the file isn't on that list, 
> SmartScreen shows a warning, advising caution." [1]
>
> So in theory this will go away once a few people have downloaded NetBeans.
>
> -- Eirik
> [1]
> https://docs.microsoft.com/en-us/windows/security/threat-protection/wi
> ndows-defender-smartscreen/windows-defender-smartscreen-overview
>
> -Original Message-
> From: Christian Lenz 
> Sent: Wednesday, October 31, 2018 3:56 PM
> To: dev@netbeans.incubator.apache.org; net...@netbeans.apache.org
> Subject: NetBeans 10.0 vc2
>
> Hey,
>
> I tried to run NB 10.0 VC2. I use the Windows Defender SmartScreen and it was 
> still activated since I don’t know. NetBeans 8.2, NetBeans 9.0 and NetBeans 
> 10.0 VC1 opened very well (NB 10.0 VC1 with the command line but I think that 
> was fixed). Now when I start NB 10.0 VC2 I got the Windows Defender 
> SmartScreen prompt that my PC Prevent the start of an unknown app with only 
> one call to Action called „Don’t execute“. There is a link for „More 
> Information“ where I can still run it. Similar message on pages with http and 
> HTTPS.
>
> So IMHO smth weird happened from VC1 to VC2. Maybe with the HIDPI stuff? Only 
> guessing, I don’t know.
>
>
> Cheers
>
> Chris
>
>
>
>
> -
> 

RE: NetBeans 10.0 vc2

[Eirik Bakke]

> Well, that's strange. AFAIK I still used the old 9.0 launcher in 10.0vc2
Oh, right. Hmm. Not sure why it happened, then.

-Original Message-
From: Laszlo Kishalmi  
Sent: Wednesday, October 31, 2018 4:59 PM
To: dev@netbeans.incubator.apache.org
Subject: Re: NetBeans 10.0 vc2

Well, that's strange. AFAIK I still used the old 9.0 launcher in 10.0vc2

The new launcher just has been merged into master today. So it will be part of 
vc3

On 10/31/18 1:52 PM, Eirik Bakke wrote:
> I think the Windows Defender thing pops up whenever someone runs an 
> executable that no one (or very few Windows users) has ever run before. Since 
> the launcher executable has recently been updated, this is the case here, but 
> was not the case for the previous launcher (which had been used by many 
> NetBeans users previously).
>
> "Checking downloaded files against a list of files that are well known 
> and downloaded by many Windows users. If the file isn't on that list, 
> SmartScreen shows a warning, advising caution." [1]
>
> So in theory this will go away once a few people have downloaded NetBeans.
>
> -- Eirik
> [1] 
> https://docs.microsoft.com/en-us/windows/security/threat-protection/wi
> ndows-defender-smartscreen/windows-defender-smartscreen-overview
>
> -Original Message-
> From: Christian Lenz 
> Sent: Wednesday, October 31, 2018 3:56 PM
> To: dev@netbeans.incubator.apache.org; net...@netbeans.apache.org
> Subject: NetBeans 10.0 vc2
>
> Hey,
>
> I tried to run NB 10.0 VC2. I use the Windows Defender SmartScreen and it was 
> still activated since I don’t know. NetBeans 8.2, NetBeans 9.0 and NetBeans 
> 10.0 VC1 opened very well (NB 10.0 VC1 with the command line but I think that 
> was fixed). Now when I start NB 10.0 VC2 I got the Windows Defender 
> SmartScreen prompt that my PC Prevent the start of an unknown app with only 
> one call to Action called „Don’t execute“. There is a link for „More 
> Information“ where I can still run it. Similar message on pages with http and 
> HTTPS.
>
> So IMHO smth weird happened from VC1 to VC2. Maybe with the HIDPI stuff? Only 
> guessing, I don’t know.
>
>
> Cheers
>
> Chris
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: 
> dev-h...@netbeans.incubator.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.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: NetBeans 10.0 vc2

[Eirik Bakke]

I think the Windows Defender thing pops up whenever someone runs an executable 
that no one (or very few Windows users) has ever run before. Since the launcher 
executable has recently been updated, this is the case here, but was not the 
case for the previous launcher (which had been used by many NetBeans users 
previously).

"Checking downloaded files against a list of files that are well known and 
downloaded by many Windows users. If the file isn't on that list, SmartScreen 
shows a warning, advising caution." [1]

So in theory this will go away once a few people have downloaded NetBeans.

-- Eirik
[1] 
https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-smartscreen/windows-defender-smartscreen-overview

-Original Message-
From: Christian Lenz  
Sent: Wednesday, October 31, 2018 3:56 PM
To: dev@netbeans.incubator.apache.org; net...@netbeans.apache.org
Subject: NetBeans 10.0 vc2

Hey,

I tried to run NB 10.0 VC2. I use the Windows Defender SmartScreen and it was 
still activated since I don’t know. NetBeans 8.2, NetBeans 9.0 and NetBeans 
10.0 VC1 opened very well (NB 10.0 VC1 with the command line but I think that 
was fixed). Now when I start NB 10.0 VC2 I got the Windows Defender SmartScreen 
prompt that my PC Prevent the start of an unknown app with only one call to 
Action called „Don’t execute“. There is a link for „More Information“ where I 
can still run it. Similar message on pages with http and HTTPS.

So IMHO smth weird happened from VC1 to VC2. Maybe with the HIDPI stuff? Only 
guessing, I don’t know.


Cheers

Chris 

RE: recommendation for language support

[Eirik Bakke]

I recommend ANTLR over JavaCC for new projects (I've used both). ANTLR is a 
very good-quality library.

You can use the following adapter class to hook ANTLR’s 
org.antlr.v4.runtime.CharStream interface up to NetBeans’ 
org.netbeans.spi.lexer.LexerInput interface:

https://gist.github.com/eirikbakke/51cf4c9375880acd4741

— Eirik

-Original Message-
From: Mario Schroeder  
Sent: Tuesday, October 30, 2018 3:37 PM
To: dev@netbeans.incubator.apache.org
Subject: recommendation for language support

Hi,

I would appreciate when someone could set me on the right track. I'm wondering 
what is the best way to write a plugin with a support for a new language.

I have found this old tutorial:
http://wiki.netbeans.org/How_to_create_support_for_a_new_language
It uses JavaCC. The tutorial is linked to another one, which makes use of 
ANTLR. When I have a look at NetBeans source code, there are some templates 
written with JFlex. So I'm confused. Which one should I use?

I would prefer ANTLR, since there seems to be more documentation for it.
Does anyone have a recommendation?

Regards,
Mario

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: High level status of Apache NetBeans

[Eirik Bakke]

Very informative interview! Thank you for being a great ambassador and catalyst 
for the community!

-- Eirik

-Original Message-
From: Geertjan Wielenga  
Sent: Wednesday, October 24, 2018 6:14 PM
To: dev 
Subject: High level status of Apache NetBeans

FYI: Small interview with me at Oracle Code One today:

https://www.pscp.tv/w/1YqxoglXEYExv

On Twitter:

https://twitter.com/OracleDevs/status/1055206463809843200

Thanks,

Gj

RE: Maven Artifacts for Release 9

[Eirik Bakke]

I don't think they're hosted yet; the TODO is at 
https://issues.apache.org/jira/browse/NETBEANS-467 . But see my comment at the 
end there for the command required to build them yourself.

-- Eirik

-Original Message-
From: Mario Schroeder  
Sent: Tuesday, October 23, 2018 1:15 PM
To: dev@netbeans.incubator.apache.org
Subject: Maven Artifacts for Release 9

Hi,

I wanted to start creating a plugin as a tutorial using Maven for the book.
However I can't find the dependecies for release 9 of NetBeans. The latest 
version in the public repository is 8.2. I'm using this url:
http://bits.netbeans.org/nexus/content/groups/netbeans/ Did it move? Or is it 
not available yet? What am I missing?

Thanks for help in advance.

RE: Some info for NetBeans 10 VC 1

[Eirik Bakke]

Oh, sorry--I didn't see that. I had a look at it just now.

The output you pasted there seems to be from a single-monitor configuration. 
Could you set up your multi-monitor setup and reproduce the bug again, and then 
run the PrintGC application again once you know the bug is present?

-- Eirik

-Original Message-
From: Christian Lenz  
Sent: Thursday, October 18, 2018 3:40 AM
To: dev@netbeans.incubator.apache.org
Subject: AW: Some info for NetBeans 10 VC 1

Hey Eirik,

did you have a look into my Output, that I pasted below your gist?


Cheers

Chris



Von: Eirik Bakke
Gesendet: Donnerstag, 4. Oktober 2018 19:59
An: dev@netbeans.incubator.apache.org
Betreff: RE: Some info for NetBeans 10 VC 1

Regarding 1: This is likely a JDK bug. Could you run the application at 
https://gist.github.com/eirikbakke/b85b67dae62993e3cbee51e4c9e6c214 and provide 
the output?

-- Eirik

-Original Message-
From: Christian Lenz  
Sent: Thursday, October 4, 2018 12:01 PM
To: dev@netbeans.incubator.apache.org
Subject: Some info for NetBeans 10 VC 1

Hey,

as I’m testing the PHP specs I have some Questions/Infos in General, not for 
PHP:

1. See this screenshot (https://imgur.com/a/uKgS0Y9) of a Multi monitor, I have 
a Laptop and 2 monitors. When I move NetBeans 10 to the Right monitor and open 
File, it will appears on the other monitor. I mean it is not a blocker or 
critical but not nice. We should fix it but hopefully not for NetBeans 10.1 or 
11, Maybe a patch would be nice that can handle this. Will create a ticket for 
that, if there isn’t one yet.

2. The Little Checkbox inside the Plugin Portal went back to NetBeans 10.0, but 
it was removed in 9.0 what is the current state now? I was fine to not have 
this Checkbox anymore, because it is not Handy. I mean for the next realease 
(of Course, I will create a ticket) the view could be a tree to see the Groups 
(Show Details off) and if you expand it or click on Show Details you see 
everything. But this is a complete other Point. Only wanted to know whether the 
Checkbox is back again or it was added again by mistake.

3. I thought that Groovy and PHP are the only packages which went into NB 10.0. 
Now I can see that HTML5/JS which is webcommon, is also included into the 
release, I mean which is quite nice for me but we don’t have a tribe or test or 
smth else. Why was it included then? Is it needed for PHP? If not we should 
make a tribe for the release because it is now part of the core. Doesn’t matter 
new Features where added or Bugs where fixed.

These are my Little Things for the Moment. Thx.


Cheers

Chris 

RE: Hacktoberfest

[Eirik Bakke]

I suspect having two issue trackers active at the same time would become very 
messy. Some bugs will have JIRA issue numbers, others will have 
GitHub-generated issue numbers, some bugs will exist in just one system, some 
in both etc. And if people can file bugs without being aware of JIRA, there 
will be more duplicates filed (as you mention). And there would not be an easy 
way to mark a bug as a duplicate of a bug in the other system. And bug 
discussions would be split between two systems. And people without JIRA 
accounts would not be able to follow JIRA bugs. And so on.

I'd encourage sticking to just JIRA as the official "system of record", 
pointing people there to file new bugs.

-- Eirik

-Original Message-
From: Christian Lenz  
Sent: Thursday, October 18, 2018 3:46 AM
To: dev@netbeans.incubator.apache.org
Subject: AW: Hacktoberfest

Maybe it is to late but we also should activate the GitHub issues again. I 
asked in the infrachat and if I understand it correct, there is no Problem 
while using GitHub as an issue Tracker too.

It seems possible to create jira tickets from GitHub issues, but not vice versa 
(Plugin missing, must be written, etc.) to cover the Basic stuff. I know that 
jira and GitHub issues are very different Systems, but for Basic Generation of 
issues, that could be possible. Anyway, we will also have the Problem of 
duplicates.

So is there anything else, what doesn’t make sense to Show issues on the 
incubator-netbeans repo? A lot more People will create tickets on the favorite 
repo System, instead of creating a JIRA account. And, again the issue section 
will help us with the next hacktoberfest, where we can have Benefits out of it.


Cheers

Chris



Von: Christian Lenz
Gesendet: Dienstag, 2. Oktober 2018 09:48
An: dev@netbeans.incubator.apache.org
Betreff: Hacktoberfest

Hey,

I didn’t know how it was handled but the repos add the label hacktoberfest to 
their issues. The problem with our repo is, that we don’t show our issues, 
because it is in jira. I don’t know whether it is possible to sync issues from 
jira to GitHub, to Benefit from the hacktoberfest. 

Don’t know whether it is to late and to much effort, Maybe next year 😃.


Cheers

Chris



-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: different FileChooser behavior with JDK 11.0.1 on Windows than with 11.0.0

[Eirik Bakke]

> [weird] behavior when I tried to open a new project
> What does the NetBeans FileChooser different than the default Java one?

The "Open Project" file chooser contains special logic to recognize NetBeans 
project folders as such, so that they can be displayed with a proper icon, and 
so that double-clicking said folders will open the project rather than descend 
into the folder. There's also a "Project Name" and "Open Required Projects" 
pane added to the file chooser.

> Am I the only one with this problem?
I managed to reproduce it on my Windows 10 machine. As you say, I had to use 
the latest OpenJDK 11.0.1 (from https://jdk.java.net/11/ ), and I had to create 
an intentionally broken shortcut (to a file or a folder--doesn't matter) on my 
desktop.

Please feel free to add a JIRA issue for this (under the NETBEANS project at 
https://issues.apache.org ).

To investigate a bug like this, first find the NetBeans module that implements 
the custom file chooser. The easiest way is to search for a UI string that 
occurs in said file chooser; I'd go for "Open Required Projects". Though if you 
look carefully, you'll see there's a mnemonic underline under the "R", so you'd 
have to search for a UI string matching "Open &Required Projects" in this case 
(there's a convention where an '&' symbol before a character in a UI string 
becomes that component's keyboard mnemonic character on WIndows). So I do:

git grep 'Open &Required Projects'

which gives me

ide/projectui/src/org/netbeans/modules/project/ui/Bundle.properties:LBL_PrjChooser_Subprojects_CheckBox=Open
 &Required Projects\:

So the module to investigate in is ide/projectui.

If you do "ant" once in the incubator-netbeans folder, you'll build the entire 
IDE, after which you can run the freshly built IDE using "ant tryme". 
Subsequently, if you make changes in the ide/projectui module for testing 
purposes, it's sufficient to just run "ant" in that folder again to save time; 
"ant tryme" from the incubator-netbeans root will then use the updated code. 
I'd start by inserting print statements to try to localize the code that causes 
the dialog to pop up.

-- Eirik

-Original Message-
From: Jens Hofschröer  
Sent: Wednesday, October 17, 2018 8:48 AM
To: dev@netbeans.incubator.apache.org
Subject: different FileChooser behavior with JDK 11.0.1 on Windows than with 
11.0.0

Hi

I wanted to test the current JDK 11.0.1 in our RCP application and found a 
wired behavior when I tried to open a new project. I got spammed with error 
messages that various (Windows-)links on my Desktop are no longer valid and if 
I want to remove them.

These messages are OS-messages and occur normally when you try to open an file 
or application via a .lnk file and the destination does no longer exist. A 
valid message for an invalid file. But these messages only occur if you 
actively click on these abandoned shortcuts, never when you just view them in a 
directory listing.

/!\ This behavior is specific to the NetBeans FileChooser and the 11.0.1 
release. There is no regression in plain Swing applications and the default 
JFileChooser. There were no regressions with the JDK11+23 build of OpenJDK.

I tried OpenJDK and OracleJDK since Azul and AdoptJDK do not provide a recent 
build.

Java: 11.0.1; OpenJDK 64-Bit Server VM 11.0.1+13
Java: 11.0.1; Java HotSpot(TM) 64-Bit Server VM 11.0.1+13-LTS

Also this is not specific to NB10. I tried NB8.2, NB9 and NB10 together with 
our RCP based on NB8.2 and NB9

System: Windows 7 Version 6.1 läuft auf amd64; Cp1252; de_DE

I don't know where to start digging the problem. What does the NetBeans 
FileChooser different than the default Java one? What change was done to Java? 
I could not find a hint on this. Am I the only one with this problem?

Greetings
Jens


--
http://blog.nigjo.de/netbeans/

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: NetBeans Default Maximum HeapSize

[Eirik Bakke]

Also beware that the default maximum heap size calculation exists in two 
places, both which would need to be updated here:
* For Windows, in NbLauncher::adjustHeapAndPermGenSize() in 
nb/ide.launcher/windows/nblauncher.cpp
* On Linux and MacOS, in nb/ide.launcher/unix/netbeans

(As an aside, it would be nice for the heap size calculation logic in 
nblauncher.cpp to be factored out to also work for the NetBeans platform 
application launcher, in 
harness/apisupport.harness/windows-launcher-src/applauncher.cpp . But that's a 
separate issue.)

-- Eirik

-Original Message-
From: Laszlo Kishalmi  
Sent: Sunday, October 7, 2018 2:37 PM
To: dev@netbeans.incubator.apache.org
Subject: Re: NetBeans Default Maximum HeapSize

Fixed the subject to be more accurate.

On 10/07/2018 11:31 AM, Eirik Bakke wrote:
> TL;DR: I would increase Xmx to 50% of system memory by default.
>
>> Right now NetBeans calculates it's default heap size on 20% of the system 
>> memory, but cap it on 1Gb.
> It's worse than that--this is the _maximum_ heap size, not the default (at 
> least on MacOS on Linux).
>
> I ran on the default for years, but eventually started setting a much higher 
> limit in netbeans.conf. This improved NetBeans performance greatly, and got 
> rid of some very annoying errors where some NetBeans-invoked maven process 
> would run out of memory.
>
> I'd say put the maximum at 50% of system memory. The JVM won't actually use 
> that much unless it needs it. And even if it uses it all, it can still be 
> swapped out by the OS if other processes needs it. Swapping is probably 
> better than constantly running the garbage collector to reclaim space (though 
> Java performance tuning experts might chime in on this latter theory).
>
> Photoshop, for comparison, uses up to 70% of system memory by default (a 
> setting in Preferences->Performance->Memory Usage). I frequently run both 
> Photoshop and NetBeans concurrently and have no issues, even though both are 
> configured to use up to 70% and 50% of system memory, respectively. (This was 
> the case both on my old MacBook Air with 8GB RAM and on my newer Lenovo 
> Windows 10 machine with 16GB RAM.)
>
> -- Eirik
>
> -Original Message-
> From: Laszlo Kishalmi 
> Sent: Saturday, October 6, 2018 6:51 PM
> To: dev@netbeans.incubator.apache.org
> Subject: NetBeand Default HeapSize
>
> Hi there,
>
> Right now NetBeans calculates it's default heap size on 20% of the system 
> memory, but cap it on 1Gb.
>
> Is it usually enough? Most of my machines have 16Gb ram and one of the first 
> things I do is to set the heap limit to 2Gb or more. I thing the
> 20 % is good, but we might move the cap to 2,3 or 4 Gb, so we do not need to 
> meddle with netbeans.conf.
>
> What's your Opinion?
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: NetBeand Default HeapSize

[Eirik Bakke]

TL;DR: I would increase Xmx to 50% of system memory by default.

> Right now NetBeans calculates it's default heap size on 20% of the system 
> memory, but cap it on 1Gb.

It's worse than that--this is the _maximum_ heap size, not the default (at 
least on MacOS on Linux).

I ran on the default for years, but eventually started setting a much higher 
limit in netbeans.conf. This improved NetBeans performance greatly, and got rid 
of some very annoying errors where some NetBeans-invoked maven process would 
run out of memory. 

I'd say put the maximum at 50% of system memory. The JVM won't actually use 
that much unless it needs it. And even if it uses it all, it can still be 
swapped out by the OS if other processes needs it. Swapping is probably better 
than constantly running the garbage collector to reclaim space (though Java 
performance tuning experts might chime in on this latter theory).

Photoshop, for comparison, uses up to 70% of system memory by default (a 
setting in Preferences->Performance->Memory Usage). I frequently run both 
Photoshop and NetBeans concurrently and have no issues, even though both are 
configured to use up to 70% and 50% of system memory, respectively. (This was 
the case both on my old MacBook Air with 8GB RAM and on my newer Lenovo Windows 
10 machine with 16GB RAM.)

-- Eirik

-Original Message-
From: Laszlo Kishalmi  
Sent: Saturday, October 6, 2018 6:51 PM
To: dev@netbeans.incubator.apache.org
Subject: NetBeand Default HeapSize

Hi there,

Right now NetBeans calculates it's default heap size on 20% of the system 
memory, but cap it on 1Gb.

Is it usually enough? Most of my machines have 16Gb ram and one of the first 
things I do is to set the heap limit to 2Gb or more. I thing the
20 % is good, but we might move the cap to 2,3 or 4 Gb, so we do not need to 
meddle with netbeans.conf.

What's your Opinion?




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: Some info for NetBeans 10 VC 1

[Eirik Bakke]

Regarding 1: This is likely a JDK bug. Could you run the application at 
https://gist.github.com/eirikbakke/b85b67dae62993e3cbee51e4c9e6c214 and provide 
the output?

-- Eirik

-Original Message-
From: Christian Lenz  
Sent: Thursday, October 4, 2018 12:01 PM
To: dev@netbeans.incubator.apache.org
Subject: Some info for NetBeans 10 VC 1

Hey,

as I’m testing the PHP specs I have some Questions/Infos in General, not for 
PHP:

1. See this screenshot (https://imgur.com/a/uKgS0Y9) of a Multi monitor, I have 
a Laptop and 2 monitors. When I move NetBeans 10 to the Right monitor and open 
File, it will appears on the other monitor. I mean it is not a blocker or 
critical but not nice. We should fix it but hopefully not for NetBeans 10.1 or 
11, Maybe a patch would be nice that can handle this. Will create a ticket for 
that, if there isn’t one yet.

2. The Little Checkbox inside the Plugin Portal went back to NetBeans 10.0, but 
it was removed in 9.0 what is the current state now? I was fine to not have 
this Checkbox anymore, because it is not Handy. I mean for the next realease 
(of Course, I will create a ticket) the view could be a tree to see the Groups 
(Show Details off) and if you expand it or click on Show Details you see 
everything. But this is a complete other Point. Only wanted to know whether the 
Checkbox is back again or it was added again by mistake.

3. I thought that Groovy and PHP are the only packages which went into NB 10.0. 
Now I can see that HTML5/JS which is webcommon, is also included into the 
release, I mean which is quite nice for me but we don’t have a tribe or test or 
smth else. Why was it included then? Is it needed for PHP? If not we should 
make a tribe for the release because it is now part of the core. Doesn’t matter 
new Features where added or Bugs where fixed.

These are my Little Things for the Moment. Thx.


Cheers

Chris 

RE: Blurry font with NetBeans 9.0

[Eirik Bakke]

The other Windows HiDPI bug I mentioned before, where checkboxes, radio buttons 
and so on become too small or too large when moved from one monitor to another, 
has now been assigned a JDK JIRA ticket:

https://bugs.openjdk.java.net/browse/JDK-8211715
(And see https://people.csail.mit.edu/ebakke/WindowsSwingMultiMonitorTest.png 
for an illustration.)

This one creates some quite annoying visual artifacts in the NetBeans Projects 
pane, but we probably have to wait for the underlying problem to be fixed in 
the JDK.

-- Eirik

-Original Message-
From: Eirik Bakke 
Sent: Tuesday, September 18, 2018 9:52 AM
To: 'dev@netbeans.incubator.apache.org' 
Subject: RE: Blurry font with NetBeans 9.0

There's another remaining problem where checkboxes, radio buttons and so on 
become too small or too large on one of the monitors. That one is a JDK bug, 
which I have reported on https://bugreport.java.com/bugreport (though it has 
not been assigned a JDK JIRA ticket yet).

-- Eirik

-Original Message-
From: Christian Lenz 
Sent: Tuesday, September 18, 2018 9:44 AM
To: dev@netbeans.incubator.apache.org
Subject: AW: Blurry font with NetBeans 9.0

Ok yes, now everything is fine, except from the titlebar 😃 It is huge now on 
non HiDPI Monitors, but you mentioned it before. The rest is fine, no blurry, 
no Problems on HiDPI or non HiDPI Monitors. But the titlebar is weird.

Thx.



Von: Christian Lenz
Gesendet: Dienstag, 18. September 2018 15:38
An: dev@netbeans.incubator.apache.org
Betreff: AW: Blurry font with NetBeans 9.0

Ok, will Change it. I thought I Need dpiAware=false and uiScale=2 AND the 
Override high DPI scaling behaviour -> Application.
Thx. Will try this.



Von: Eirik Bakke
Gesendet: Dienstag, 18. September 2018 15:31
An: dev@netbeans.incubator.apache.org
Betreff: RE: Blurry font with NetBeans 9.0

Hmm, I haven't seen that problem before. Except for the title bar--I know it 
becomes huge or tiny at times (that particular problem will also be solved with 
NETBEANS-1227).

Might you still be running with "dpiAware=false" and "uiScale=2"? Those two 
should not be needed once you apply the "Override high DPI scaling 
behavior"-->"Application" trick--in fact they would likely cause problems.

-- Eirik

-Original Message-
From: Christian Lenz 
Sent: Tuesday, September 18, 2018 9:13 AM
To: dev@netbeans.incubator.apache.org
Subject: AW: Blurry font with NetBeans 9.0

Yes, so again I don’t have Problems with HiDPI anymore. No Blurry font, no to 
small or to big, but when I move my window to a non HiDPI monitor and with an 
other Resolution, it will gets really big.



Von: Eirik Bakke
Gesendet: Dienstag, 18. September 2018 15:09
An: dev@netbeans.incubator.apache.org
Betreff: RE: Blurry font with NetBeans 9.0

Did you try the "Compatibility"-->"Change high DPI settings"-->"Override high 
DPI scaling behavior"-->"Application" trick?

(Once https://issues.apache.org/jira/browse/NETBEANS-1227 is resolved, this 
workaround will become unnecessary.)

-- Eirik

-Original Message-
From: Christian Lenz 
Sent: Tuesday, September 18, 2018 8:39 AM
To: dev@netbeans.incubator.apache.org
Subject: AW: Blurry font with NetBeans 9.0

Is there anything else, what I can do here to Prevent making NetBeans bigger on 
a non HiDPI monitor, when I move the window?


Cheers

Chris



Von: Christian Lenz
Gesendet: Donnerstag, 13. September 2018 15:56
An: dev@netbeans.incubator.apache.org
Betreff: AW: Blurry font with NetBeans 9.0

Update:

dpiAware=false
uiScale=2

Settings via compatibilty for the OS, the application should handle it and 
override the dpi scale if it is to high.

Now, everything Looks fine, on the Surface book with the hidpi Display, but 
when I move my NetBeans window to a different monitor, w/o having retina or 
hidpi, everything is too big.

Someone mentioned it here before so how can I fix this?

So Long Story short, everything is fine for hidpi Display but not for normal 
Displays. I use both in parallel.


Cheers

Chris



Von: Christian Lenz
Gesendet: Montag, 10. September 2018 11:53
An: dev@netbeans.incubator.apache.org
Betreff: AW: Blurry font with NetBeans 9.0

Hey all,

so it seems to work now. I use JDK 10.0.2 and the uiScale=2 and dpiAware=false 
and the scaling compatibilty Option of Windows.
Thx to all. Will check whether it will work with the darcula laf or not.


Cheers

Chris

Von: Christian Lenz
Gesendet: Montag, 10. September 2018 11:20
An: dev@netbeans.incubator.apache.org
Betreff: AW: Blurry font with NetBeans 9.0

Hey Tim,

which zoom do you mean? If you mean the Windows scaling (zoom) this is not 
possible, as I said. Because everything is to small, not only NetBeans. I 
didn’t need to Change anything in IntelliJ and there it works well and out of 
the box, I don’t know why I have to do such stuff for NetBeans.

When I add those flags for dpiaware and

RE: Some info for NetBeans 10 VC 1

[Eirik Bakke]

Also, Christian: For testing purposes, please make sure you are running 
NetBeans with the "Compatibility"-->"Change high DPI settings"-->"Override high 
DPI scaling behavior"-->"Application" trick we discussed before if you have 
HiDPI screens in your setup. (Again, this will be the default setting in the 
future.) I see from your screenshot that your menu bar is blurry (but not the 
title bar), suggesting an incorrect HiDPI setting.

-Original Message-
From: Eirik Bakke 
Sent: Thursday, October 4, 2018 1:41 PM
To: 'dev@netbeans.incubator.apache.org' 
Subject: RE: Some info for NetBeans 10 VC 1

Regarding 1: This is likely a JDK bug. Could you run the application at 
https://gist.github.com/eirikbakke/b85b67dae62993e3cbee51e4c9e6c214 and provide 
the output?

-- Eirik

-Original Message-
From: Christian Lenz  
Sent: Thursday, October 4, 2018 12:01 PM
To: dev@netbeans.incubator.apache.org
Subject: Some info for NetBeans 10 VC 1

Hey,

as I’m testing the PHP specs I have some Questions/Infos in General, not for 
PHP:

1. See this screenshot (https://imgur.com/a/uKgS0Y9) of a Multi monitor, I have 
a Laptop and 2 monitors. When I move NetBeans 10 to the Right monitor and open 
File, it will appears on the other monitor. I mean it is not a blocker or 
critical but not nice. We should fix it but hopefully not for NetBeans 10.1 or 
11, Maybe a patch would be nice that can handle this. Will create a ticket for 
that, if there isn’t one yet.

2. The Little Checkbox inside the Plugin Portal went back to NetBeans 10.0, but 
it was removed in 9.0 what is the current state now? I was fine to not have 
this Checkbox anymore, because it is not Handy. I mean for the next realease 
(of Course, I will create a ticket) the view could be a tree to see the Groups 
(Show Details off) and if you expand it or click on Show Details you see 
everything. But this is a complete other Point. Only wanted to know whether the 
Checkbox is back again or it was added again by mistake.

3. I thought that Groovy and PHP are the only packages which went into NB 10.0. 
Now I can see that HTML5/JS which is webcommon, is also included into the 
release, I mean which is quite nice for me but we don’t have a tribe or test or 
smth else. Why was it included then? Is it needed for PHP? If not we should 
make a tribe for the release because it is now part of the core. Doesn’t matter 
new Features where added or Bugs where fixed.

These are my Little Things for the Moment. Thx.


Cheers

Chris 

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: Pull Request review before NetBeans 10!

[Eirik Bakke]

I just tried 10vc1 and can confirm that NETBEANS-1308 (Windows launcher fails 
to suppress console) is still present.

-- Eirik

-Original Message-
From: Eirik Bakke  
Sent: Sunday, September 30, 2018 9:09 PM
To: dev@netbeans.incubator.apache.org
Subject: RE: Pull Request review before NetBeans 10!

Beware that the Windows launcher seems to have a bug, where the console is not 
suppressed when the EXE file is launched from a shortcut or from the Windows 
explorer. That was two weeks ago--I reported this as 
https://issues.apache.org/jira/browse/NETBEANS-1308 . For anyone who tries the 
latest launcher again, could you see if you still observe this problem?

For anyone who tests "[NETBEANS-1227] Mark Windows launchers as DPI-aware", 
also feel free to test https://github.com/apache/incubator-netbeans/pull/859 , 
which introduces HiDPI icons in the window system ("X" buttons in tabs etc.). 
That one should be ready to merge, if no one objects to the API change (add a 
new public abstract class VectorIcon to org.openide.util.ui Utilities API, for 
use by other modules that want to provide custom-painted HiDPI icons).

-- Eirik

-Original Message-
From: Laszlo Kishalmi  
Sent: Sunday, September 30, 2018 2:34 AM
To: dev@netbeans.incubator.apache.org
Subject: Pull Request review before NetBeans 10!

Dear all,

There are several PR-s out there, please review and merge everything safely can 
be made!

We are about to branch for release 10 tomorrow.

I  specially ask for help in combing and testing three of our windows launcher 
related ones:

 1. [NETBEANS-1227] Mark Windows launchers as DPI-aware
<https://github.com/apache/incubator-netbeans/pull/883>
 2. [NETBEANS-1157] resolved problem with java version higher 9 and the
n… <https://github.com/apache/incubator-netbeans/pull/734>

I do not have Windows around me to test these out.


Laszlo Kishalmi

Volunteer Release Manager of NetBeans 10


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: Pull Request review before NetBeans 10!

[Eirik Bakke]

Beware that the Windows launcher seems to have a bug, where the console is not 
suppressed when the EXE file is launched from a shortcut or from the Windows 
explorer. That was two weeks ago--I reported this as 
https://issues.apache.org/jira/browse/NETBEANS-1308 . For anyone who tries the 
latest launcher again, could you see if you still observe this problem?

For anyone who tests "[NETBEANS-1227] Mark Windows launchers as DPI-aware", 
also feel free to test https://github.com/apache/incubator-netbeans/pull/859 , 
which introduces HiDPI icons in the window system ("X" buttons in tabs etc.). 
That one should be ready to merge, if no one objects to the API change (add a 
new public abstract class VectorIcon to org.openide.util.ui Utilities API, for 
use by other modules that want to provide custom-painted HiDPI icons).

-- Eirik

-Original Message-
From: Laszlo Kishalmi  
Sent: Sunday, September 30, 2018 2:34 AM
To: dev@netbeans.incubator.apache.org
Subject: Pull Request review before NetBeans 10!

Dear all,

There are several PR-s out there, please review and merge everything safely can 
be made!

We are about to branch for release 10 tomorrow.

I  specially ask for help in combing and testing three of our windows launcher 
related ones:

 1. [NETBEANS-1227] Mark Windows launchers as DPI-aware

 2. [NETBEANS-1157] resolved problem with java version higher 9 and the
n… 

I do not have Windows around me to test these out.


Laszlo Kishalmi

Volunteer Release Manager of NetBeans 10


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: Blurry font with NetBeans 9.0

[Eirik Bakke]

There's another remaining problem where checkboxes, radio buttons and so on 
become too small or too large on one of the monitors. That one is a JDK bug, 
which I have reported on https://bugreport.java.com/bugreport (though it has 
not been assigned a JDK JIRA ticket yet).

-- Eirik

-Original Message-
From: Christian Lenz  
Sent: Tuesday, September 18, 2018 9:44 AM
To: dev@netbeans.incubator.apache.org
Subject: AW: Blurry font with NetBeans 9.0

Ok yes, now everything is fine, except from the titlebar 😃 It is huge now on 
non HiDPI Monitors, but you mentioned it before. The rest is fine, no blurry, 
no Problems on HiDPI or non HiDPI Monitors. But the titlebar is weird.

Thx.



Von: Christian Lenz
Gesendet: Dienstag, 18. September 2018 15:38
An: dev@netbeans.incubator.apache.org
Betreff: AW: Blurry font with NetBeans 9.0

Ok, will Change it. I thought I Need dpiAware=false and uiScale=2 AND the 
Override high DPI scaling behaviour -> Application.
Thx. Will try this.



Von: Eirik Bakke
Gesendet: Dienstag, 18. September 2018 15:31
An: dev@netbeans.incubator.apache.org
Betreff: RE: Blurry font with NetBeans 9.0

Hmm, I haven't seen that problem before. Except for the title bar--I know it 
becomes huge or tiny at times (that particular problem will also be solved with 
NETBEANS-1227).

Might you still be running with "dpiAware=false" and "uiScale=2"? Those two 
should not be needed once you apply the "Override high DPI scaling 
behavior"-->"Application" trick--in fact they would likely cause problems.

-- Eirik

-Original Message-
From: Christian Lenz 
Sent: Tuesday, September 18, 2018 9:13 AM
To: dev@netbeans.incubator.apache.org
Subject: AW: Blurry font with NetBeans 9.0

Yes, so again I don’t have Problems with HiDPI anymore. No Blurry font, no to 
small or to big, but when I move my window to a non HiDPI monitor and with an 
other Resolution, it will gets really big.



Von: Eirik Bakke
Gesendet: Dienstag, 18. September 2018 15:09
An: dev@netbeans.incubator.apache.org
Betreff: RE: Blurry font with NetBeans 9.0

Did you try the "Compatibility"-->"Change high DPI settings"-->"Override high 
DPI scaling behavior"-->"Application" trick?

(Once https://issues.apache.org/jira/browse/NETBEANS-1227 is resolved, this 
workaround will become unnecessary.)

-- Eirik

-Original Message-
From: Christian Lenz 
Sent: Tuesday, September 18, 2018 8:39 AM
To: dev@netbeans.incubator.apache.org
Subject: AW: Blurry font with NetBeans 9.0

Is there anything else, what I can do here to Prevent making NetBeans bigger on 
a non HiDPI monitor, when I move the window?


Cheers

Chris



Von: Christian Lenz
Gesendet: Donnerstag, 13. September 2018 15:56
An: dev@netbeans.incubator.apache.org
Betreff: AW: Blurry font with NetBeans 9.0

Update:

dpiAware=false
uiScale=2

Settings via compatibilty for the OS, the application should handle it and 
override the dpi scale if it is to high.

Now, everything Looks fine, on the Surface book with the hidpi Display, but 
when I move my NetBeans window to a different monitor, w/o having retina or 
hidpi, everything is too big.

Someone mentioned it here before so how can I fix this?

So Long Story short, everything is fine for hidpi Display but not for normal 
Displays. I use both in parallel.


Cheers

Chris



Von: Christian Lenz
Gesendet: Montag, 10. September 2018 11:53
An: dev@netbeans.incubator.apache.org
Betreff: AW: Blurry font with NetBeans 9.0

Hey all,

so it seems to work now. I use JDK 10.0.2 and the uiScale=2 and dpiAware=false 
and the scaling compatibilty Option of Windows.
Thx to all. Will check whether it will work with the darcula laf or not.


Cheers

Chris

Von: Christian Lenz
Gesendet: Montag, 10. September 2018 11:20
An: dev@netbeans.incubator.apache.org
Betreff: AW: Blurry font with NetBeans 9.0

Hey Tim,

which zoom do you mean? If you mean the Windows scaling (zoom) this is not 
possible, as I said. Because everything is to small, not only NetBeans. I 
didn’t need to Change anything in IntelliJ and there it works well and out of 
the box, I don’t know why I have to do such stuff for NetBeans.

When I add those flags for dpiaware and uiScale, Nothing work anymore. NetBeans 
started and it disappears but runs in Background. Removed all Folders for 
NetBeans completely. After I open the exe again, I got an empty Dialog.


Cheers

Chris

Von: Tim Boudreau
Gesendet: Freitag, 7. September 2018 19:48
An: dev@netbeans.incubator.apache.org
Betreff: Re: Blurry font with NetBeans 9.0

Add --fontsize 24 (or whatever size works) to your netbeans.conf and turn off 
zoom.

Of course fonts will look fuzzy when zoomed - you are making the logical pixels 
take up more than one physical pixel.

There are a couple of system properties that may be useful to tell AWT as well.

I have been running NetBeans for years on a high dpi screen. Zo

RE: Blurry font with NetBeans 9.0

[Eirik Bakke]

Hmm, I haven't seen that problem before. Except for the title bar--I know it 
becomes huge or tiny at times (that particular problem will also be solved with 
NETBEANS-1227).

Might you still be running with "dpiAware=false" and "uiScale=2"? Those two 
should not be needed once you apply the "Override high DPI scaling 
behavior"-->"Application" trick--in fact they would likely cause problems.

-- Eirik

-Original Message-
From: Christian Lenz  
Sent: Tuesday, September 18, 2018 9:13 AM
To: dev@netbeans.incubator.apache.org
Subject: AW: Blurry font with NetBeans 9.0

Yes, so again I don’t have Problems with HiDPI anymore. No Blurry font, no to 
small or to big, but when I move my window to a non HiDPI monitor and with an 
other Resolution, it will gets really big.



Von: Eirik Bakke
Gesendet: Dienstag, 18. September 2018 15:09
An: dev@netbeans.incubator.apache.org
Betreff: RE: Blurry font with NetBeans 9.0

Did you try the "Compatibility"-->"Change high DPI settings"-->"Override high 
DPI scaling behavior"-->"Application" trick?

(Once https://issues.apache.org/jira/browse/NETBEANS-1227 is resolved, this 
workaround will become unnecessary.)

-- Eirik

-Original Message-
From: Christian Lenz 
Sent: Tuesday, September 18, 2018 8:39 AM
To: dev@netbeans.incubator.apache.org
Subject: AW: Blurry font with NetBeans 9.0

Is there anything else, what I can do here to Prevent making NetBeans bigger on 
a non HiDPI monitor, when I move the window?


Cheers

Chris



Von: Christian Lenz
Gesendet: Donnerstag, 13. September 2018 15:56
An: dev@netbeans.incubator.apache.org
Betreff: AW: Blurry font with NetBeans 9.0

Update:

dpiAware=false
uiScale=2

Settings via compatibilty for the OS, the application should handle it and 
override the dpi scale if it is to high.

Now, everything Looks fine, on the Surface book with the hidpi Display, but 
when I move my NetBeans window to a different monitor, w/o having retina or 
hidpi, everything is too big.

Someone mentioned it here before so how can I fix this?

So Long Story short, everything is fine for hidpi Display but not for normal 
Displays. I use both in parallel.


Cheers

Chris



Von: Christian Lenz
Gesendet: Montag, 10. September 2018 11:53
An: dev@netbeans.incubator.apache.org
Betreff: AW: Blurry font with NetBeans 9.0

Hey all,

so it seems to work now. I use JDK 10.0.2 and the uiScale=2 and dpiAware=false 
and the scaling compatibilty Option of Windows.
Thx to all. Will check whether it will work with the darcula laf or not.


Cheers

Chris

Von: Christian Lenz
Gesendet: Montag, 10. September 2018 11:20
An: dev@netbeans.incubator.apache.org
Betreff: AW: Blurry font with NetBeans 9.0

Hey Tim,

which zoom do you mean? If you mean the Windows scaling (zoom) this is not 
possible, as I said. Because everything is to small, not only NetBeans. I 
didn’t need to Change anything in IntelliJ and there it works well and out of 
the box, I don’t know why I have to do such stuff for NetBeans.

When I add those flags for dpiaware and uiScale, Nothing work anymore. NetBeans 
started and it disappears but runs in Background. Removed all Folders for 
NetBeans completely. After I open the exe again, I got an empty Dialog.


Cheers

Chris

Von: Tim Boudreau
Gesendet: Freitag, 7. September 2018 19:48
An: dev@netbeans.incubator.apache.org
Betreff: Re: Blurry font with NetBeans 9.0

Add --fontsize 24 (or whatever size works) to your netbeans.conf and turn off 
zoom.

Of course fonts will look fuzzy when zoomed - you are making the logical pixels 
take up more than one physical pixel.

There are a couple of system properties that may be useful to tell AWT as well.

I have been running NetBeans for years on a high dpi screen. Zoom is not the 
solution.

-Tim

On Fri, Sep 7, 2018 at 10:21 AM Eirik Bakke  wrote:

> I have added https://issues.apache.org/jira/browse/NETBEANS-1227 to 
> indicate that the NetBeans launcher should eventually declare itself 
> as DPI-aware, like JDKs javaw.exe already does.
>
> -- Eirik
>
> -Original Message-
> From: Eirik Bakke 
> Sent: Friday, September 7, 2018 9:48 AM
> To: dev@netbeans.incubator.apache.org
> Subject: RE: Blurry font with NetBeans 9.0
>
> Hi, Christian.
>
> I have NetBeans 9.0 running very well on a Windows 10 HiDPI screen at 
> either 150% or 200% scaling. It's essential to use the latest Java--I 
> use 10.0.2. You also need to right click the "bin\netbeans64.exe"
> file, or whichever shortcut you're using to open NetBeans, go to the 
> "Compatibility"
> tab, click "Change high DPI settings", "Override high DPI scaling 
> behavior", and select scaling performed by "Application". (This should 
> probably be built into the launcher at some point.)
>
> -- Eirik
>
> -Original Mes

RE: Blurry font with NetBeans 9.0

[Eirik Bakke]

Did you try the "Compatibility"-->"Change high DPI settings"-->"Override high 
DPI scaling behavior"-->"Application" trick?

(Once https://issues.apache.org/jira/browse/NETBEANS-1227 is resolved, this 
workaround will become unnecessary.)

-- Eirik

-Original Message-
From: Christian Lenz  
Sent: Tuesday, September 18, 2018 8:39 AM
To: dev@netbeans.incubator.apache.org
Subject: AW: Blurry font with NetBeans 9.0

Is there anything else, what I can do here to Prevent making NetBeans bigger on 
a non HiDPI monitor, when I move the window?


Cheers

Chris



Von: Christian Lenz
Gesendet: Donnerstag, 13. September 2018 15:56
An: dev@netbeans.incubator.apache.org
Betreff: AW: Blurry font with NetBeans 9.0

Update:

dpiAware=false
uiScale=2

Settings via compatibilty for the OS, the application should handle it and 
override the dpi scale if it is to high.

Now, everything Looks fine, on the Surface book with the hidpi Display, but 
when I move my NetBeans window to a different monitor, w/o having retina or 
hidpi, everything is too big.

Someone mentioned it here before so how can I fix this?

So Long Story short, everything is fine for hidpi Display but not for normal 
Displays. I use both in parallel.


Cheers

Chris



Von: Christian Lenz
Gesendet: Montag, 10. September 2018 11:53
An: dev@netbeans.incubator.apache.org
Betreff: AW: Blurry font with NetBeans 9.0

Hey all,

so it seems to work now. I use JDK 10.0.2 and the uiScale=2 and dpiAware=false 
and the scaling compatibilty Option of Windows.
Thx to all. Will check whether it will work with the darcula laf or not.


Cheers

Chris

Von: Christian Lenz
Gesendet: Montag, 10. September 2018 11:20
An: dev@netbeans.incubator.apache.org
Betreff: AW: Blurry font with NetBeans 9.0

Hey Tim,

which zoom do you mean? If you mean the Windows scaling (zoom) this is not 
possible, as I said. Because everything is to small, not only NetBeans. I 
didn’t need to Change anything in IntelliJ and there it works well and out of 
the box, I don’t know why I have to do such stuff for NetBeans.

When I add those flags for dpiaware and uiScale, Nothing work anymore. NetBeans 
started and it disappears but runs in Background. Removed all Folders for 
NetBeans completely. After I open the exe again, I got an empty Dialog.


Cheers

Chris

Von: Tim Boudreau
Gesendet: Freitag, 7. September 2018 19:48
An: dev@netbeans.incubator.apache.org
Betreff: Re: Blurry font with NetBeans 9.0

Add --fontsize 24 (or whatever size works) to your netbeans.conf and turn off 
zoom.

Of course fonts will look fuzzy when zoomed - you are making the logical pixels 
take up more than one physical pixel.

There are a couple of system properties that may be useful to tell AWT as well.

I have been running NetBeans for years on a high dpi screen. Zoom is not the 
solution.

-Tim

On Fri, Sep 7, 2018 at 10:21 AM Eirik Bakke  wrote:

> I have added https://issues.apache.org/jira/browse/NETBEANS-1227 to 
> indicate that the NetBeans launcher should eventually declare itself 
> as DPI-aware, like JDKs javaw.exe already does.
>
> -- Eirik
>
> -Original Message-
> From: Eirik Bakke 
> Sent: Friday, September 7, 2018 9:48 AM
> To: dev@netbeans.incubator.apache.org
> Subject: RE: Blurry font with NetBeans 9.0
>
> Hi, Christian.
>
> I have NetBeans 9.0 running very well on a Windows 10 HiDPI screen at 
> either 150% or 200% scaling. It's essential to use the latest Java--I 
> use 10.0.2. You also need to right click the "bin\netbeans64.exe" 
> file, or whichever shortcut you're using to open NetBeans, go to the 
> "Compatibility"
> tab, click "Change high DPI settings", "Override high DPI scaling 
> behavior", and select scaling performed by "Application". (This should 
> probably be built into the launcher at some point.)
>
> -- Eirik
>
> -Original Message-
> From: Christian Lenz 
> Sent: Friday, September 7, 2018 4:45 AM
> To: dev@netbeans.incubator.apache.org
> Subject: Blurry font with NetBeans 9.0
>
> Hey All,
>
> I wanted to test out NetBeans 9.0 and I must say, that I have a blurry 
> font. Please see the attached screenshot of comparing NetBeans 8.2 and 
> NetBeans 9.0:
> https://netbeans.slack.com/files/U2BLJ28NA/FCJC0D1C5/image.png
>
> It doesn’t matter of the LaF so I have it w/ or w/o the dacrula theme.
>
> My Enviroment is:
> Windows 10 (64 bit, latest release) with a zoom factor of 200% because 
> I have a HiDPI Surface book and I can’t set it to 100% because it is 
> far to small so this is not an Option.
>
> Here are the Infos from the About Dialog:
>
> Product Version: Apache NetBeans IDE 9.0 (Build
> incubator-netbeans-release-334-on-20180708)
> Updates: Updates available to version NetBeans 8.2 Patch 2 (weird 

RE: dpi on Windows Java 9

[Eirik Bakke]

I've submitted a pull request that adds scalable icons for the most important 
window system icons, that is those in o.n.swing.tabcontrol and openide.awt, 
starting with the Windows L&F (plus a couple of platform-independent icons):

https://github.com/apache/incubator-netbeans/pull/859

LAF icons, in particular, are often both simple and highly parameterized (need 
both enabled, disabled, rollover, and pressed variants, and might eventually 
need Darcula versions), and so made sense to implement with custom painting 
code. This is the approach taken in Swing's own Windows L&F, e.g. for checkbox 
checks and combobox dropdown arrows [1]. On Windows, in particular, arbitrary 
DPI scalings can be encountered, so the Mac approach of just serving an extra 
bitmap "@2x" resolution for each icon does not work in all cases.

(For other kinds of icons, there's still a need to let ImageUtilities load 
bitmaps with multiple resolutions available. Automatic SVG loading & rendering, 
like Tim Boudreau suggested, would be another great feature.)
 
-- Eirik
[1] See 
http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/tip/src/java.desktop/share/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java

-Original Message-
From: Tim Boudreau  
Sent: Sunday, March 11, 2018 5:14 PM
To: dev@netbeans.incubator.apache.org; Emilian Bold 
Subject: Re: dpi on Windows Java 9

IMO, if we wanted to do this and be future-proof, the thing to do would be to 
convert the icons to SVG or some similar vector format and update the icon 
loading code in ImageUtilities to use it.

There are some tools - particularly potrace - that can assist in initial 
conversion, but deal in tracing lines and shapes and give 2- or 3- color output 
(potrace lets you set a single interior color for closed shapes), but which 
could be helpful as a start.

Given that SVG is XML-based, I could imagine that just using something like 
Batik to load SVG would be unacceptable;  but SVG could be used as a 
designer-friendly input stage, and then be compiled by the build process into 
something more performant (either literal Java code that paints the contents of 
the svg, or some binary representation of drawing instructions), much the same 
way resource bundle message annotations are turned into static methods.

I've written code before that implements a Graphics2D that simply stores a list 
of everything it was told to do - wouldn't be that hard to take the list of 
drawing instructions from there and generate Java code to reproduce those steps.

Straw man example:

 - Code that uses an SVG icon is annotated with
@Icon("org/netbeans/modules/x/myIcon.svg")
 - At build time:
   - Annotation processor looks up that file, reads it with Batik, paints it 
into a code-generating Graphics2D which outputs a generated static method 
myIcon() on a generated class in the same package
   - Code that wants to use the icon calls the static method, the same way 
bundle messages are loaded in modern NetBeans code
 - At run time:
   - If using the generated static method, the output is just an image or an 
icon, no surprises
   - For the case where icons are shared across modules (this happens), 
ImageUtilities could be tweaked to, in the case of a .svg extension, try to 
look up the generated class / method (and optionally fall back to Batik if 
nobody minded a dependency on it, but that could be pluggable via Lookup if 
it's even needed)

The hard part is converting to SVG, since turning an image into efficient 
vectors is a genuinely hard problem where there are many non-optimal answers 
and few optimal ones - particularly for converting gradients.  I could imagine 
getting a little better output by running the icon through potrace with several 
color filters on it and combining the output.  But likely it simply requires a 
bunch of manual tweaking.

-Tim


On Sun, Mar 11, 2018 at 4:07 PM, Emilian Bold 
wrote:

> > In my opinion, the correct fix would be for applications to provide 
> > higher resolution icons :) It's a win-win for everyone.
>
> https://nextbeans.com/retina
> https://jaxenter.com/netbeans/netbeans-retina
>
> --emi
>
> ‐‐‐ Original Message ‐‐‐
>
> On 11 March 2018 9:49 PM, cowwoc  wrote:
>
> > I might be in the minority, but I actually prefer the new look. It 
> > makes
> >
> > Netbeans a lot easier to use in high DPI environments (yes, on Windows).
> >
> > Netbeans with JDK 8 looks super tiny.
> >
> > In my opinion, the correct fix would be for applications to provide
> >
> > higher resolution icons :) It's a win-win for everyone.
> >
> > Gili
> >
> > On 2018-03-11 3:14 PM, Neil C Smith wrote:
> >
> > > Hi,
> > >
> > > On Sun, 11 Mar 2018, 19:02 , toni.ep...@eppleton.de wrote:
> > >
> > > > It's a 13,3" FHD 1920 x 1080 with app scaling set to 150%. Not 
> > > > sure
> if
> > > >
> > > > that already counts as high dpi.
> > >
> > > Looks like you're not alone anyway
> > >
> > > https://bugs.openjdk.java.net/browse/JDK-8187367
> > >
> > > Not sure 

RE: Blurry font with NetBeans 9.0

[Eirik Bakke]

> Add --fontsize 24 (or whatever size works) to your netbeans.conf and turn off 
> zoom.

That won't work for multi-monitor situations where one monitor is HiDPI and one 
is not--the window would appear twice as large (in physical inches) if you 
dragged it from the HiDPI screen to the regular screen. Are you on Windows, 
Linux, or MacOS? Both on Windows and MacOS, Java 10 has very good support for 
per-monitor HiDPI scaling, implemented at the AWT level.

> Of course fonts will look fuzzy when zoomed - you are making the logical 
> pixels take up more than one physical pixel.

I believe Christian Lenz was talking about the Windows "Scale and layout" 
setting, for which this is _not_ quite correct. The fonts will look perfectly 
sharp, provided you use Java 10 and the workaround for the missing NetBeans 
launcher manifest (see NETBEANS-1227). Every Graphics2D object will have a 
defaultTransform that ensures that text and other Java2D graphics primitives 
are rendered at twice (or 150% etc.) the pixel resolution, without Java apps 
having to do anything in particular to support it. If a window is dragged to 
another screen, the FontRenderContext and defaultTransform changes to whatever 
HiDPI scaling setting is set for that screen, and the window repaints at the 
new scaled resolution. Same for MacOS retina displays.

-- Eirik

-Original Message-
From: Tim Boudreau  
Sent: Friday, September 7, 2018 1:48 PM
To: dev@netbeans.incubator.apache.org
Subject: Re: Blurry font with NetBeans 9.0

Add --fontsize 24 (or whatever size works) to your netbeans.conf and turn off 
zoom.

Of course fonts will look fuzzy when zoomed - you are making the logical pixels 
take up more than one physical pixel.

There are a couple of system properties that may be useful to tell AWT as well.

I have been running NetBeans for years on a high dpi screen. Zoom is not the 
solution.

-Tim

On Fri, Sep 7, 2018 at 10:21 AM Eirik Bakke  wrote:

> I have added https://issues.apache.org/jira/browse/NETBEANS-1227 to 
> indicate that the NetBeans launcher should eventually declare itself 
> as DPI-aware, like JDKs javaw.exe already does.
>
> -- Eirik
>
> -Original Message-
> From: Eirik Bakke 
> Sent: Friday, September 7, 2018 9:48 AM
> To: dev@netbeans.incubator.apache.org
> Subject: RE: Blurry font with NetBeans 9.0
>
> Hi, Christian.
>
> I have NetBeans 9.0 running very well on a Windows 10 HiDPI screen at 
> either 150% or 200% scaling. It's essential to use the latest Java--I 
> use 10.0.2. You also need to right click the "bin\netbeans64.exe" 
> file, or whichever shortcut you're using to open NetBeans, go to the 
> "Compatibility"
> tab, click "Change high DPI settings", "Override high DPI scaling 
> behavior", and select scaling performed by "Application". (This should 
> probably be built into the launcher at some point.)
>
> -- Eirik
>
> -Original Message-
> From: Christian Lenz 
> Sent: Friday, September 7, 2018 4:45 AM
> To: dev@netbeans.incubator.apache.org
> Subject: Blurry font with NetBeans 9.0
>
> Hey All,
>
> I wanted to test out NetBeans 9.0 and I must say, that I have a blurry 
> font. Please see the attached screenshot of comparing NetBeans 8.2 and 
> NetBeans 9.0:
> https://netbeans.slack.com/files/U2BLJ28NA/FCJC0D1C5/image.png
>
> It doesn’t matter of the LaF so I have it w/ or w/o the dacrula theme.
>
> My Enviroment is:
> Windows 10 (64 bit, latest release) with a zoom factor of 200% because 
> I have a HiDPI Surface book and I can’t set it to 100% because it is 
> far to small so this is not an Option.
>
> Here are the Infos from the About Dialog:
>
> Product Version: Apache NetBeans IDE 9.0 (Build
> incubator-netbeans-release-334-on-20180708)
> Updates: Updates available to version NetBeans 8.2 Patch 2 (weird but 
> has Nothing todo with my problem)
> Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
> Runtime: Java(TM) SE Runtime Environment 10.0.1+10
> System: Windows 10 version 10.0 running on amd64; Cp1252; de_DE (nb) 
> User
> directory: C:\Users\Chrl\AppData\Roaming\NetBeans\9.0
> Cache directory: C:\Users\Chrl\AppData\Local\NetBeans\Cache\9.0
>
> Here is the thread in slack, where the guys tried to helped me, but 
> Nothing worked out:
> https://netbeans.slack.com/archives/C2BJDQ77A/p1535635507000100
>
> Do you Need smth more to help here? Did I miss smth About the blurry font?
>
>
> Cheers
>
> Chris
>
>
>  
> B 
> CB 
>   [  X  ܚX K  K[XZ[
>] ][  X  ܚX P  ]  X[ ˚[  X ] ܋ \ X  K ܙ B  ܈ Y  ] [ۘ[[X[ K[XZ[
>] Z []  X[ ˚[  X ] ܋ \ X  K ܙ B B  ܈  \   \  [  ܛX] [ۈ X  ]H  ]
>  X[

RE: AW: (Git) Diff Window horizontal space rescue

[Eirik Bakke]

On the topic of saving space, I have implemented a patch for 
https://issues.apache.org/jira/browse/NETBEANS-731 , which hides the menu bar 
in full screen mode (while letting the user still access it by moving the mouse 
to the top of the screen). This is standard behavior on MacOS, but not on other 
platforms.

I'll be testing it for a few days in my own IDE before submitting a pull 
request.

-- Eirik

-Original Message-
From: Christian Lenz  
Sent: Friday, September 7, 2018 7:16 AM
To: dev@netbeans.incubator.apache.org
Subject: AW: AW: (Git) Diff Window horizontal space rescue

Hey Emilian,

what is the Progress of this Task? I tried NB 9.0 and it is only that you moved 
the 2 drop downs (diff: Dropdown to: Dropdown) to the lines with the icons. But 
what About the other suggestions?


Cheers

Chris


Von: Christian Lenz
Gesendet: Sonntag, 13. Mai 2018 12:33
An: dev@netbeans.incubator.apache.org; Emilian Bold
Betreff: AW: AW: (Git) Diff Window horizontal space rescue

I think this is a real Problem, not everyone have big enough Monitors. Sure if 
you are working with a Docking Station, this is Maybe not a big Problem but if 
you have your Laptop with your, e.g. on a coding session at a conference, then 
this is a Problem. I can Show you some other Problems with the UI with NetBeans 
where a small monitor is a pain in the ass, but this is an other Topic.


Cheers

Chris

Von: Emilian Bold
Gesendet: Donnerstag, 10. Mai 2018 21:20
An: dev@netbeans.incubator.apache.org
Betreff: Re: AW: (Git) Diff Window horizontal space rescue

This email thread is also a form of brainstorming. I have no problems exploring 
ideas even if they never get implemented.

Starting from my plan of increasing the vertical space available for actual 
code in the diff top component, several other ideas were explored:

* the fact the even if we make the diff topcomponent float, we still waste 
space with that tab title (unlike IntelliJ).

** then we went into why the Window System doesn't handle this usecase

*** then we went into how this usecase might be implemented and how docking, 
closing would work

***… except it doesn't need to if people would just buy bigger monitors

* that people end up having multiple diff topcomponents open, even for the same 
group of files and some re-use might help

* syncing selection between the git(?) topcomponent and diff

--emi


‐‐‐ Original Message ‐‐‐

On 10 May 2018 5:20 PM, Neil C Smith  wrote:

> On Thu, 10 May 2018 at 14:25 Emilian Bold emilian.b...@protonmail.ch
> 
> wrote:
> 
> > Not sure why you have to be so adamant about this.
> > 
> > I could add some flag per topcomponent that says 'no-individual-tab'.
> > 
> > Then, if I have a floating window holding that single topcomponent it won't
> > 
> > have the title bar.
> 
> Play nice people! ;-)
> 
> I actually agree with both of you. I'd be really annoyed if we lost the
> 
> current tab behaviour, and yet also would love an option to selectively
> 
> open top components in separate windows without any tab support,
> 
> particularly within my RCP app rather than IDE.
> 
> Is the problem that we conflate two ideas in Float? One is SDI and the
> 
> other is MDI across multiple windows. Perhaps we need different options
> 
> with Float (or Undock) being single window, and an option more like New
> 
> Document Tab Group that opens in a new tab-able window?
> 
> But while we only have one option, my vote is on keeping the current
> 
> behaviour.
> 
> Best wishes,
> 
> Neil
> 
> 
> ---
> 
> Neil C Smith
> 
> Artist & Technologist
> 
> www.neilcsmith.net
> 
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/conflue

RE: Blurry font with NetBeans 9.0

[Eirik Bakke]

I have added https://issues.apache.org/jira/browse/NETBEANS-1227 to indicate 
that the NetBeans launcher should eventually declare itself as DPI-aware, like 
JDKs javaw.exe already does.

-- Eirik

-Original Message-
From: Eirik Bakke  
Sent: Friday, September 7, 2018 9:48 AM
To: dev@netbeans.incubator.apache.org
Subject: RE: Blurry font with NetBeans 9.0

Hi, Christian.

I have NetBeans 9.0 running very well on a Windows 10 HiDPI screen at either 
150% or 200% scaling. It's essential to use the latest Java--I use 10.0.2. You 
also need to right click the "bin\netbeans64.exe" file, or whichever shortcut 
you're using to open NetBeans, go to the "Compatibility" tab, click "Change 
high DPI settings", "Override high DPI scaling behavior", and select scaling 
performed by "Application". (This should probably be built into the launcher at 
some point.)

-- Eirik

-Original Message-
From: Christian Lenz  
Sent: Friday, September 7, 2018 4:45 AM
To: dev@netbeans.incubator.apache.org
Subject: Blurry font with NetBeans 9.0

Hey All,

I wanted to test out NetBeans 9.0 and I must say, that I have a blurry font. 
Please see the attached screenshot of comparing NetBeans 8.2 and NetBeans 9.0: 
https://netbeans.slack.com/files/U2BLJ28NA/FCJC0D1C5/image.png

It doesn’t matter of the LaF so I have it w/ or w/o the dacrula theme.

My Enviroment is:
Windows 10 (64 bit, latest release) with a zoom factor of 200% because I have a 
HiDPI Surface book and I can’t set it to 100% because it is far to small so 
this is not an Option.

Here are the Infos from the About Dialog:

Product Version: Apache NetBeans IDE 9.0 (Build 
incubator-netbeans-release-334-on-20180708)
Updates: Updates available to version NetBeans 8.2 Patch 2 (weird but has 
Nothing todo with my problem)
Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
Runtime: Java(TM) SE Runtime Environment 10.0.1+10
System: Windows 10 version 10.0 running on amd64; Cp1252; de_DE (nb) User 
directory: C:\Users\Chrl\AppData\Roaming\NetBeans\9.0
Cache directory: C:\Users\Chrl\AppData\Local\NetBeans\Cache\9.0

Here is the thread in slack, where the guys tried to helped me, but Nothing 
worked out: https://netbeans.slack.com/archives/C2BJDQ77A/p1535635507000100

Do you Need smth more to help here? Did I miss smth About the blurry font?


Cheers

Chris


B�CB��[��X��ܚX�KK[XZ[
�]�][��X��ܚX�P�]�X[�˚[��X�]܋�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[
�]�Z[�]�X[�˚[��X�]܋�\X�K�ܙ�B�B��܈�\�\�[��ܛX][ۈX��]H�]�X[��XZ[[��\���\�]
�B�΋Z�K�\X�K�ܙ���ۙ�Y[��K�\�^KӑU�PS���XZ[[���\��B�B�B

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: Blurry font with NetBeans 9.0

[Eirik Bakke]

Hi, Christian.

I have NetBeans 9.0 running very well on a Windows 10 HiDPI screen at either 
150% or 200% scaling. It's essential to use the latest Java--I use 10.0.2. You 
also need to right click the "bin\netbeans64.exe" file, or whichever shortcut 
you're using to open NetBeans, go to the "Compatibility" tab, click "Change 
high DPI settings", "Override high DPI scaling behavior", and select scaling 
performed by "Application". (This should probably be built into the launcher at 
some point.)

-- Eirik

-Original Message-
From: Christian Lenz  
Sent: Friday, September 7, 2018 4:45 AM
To: dev@netbeans.incubator.apache.org
Subject: Blurry font with NetBeans 9.0

Hey All,

I wanted to test out NetBeans 9.0 and I must say, that I have a blurry font. 
Please see the attached screenshot of comparing NetBeans 8.2 and NetBeans 9.0: 
https://netbeans.slack.com/files/U2BLJ28NA/FCJC0D1C5/image.png

It doesn’t matter of the LaF so I have it w/ or w/o the dacrula theme.

My Enviroment is:
Windows 10 (64 bit, latest release) with a zoom factor of 200% because I have a 
HiDPI Surface book and I can’t set it to 100% because it is far to small so 
this is not an Option.

Here are the Infos from the About Dialog:

Product Version: Apache NetBeans IDE 9.0 (Build 
incubator-netbeans-release-334-on-20180708)
Updates: Updates available to version NetBeans 8.2 Patch 2 (weird but has 
Nothing todo with my problem)
Java: 10.0.1; Java HotSpot(TM) 64-Bit Server VM 10.0.1+10
Runtime: Java(TM) SE Runtime Environment 10.0.1+10
System: Windows 10 version 10.0 running on amd64; Cp1252; de_DE (nb) User 
directory: C:\Users\Chrl\AppData\Roaming\NetBeans\9.0
Cache directory: C:\Users\Chrl\AppData\Local\NetBeans\Cache\9.0

Here is the thread in slack, where the guys tried to helped me, but Nothing 
worked out: https://netbeans.slack.com/archives/C2BJDQ77A/p1535635507000100

Do you Need smth more to help here? Did I miss smth About the blurry font?


Cheers

Chris

RE: Weird behavior since the nb-javac update

[Eirik Bakke]

I also get this exception every now and then now:

java.lang.NoSuchMethodError: 
com.sun.tools.javac.code.Scope$NamedImportScope.(Lcom/sun/tools/javac/code/Symbol;Lcom/sun/tools/javac/code/Scope;)V
at 
org.netbeans.api.java.source.SourceUtils.resolveImport(SourceUtils.java:427)
at 
org.netbeans.modules.editor.java.AutoImport.visitDeclared(AutoImport.java:102)
at 
org.netbeans.modules.editor.java.AutoImport.visitDeclared(AutoImport.java:49)
at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:1157)
at 
javax.lang.model.util.AbstractTypeVisitor6.visit(AbstractTypeVisitor6.java:91)
at 
org.netbeans.modules.editor.java.AutoImport.resolveImport(AutoImport.java:74)
at 
org.netbeans.modules.editor.java.JavaCodeTemplateProcessor.updateImports(JavaCodeTemplateProcessor.java:328)
at 
org.netbeans.modules.editor.java.JavaCodeTemplateProcessor.updateDefaultValues(JavaCodeTemplateProcessor.java:150)
at 
org.netbeans.lib.editor.codetemplates.CodeTemplateInsertHandler.processTemplate(CodeTemplateInsertHandler.java:225)
at 
org.netbeans.lib.editor.codetemplates.CodeTemplateManagerOperation.insert(CodeTemplateManagerOperation.java:273)
at 
org.netbeans.lib.editor.codetemplates.api.CodeTemplate.insert(CodeTemplate.java:82)
at 
org.netbeans.modules.editor.java.JavaCompletionItem.process(JavaCompletionItem.java:566)
at 
org.netbeans.modules.editor.java.JavaCompletionItem.defaultAction(JavaCompletionItem.java:286)
at 
org.netbeans.modules.editor.completion.CompletionImpl.dispatchKeyEvent(CompletionImpl.java:785)
at 
org.netbeans.modules.editor.completion.CompletionImpl.keyPressed(CompletionImpl.java:386)
at 
java.desktop/java.awt.AWTEventMulticaster.keyPressed(AWTEventMulticaster.java:258)
at 
java.desktop/java.awt.AWTEventMulticaster.keyPressed(AWTEventMulticaster.java:257)
at java.desktop/java.awt.Component.processKeyEvent(Component.java:6547)
at 
java.desktop/javax.swing.JComponent.processKeyEvent(JComponent.java:2849)
at java.desktop/java.awt.Component.processEvent(Component.java:6366)
at java.desktop/java.awt.Container.processEvent(Container.java:2261)
at 
java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4966)
at 
java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2319)
at java.desktop/java.awt.Component.dispatchEvent(Component.java:4798)
at 
java.desktop/java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1950)
at 
java.desktop/java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:871)
at 
java.desktop/java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:1140)
at 
java.desktop/java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:1010)
at 
java.desktop/java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:836)
at 
java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4847)
at 
java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2319)
at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772)
at java.desktop/java.awt.Component.dispatchEvent(Component.java:4798)
at 
java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772)
at java.desktop/java.awt.EventQueue.access$600(EventQueue.java:97)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at 
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87)
at 
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:97)
at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at 
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
at 
org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:136)
[catch] at 
java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at 
java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at 
java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at 
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at 
java.desktop/java.awt.EventDispatchT

RE: Weird behavior since the nb-javac update

[Eirik Bakke]

Yep, I can see this behavior too after the javac update (didn't have a chance 
to try before updating).

-Original Message-
From: Thilina Ranathunga  
Sent: Thursday, September 6, 2018 7:12 AM
To: dev@netbeans.incubator.apache.org
Subject: Re: Weird behavior since the nb-javac update

Broken after the update.

*Kind regards, *
*Thilina Ranathunga.*


On Thu, Sep 6, 2018 at 4:39 PM Thilina Ranathunga 
wrote:

> 1. Type MouseWh
> 2. Press Ctrl-Space
> 3. Press enter
>
> works fine with nb-javac  v 1.2
> it adds the import and completes the line
>
>
> *Kind regards, *
> *Thilina Ranathunga.*
>
>
> On Thu, Sep 6, 2018 at 3:32 PM Patrik Karlström  wrote:
>
>> Another thing is when try to use a class not previously imported, I 
>> get the import, but the line Im editing gets deleted.
>> 1. Type MouseWh
>> 2. Press Ctrl-Space
>> 3. Press enter
>> That generates: import java.awt.event.MouseWheelEvent; But removes 
>> the line with MouseWh, instead of expanding it.
>>
>> Oh, and this one too.
>> When I paste code that requires imports I get the dialog listing the 
>> needed classes, pressing OK in that dialog generates an exception.
>> The dialog stays visible but now with only cancel enabled.
>> My code did not get the imports.
>>
>> java.lang.NoSuchMethodError:
>>
>> com.sun.tools.javac.code.Scope$NamedImportScope.(Lcom/sun/tools
>> /javac/code/Symbol;Lcom/sun/tools/javac/code/Scope;)V
>> at
>>
>> org.netbeans.api.java.source.SourceUtils.resolveImport(SourceUtils.ja
>> va:427)
>> at
>>
>> org.netbeans.modules.java.editor.imports.ClipboardHandler$1.run(Clipb
>> oardHandler.java:154)
>> at
>>
>> org.netbeans.modules.java.editor.imports.ClipboardHandler$1.run(Clipb
>> oardHandler.java:126) at 
>> org.netbeans.api.java.source.JavaSource$1.run(JavaSource.java:672)
>> at org.netbeans.api.java.source.JavaSource$1.run(JavaSource.java:662)
>> at
>> org.netbeans.api.java.source.JavaSource$MultiTask.run(JavaSource.java
>> :501)
>> at
>>
>> org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProc
>> essor.java:586)
>> at
>>
>> org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(Par
>> serManager.java:130)
>> at
>>
>> org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(Par
>> serManager.java:114)
>> at
>>
>> org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.
>> java:181)
>> at
>>
>> org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.
>> java:178)
>> at
>>
>> org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.pr
>> iorityIO(FileChangedManager.java:153)
>> at
>>
>> org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO
>> (ProvidedExtensions.java:335)
>> at
>>
>> org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(Da
>> taObjectEnvFactory.java:118)
>> at
>>
>> org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.j
>> ava:67)
>> at
>>
>> org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProce
>> ssor.java:178)
>> at
>>
>> org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.ja
>> va:81)
>> at
>>
>> org.netbeans.api.java.source.JavaSource.runUserActionTaskImpl(JavaSou
>> rce.java:451)
>> at
>>
>> org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.
>> java:422)
>> at
>>
>> org.netbeans.api.java.source.JavaSource.runModificationTask(JavaSourc
>> e.java:683)
>> at
>>
>> org.netbeans.modules.java.editor.imports.ClipboardHandler.doImport(Cl
>> ipboardHandler.java:126)
>> at
>>
>> org.netbeans.modules.java.editor.imports.ClipboardHandler.access$100(
>> ClipboardHandler.java:113)
>> at
>>
>> org.netbeans.modules.java.editor.imports.ClipboardHandler$4$1.run(Cli
>> pboardHandler.java:216) at 
>> org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418
>> )
>> at
>>
>> org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.j
>> ava:45) at 
>> org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
>> [catch] at
>>
>> org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java
>> :2033)
>>
>> com.sun.tools.javac.code.Types$FunctionDescriptorLookupError
>> at 
>> com.sun.tools.javac.code.Types$DescriptorCache.failure(Types.java:809
>> ) at 
>> com.sun.tools.javac.code.Types$DescriptorCache.failure(Types.java:805
>> )
>> at
>>
>> com.sun.tools.javac.code.Types$DescriptorCache.findDescriptorInternal
>> (Types.java:735) at 
>> com.sun.tools.javac.code.Types$DescriptorCache.get(Types.java:719)
>> at com.sun.tools.javac.code.Types.findDescriptorType(Types.java:828)
>> at
>>
>> com.sun.tools.javac.tree.JCTree$JCFunctionalExpression.getDescriptorT
>> ype(JCTree.java:737) at 
>> com.sun.tools.javac.comp.Flow$FlowAnalyzer.visitLambda(Flow.java:1311
>> ) at 
>> com.sun.tools.javac.tree.JCTree$JCLambda.accept(JCTree.java:1813)
>> at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
>> at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:415)
>> at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.

RE: No IDE console output from platform app on Windows/maven/Java 9?

[Eirik Bakke]

I have added this as an issue against the nbm-maven-plugin, and added some more 
details about what I've tried so far:

https://github.com/mojohaus/nbm-maven-plugin/issues/45

Still not sure how to solve this.

-- Eirik

-Original Message-
From: Eirik Bakke  
Sent: Thursday, August 30, 2018 5:15 PM
To: dev@netbeans.incubator.apache.org
Subject: No IDE console output from platform app on Windows/maven/Java 9?

I have a maven-based NetBeans Platform app now using the 9.0-vc3 version of the 
platform libraries. During development, I'm running the application from the 
IDE, which works fine on Java 8.

However, when I switch to Java 9 or Java 10, there is no console output from 
the platform application shown in the output pane of the IDE, except some 
initial build messages. So nothing that is printed via "System.out.println()" 
or logged via Logger from the application itself is shown in the IDE's Output 
pane. If I run the application manually from the Windows command line, all 
messages show up just fine.
Does anyone have an idea of how to solve this?

There was a similar bug several years ago: 
https://netbeans.org/bugzilla/show_bug.cgi?id=235193 . That one could be fixed 
by changing the nbm-maven-plugin to a newer version. This time I'm already at 
the latest version--cloning the latest development version of nbm-maven-plugin 
and using that one did not help either.

-- Eirik

== Example Output Pane ==

Integrity verification passed.
Created NetBeans module cluster(s) at 
Z:\Ultorg\ultorg_src\Modules\desktop-application\target\ultorg
--- nbm-maven-plugin:4.1:run-platform (default-cli) @ desktop-application ---
Executing: cmd.exe /X /C 
"Z:\Ultorg\ultorg_src\Modules\desktop-application\target\ultorg\bin\ultorg.exe 
 


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

No IDE console output from platform app on Windows/maven/Java 9?

[Eirik Bakke]

I have a maven-based NetBeans Platform app now using the 9.0-vc3 version of the 
platform libraries. During development, I'm running the application from the 
IDE, which works fine on Java 8.

However, when I switch to Java 9 or Java 10, there is no console output from 
the platform application shown in the output pane of the IDE, except some 
initial build messages. So nothing that is printed via "System.out.println()" 
or logged via Logger from the application itself is shown in the IDE's Output 
pane. If I run the application manually from the Windows command line, all 
messages show up just fine.
Does anyone have an idea of how to solve this?

There was a similar bug several years ago: 
https://netbeans.org/bugzilla/show_bug.cgi?id=235193 . That one could be fixed 
by changing the nbm-maven-plugin to a newer version. This time I'm already at 
the latest version--cloning the latest development version of nbm-maven-plugin 
and using that one did not help either.

-- Eirik

== Example Output Pane ==

Integrity verification passed.
Created NetBeans module cluster(s) at 
Z:\Ultorg\ultorg_src\Modules\desktop-application\target\ultorg
--- nbm-maven-plugin:4.1:run-platform (default-cli) @ desktop-application ---
Executing: cmd.exe /X /C 
"Z:\Ultorg\ultorg_src\Modules\desktop-application\target\ultorg\bin\ultorg.exe 

RE: NB 9 Platform Maven arifacts

[Eirik Bakke]

Alright, I managed to build the NetBeans 9.0 maven artifacts for use with my 
NetBeans Platform application. In case it helps anyone else, here are the exact 
steps I had to go through (on Windows in my case):

1) Clone and build the _latest_ version of the nb-repository-plugin--the latest 
official one on maven central doesn't work with Maven 3.1.1. I changed the 
version in the pom.xml of the plugin to "1.4-mybuild" before doing mvn install.
2) Clone and cd into incubator-netbeans. Then do:

git checkout 9.0-vc3
git clean -xdf
ant
ant build-nbms
ant build-source-zips
ant build-javadoc

3) Run the download goal (put all of these on one line):
mvn org.codehaus.mojo:nb-repository-plugin:1.4-mybuild:download
  -DnexusIndexDirectory=C:\Users\ebakke\Temp\nbrepoidx
  -DrepositoryUrl=https://repo.maven.apache.org/maven2
 
4) Run the populate goal:

mvn org.codehaus.mojo:nb-repository-plugin:1.4-mybuild:populate
  -DnexusIndexDirectory=C:\Users\ebakke\Temp\nbrepoidx
  -DforcedVersion=RELEASE90mybuild
  -DnetbeansInstallDirectory=nbbuild/netbeans
  -DnetbeansNbmDirectory=nbbuild/nbms
  -DnetbeansSourcesDirectory=nbbuild/build/source-zips
  -DnetbeansJavadocDirectory=nbbuild/build/javadoc

This installs the artifacts into the local maven cache only (~/.m2). There's 
another option to install them into a private Nexus repository, which I haven't 
tried yet.

5) Update the NetBeans Platform application's pom.xml to use RELEASE90mybuild.

-- Eirik

-----Original Message-
From: Eirik Bakke  
Sent: Thursday, August 23, 2018 8:26 PM
To: dev@netbeans.incubator.apache.org
Subject: RE: NB 9 Platform Maven arifacts

Ah--thank you!

-- Eirik

-Original Message-
From: Geertjan Wielenga 
Sent: Thursday, August 23, 2018 7:43 AM
To: dev 
Subject: Re: NB 9 Platform Maven arifacts

This thread could help:

https://lists.apache.org/thread.html/3b4ef9f4e14f614e65b4144e02ef228fcda693ace1de2752a338885d@%3Cdev.netbeans.apache.org%3E

Gj

On Thu, Aug 23, 2018 at 9:24 AM, Luff,Chris 
wrote:

> You can use the nb-repository-plugin to build the maven artifacts for 
> your local repo at the correct version from a netbeans source.
>
> Associate Principal Software Engineer | IP Development - Care Insight 
> and Delivery Dev | chris.l...@cerner.com<mailto:chris.l...@cerner.com>
> | Cerner Limited<http://www.cerner.com/>
>
> On Aug 22, 2018, at 4:43 PM, Eirik Bakke 
> mailto:ebak k...@ultorg.com>> wrote:
>
> I would rather add them to my internal repo and be able to find them 
> than have to wait. Can we provide some instructions on how to do this.
>
>
> +1. I'd love to bump my platform application to NB9 so that it can 
> +start
> using the latest JDK--in particular because of improved HiDPI support 
> on Windows.
>
> -- Eirik
>
> On 8/22/18, 7:37 AM, "David Beer"  david.m.b...@gmail.com>> wrote:
>
> Hi Geerjan
>
> So the main problem is that becasue the domain has not be transfered 
> yet, means that the maven artifacts can't be uploaded to the original 
> site. Can we not upload them somewhere or have the source for the 
> archetype so that we can build it and deploy to our own maven repos, 
> and a way of building the artifacts for now and pushing to our own repos.
>
> I would rather add them to my internal repo and be able to find them 
> than have to wait. Can we provide some instructions on how to do this.
>
> Thanks
>
> David
>
> On Tue, 21 Aug 2018 at 10:54, Geertjan Wielenga 
> mailto:geertjan.
> wiele...@googlemail.com.invalid>> wrote:
>
> The problem here is that netbeans.org<http://netbeans.org> has not yet 
> been donated to Apache by Oracle hence org.netbeans does not belong to 
> Apache hence org.netbeans cannot be used for Maven archetypes.
>
> So, we need to wait for the brand/domain donation to be completed 
> before going further with this -- and there's been quite some movement 
> around that recently, so I have hope that it shouldn't take too long 
> anymore.
>
> Gj
>
>
> On Mon, Aug 20, 2018 at 11:37 PM, John McDonnell 
> mailto:mcdonnell.j...@gmail.com>
>
> wrote:
>
> Hi David,
>
> Have a look at the archives of this list:
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Flists.apache.org%2Flist.html%3Fdev%
> 40netbeans.apache.org&data=02%7C01%7CChris.Luff%40cerner.com%
> 7Cde42a00968f249783c3508d60846130d%7Cfbc493a80d244454a815f4ca58e8
> c09d%7C0%7C0%7C636705494392062947&sdata=DDcwU8nNUoTsQ7KQpRDLFafeBt
> Qb5r
> yuoXquncHunFQ%3D&reserved=0:
> lte=5M:maven%20release
>
> Check the email from Emilian Bold (4th one down as I search now), 
> that's the last info on this topic I believe...\
>
> Regards
>
> John
>

RE: NB 9 Platform Maven arifacts

[Eirik Bakke]

Ah--thank you!

-- Eirik

-Original Message-
From: Geertjan Wielenga  
Sent: Thursday, August 23, 2018 7:43 AM
To: dev 
Subject: Re: NB 9 Platform Maven arifacts

This thread could help:

https://lists.apache.org/thread.html/3b4ef9f4e14f614e65b4144e02ef228fcda693ace1de2752a338885d@%3Cdev.netbeans.apache.org%3E

Gj

On Thu, Aug 23, 2018 at 9:24 AM, Luff,Chris 
wrote:

> You can use the nb-repository-plugin to build the maven artifacts for 
> your local repo at the correct version from a netbeans source.
>
> Associate Principal Software Engineer | IP Development - Care Insight 
> and Delivery Dev | chris.l...@cerner.com<mailto:chris.l...@cerner.com> 
> | Cerner Limited<http://www.cerner.com/>
>
> On Aug 22, 2018, at 4:43 PM, Eirik Bakke 
> mailto:ebak k...@ultorg.com>> wrote:
>
> I would rather add them to my internal repo and be able to find them 
> than have to wait. Can we provide some instructions on how to do this.
>
>
> +1. I'd love to bump my platform application to NB9 so that it can 
> +start
> using the latest JDK--in particular because of improved HiDPI support 
> on Windows.
>
> -- Eirik
>
> On 8/22/18, 7:37 AM, "David Beer"  david.m.b...@gmail.com>> wrote:
>
> Hi Geerjan
>
> So the main problem is that becasue the domain has not be transfered 
> yet, means that the maven artifacts can't be uploaded to the original 
> site. Can we not upload them somewhere or have the source for the 
> archetype so that we can build it and deploy to our own maven repos, 
> and a way of building the artifacts for now and pushing to our own repos.
>
> I would rather add them to my internal repo and be able to find them 
> than have to wait. Can we provide some instructions on how to do this.
>
> Thanks
>
> David
>
> On Tue, 21 Aug 2018 at 10:54, Geertjan Wielenga 
> mailto:geertjan.
> wiele...@googlemail.com.invalid>> wrote:
>
> The problem here is that netbeans.org<http://netbeans.org> has not yet 
> been donated to Apache by Oracle hence org.netbeans does not belong to 
> Apache hence org.netbeans cannot be used for Maven archetypes.
>
> So, we need to wait for the brand/domain donation to be completed 
> before going further with this -- and there's been quite some movement 
> around that recently, so I have hope that it shouldn't take too long 
> anymore.
>
> Gj
>
>
> On Mon, Aug 20, 2018 at 11:37 PM, John McDonnell 
> mailto:mcdonnell.j...@gmail.com>
>
> wrote:
>
> Hi David,
>
> Have a look at the archives of this list:
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Flists.apache.org%2Flist.html%3Fdev%
> 40netbeans.apache.org&data=02%7C01%7CChris.Luff%40cerner.com%
> 7Cde42a00968f249783c3508d60846130d%7Cfbc493a80d244454a815f4ca58e8
> c09d%7C0%7C0%7C636705494392062947&sdata=DDcwU8nNUoTsQ7KQpRDLFafeBt
> Qb5r
> yuoXquncHunFQ%3D&reserved=0:
> lte=5M:maven%20release
>
> Check the email from Emilian Bold (4th one down as I search now), 
> that's the last info on this topic I believe...\
>
> Regards
>
> John
>
> On Mon, 20 Aug 2018 at 22:04, David Beer  david.m.b...@gmail.com>>
> wrote:
>
> Hi All
>
> I have recently downloaded Netbeans 9 Incubator release, hoping to 
> start development using the NB 9 platform. However there was no option 
> to use the NB 9 Release and secondly will the modules be built like 
> they were previously and added to a maven repository.
>
> Any news on the progress around being able to build using the NB9 
> Platform using maven?
>
> Thanks
>
> David
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> <mailto:dev-unsubscr...@netbeans.incubator.apache.org>
> For additional commands, e-mail: 
> dev-h...@netbeans.incubator.apache.org
> <mailto:dev-h...@netbeans.incubator.apache.org>
>
> For further information about the NetBeans mailing lists, visit:
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%
> 2FNETBEANS%2FMailing%2Blists&data=02%7C01%7CChris.Luff%40cerner.co
> m%
> 7Cde42a00968f249783c3508d60846130d%7Cfbc493a80d244454a815f4ca58e8
> c09d%7C0%7C0%7C636705494392062947&sdata=z%2Btwgr2%2BzzKNRnYO9%
> 2FIYNs0anF2wJKVnaLKtJrCng%2B8%3D&reserved=0
>
>
>
> CONFIDENTIALITY NOTICE This message and any included attachments are 
> from Cerner Corporation and are intended only for the addressee. The 
> information contained in this message is confidential and may 
> constitute inside or non-public information under international, 

RE: Failing builds

[Eirik Bakke]

If I understand correctly, there are now two separate build systems being 
used--Jenkins, and Travis. The latter is the one that gives a "green light" on 
Github's pull request page ("All checks have passed"), but it does not seem to 
run any tests. So GitHub pull requests will show a green light even though they 
might break the Jenkins build, potentially misleading reviewers and submitters.

Ideally, Github's pull request page would show a failure if a proposed patch 
would cause any of the Jenkins builds to fail. That would prevent future pull 
requests from breaking the build.

Also note that Jenkins only seems to run tests in modules belonging to the 
"platform" cluster. Thus there are many tests that are not run at all by either 
Jenkins or Travis, e.g. in the editor and editor.lib/lib2 modules. It would be 
great to get the full test suite running on either Jenkins, Travis, or 
both--otherwise more and more unexercised tests risk breaking over time without 
anyone noticing.

--Eirik

-Original Message-
From: Geertjan Wielenga  
Sent: Wednesday, August 22, 2018 3:22 PM
To: dev 
Subject: Failing builds

Hi all,

The builds have been failing for some time:

https://builds.apache.org/job/incubator-netbeans-windows/

https://builds.apache.org/job/incubator-netbeans-linux/

I think before merging more prs, we need to figure out what the reason for
the build failures is.

I'm trying to figure it out, if anyone else can take a look too, that would
help.

Thanks,

Gj

Re: NB 9 Platform Maven arifacts

[Eirik Bakke]

> I would rather add them to my internal repo and be able to find them than
have to wait. Can we provide some instructions on how to do this.


+1. I'd love to bump my platform application to NB9 so that it can start
using the latest JDK--in particular because of improved HiDPI support on
Windows.

-- Eirik

On 8/22/18, 7:37 AM, "David Beer"  wrote:

>Hi Geerjan
>
>So the main problem is that becasue the domain has not be transfered yet,
>means that the maven artifacts can't be uploaded to the original site. Can
>we not upload them somewhere or have the source for the archetype so that
>we can build it and deploy to our own maven repos, and a way of building
>the artifacts for now and pushing to our own repos.
>
>I would rather add them to my internal repo and be able to find them than
>have to wait. Can we provide some instructions on how to do this.
>
>Thanks
>
>David
>
>On Tue, 21 Aug 2018 at 10:54, Geertjan Wielenga
> wrote:
>
>> The problem here is that netbeans.org has not yet been donated to Apache
>> by
>> Oracle hence org.netbeans does not belong to Apache hence org.netbeans
>> cannot be used for Maven archetypes.
>>
>> So, we need to wait for the brand/domain donation to be completed before
>> going further with this -- and there's been quite some movement around
>>that
>> recently, so I have hope that it shouldn't take too long anymore.
>>
>> Gj
>>
>>
>> On Mon, Aug 20, 2018 at 11:37 PM, John McDonnell
>>> >
>> wrote:
>>
>> > Hi David,
>> >
>> > Have a look at the archives of this list:
>> > https://lists.apache.org/list.html?d...@netbeans.apache.org:
>> > lte=5M:maven%20release
>> >
>> > Check the email from Emilian Bold (4th one down as I search now),
>>that's
>> > the last info on this topic I believe...\
>> >
>> > Regards
>> >
>> > John
>> >
>> > On Mon, 20 Aug 2018 at 22:04, David Beer 
>>wrote:
>> >
>> > > Hi All
>> > >
>> > > I have recently downloaded Netbeans 9 Incubator release, hoping to
>> start
>> > > development using the NB 9 platform. However there was no option to
>>use
>> > the
>> > > NB 9 Release and secondly will the modules be built like they were
>> > > previously and added to a maven repository.
>> > >
>> > > Any news on the progress around being able to build using the NB9
>> > Platform
>> > > using maven?
>> > >
>> > > Thanks
>> > >
>> > > David
>> > >
>> >
>>


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Maven artefacts [WAS: Re: [VOTE] Release Apache NetBeans 9.0 (incubating) [vote candidate 3]]

[Eirik Bakke]

Great to see NetBeans 9.0 released! I, too, would love to use it for my 
platform application (which currently uses pre-Apache RELEASE82 via maven).

I know how to build NetBeans with ant--but how does one build/install the 
corresponding maven artifacts?

-- Eirik

On 7/9/18, 11:52 AM, "Luff,Chris" 
mailto:chris.l...@cerner.com.INVALID>> wrote:

You can build them for yourself, they are just not hosted yet!

On Jul 9, 2018, at 10:50 AM, Johannes Boesl 
mailto:j.bo...@adito.de>> wrote:

I'm really looking forward to using the platform based on the new Apache
release. I need the maven artifacts tough.
Releasing the maven artifacts at 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbits.netbeans.org%2Fnexus&data=02%7C01%7CChris.Luff%40cerner.com%7C62ad3fad9e6a446f7a8608d5e58178a6%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C636667266596032217&sdata=I0sKVJf5Lob3HpRPQOurEpr%2ByXQcSYc8lyeAFx8ohKo%3D&reserved=0
 would be
sufficient as for me. Moving to another group id would be fine, too.



Am 09.07.2018 um 08:14 schrieb Emilian Bold:
No. Last I checked Apache wouldn't allow us to release Maven binaries to Maven 
Central because the ASF does not yet own the netbeans.org domain

Until netbeans.org also gets donated we cannot upload the new version.

The alternative is to move to another group id: org.apache.netbeans or 
something but this means everybody has to update not just the version but the 
groupid too in their POMs.

--emi

??? Original Message ???

On 9 July 2018 9:09 AM, Gaurav Gupta 
mailto:gaurav.gupta...@gmail.com>> wrote:

+1

Is this release also includes the maven artefacts (version RELEASE90) :

https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbits.netbeans.org%2Fnexus%2Fcontent%2Fgroups%2Fnetbeans&data=02%7C01%7CChris.Luff%40cerner.com%7C62ad3fad9e6a446f7a8608d5e58178a6%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C636667266596032217&sdata=ZuXTm62PlyciL6w46T96hUyIFFiQC3as4eNxcj8jIFg%3D&reserved=0

On Mon, Jul 9, 2018 at 10:48 AM, Laszlo Kishalmi 
laszlo.kisha...@gmail.com

wrote:

+1

On 07/08/2018 02:40 AM, Emilian Bold wrote:

Hi all,

Please vote on releasing Apache NetBeans 9.0 (incubating)!

If this voting candidate passes, another similar voting will be started

on gene...@incubator.apache.org, and if 
that passes too, then we can

release this version. This build will also undergo validation through

NetCAT.

Apache NetBeans 9.0 (incubating) constitutes all the modules in the

Apache NetBeans Git repo, which together provide the NetBeans Platform

(i.e., the underlying application framework), as well as all the modules

that provide the Java SE-related features of Apache NetBeans.

In short, Apache NetBeans 9.0 (incubating) is a full IDE for Java SE

development.

Build artifacts available here:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fincubator%2Fnetbeans%2Fin&data=02%7C01%7CChris.Luff%40cerner.com%7C62ad3fad9e6a446f7a8608d5e58178a6%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C636667266596032217&sdata=PBsug7ILT4lQHd6jBi%2BuHvPDcdfv7ymRFYpLgHf54us%3D&reserved=0

cubating-netbeans-java/incubating-9.0-vc3

The specific artifact to be voted on:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fincubator%2Fnetbeans%2Fin&data=02%7C01%7CChris.Luff%40cerner.com%7C62ad3fad9e6a446f7a8608d5e58178a6%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C636667266596032217&sdata=PBsug7ILT4lQHd6jBi%2BuHvPDcdfv7ymRFYpLgHf54us%3D&reserved=0

cubating-netbeans-java/incubating-9.0-vc3/incubating-netbean

s-java-9.0-source.zip

Included in the above are the DEPENDENCIES, DISCLAIMER, LICENSE, and

NOTICE files, as well as a README file with build instructions, which are

the same as these:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%3Fp%3Dincubator-netbeans&data=02%7C01%7CChris.Luff%40cerner.com%7C62ad3fad9e6a446f7a8608d5e58178a6%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C636667266596032217&sdata=INYTlqO9pOsQvsGw1WPrP7rZvv8JdVHGE%2FFGGM%2B6wTQ%3D&reserved=0.

git;a=blob_plain;f=README.md;h=eccd3c6cc707ba9ca219bcfb7297

9435d85f5f7a;hb=97904961e496383d6150aef9b78fa8dff8f3e1ce

SHA1: ed2098c173460ec81f05635055066da06a7ea82b

KEYS file:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Frelease%2Fincubator%2Fnetbeans%2FKEYS&data=02%7C01%7CChris.Luff%40cerner.com%7C62ad3fad9e6a446f7a8608d5e58178a6%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C636667266596032217&sdata=2H6kqxdAYdLt2XtKu4bJAPNkrqZzkEJYzcAoLIqmIgo%3D&reserved=0

Apache NetBeans Git Repo tag: 9.0-vc3 :

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitbox.apache.org%2Frepos%2Fasf%3Fp%3Dincubator-netbeans&data=02%7C01%7CChris.Luff%40cerner.com%7C62ad3fad9e6a446f7a8608d5e58178a6%7Cfbc493a80d244454a815f4ca58e8c09d%7C

RE: Does Travis and/or Jenkins run the NetBeans test suite?

[Eirik Bakke]

Yes, there is -Dtest-unit-sys-prop.ignore.random.failures=true , which skips 
tests marked with the @RandomlyFails annotation. That seems not to be the 
problem here--I've been skipping these, as does Jenkins. (And the 
OrderHid.testSnd test from question 3 is _not_ marked with @RandomlyFails.)

-- Eirik

-Original Message-
From: Tim Boudreau  
Sent: Wednesday, July 25, 2018 7:21 PM
To: dev@netbeans.incubator.apache.org
Subject: Re: Does Travis and/or Jenkins run the NetBeans test suite?

I don't know that this is the answer, but I know there used to be a mechanism 
for marking tests that fail randomly or were known to fail but hadn't been 
fixed, so the test suite didn't count them, or flagged an unexpected pass.  
Maybe that's being used?

-Tim

On Wed, Jul 25, 2018 at 12:54 PM Eirik Bakke  wrote:

> Partially--my follow-up questions are:
> 1) Am I correct that tests in editor.lib2 (and many other editor.*
> modules) are _not_ included in the tests run by Jenkins (at 
> https://builds.apache.org/job/incubator-netbeans-linux ), since they 
> are not part of the "platform" cluster?
> 2) Are anyone else able to run the tests in editor.lib2 without error? 
> (I get "NoClassDefFoundError: org/netbeans/editor/GuardedDocument" 
> errors
> there.)
> 3) Why does Jenkins not detect the failures in 
> org.netbeans.junit.OrderHid.testSnd? (Seen in the console log e.g. for
> https://builds.apache.org/job/incubator-netbeans-linux/496 )
>
> -- Eirik
>
> -Original Message-
> From: Geertjan Wielenga 
> Sent: Wednesday, July 25, 2018 2:35 PM
> To: dev 
> Subject: Re: Does Travis and/or Jenkins run the NetBeans test suite?
>
> But does this not answer the question:
>
> FYI:
> > https://builds.apache.org/job/incubator-netbeans-linux/
> > and
> > https://builds.apache.org/job/incubator-netbeans-windows
> > run platform tests.
> >
>
> Gj
>
>
>
> On Wed, Jul 18, 2018 at 1:43 PM, Eirik Bakke  wrote:
>
> > Looking at the "last stable build" of incubator-netbeans-linux, this 
> > one reports "no failures", yet has a failure in 
> > org.netbeans.junit.OrderHid.testSnd
> > (and a few more also in the nbjunit module):
> >
> > https://builds.apache.org/job/incubator-netbeans-linux/480
> >
> > Is there somehting special about the nbjunit module that makes 
> > Jenkins ignore test failures there, and only there? (I don't see it 
> > in the list of tests at 
> > https://builds.apache.org/job/incubator-netbeans-linux/480/
> > testReport/ .)
> >
> > These Jenkins builds also omit all the tests in the "ide" cluster, right?
> > E.g. most of the editor.* modules? When I run tests in editor.lib2 
> > myself, I get several errors [1]. I'm trying to figure out whether 
> > this is due to my own setup, or whether it's a problem in the 
> > codebase
> itself.
> >
> > -- Eirik
> > [1] All which boil down to "task failed due to:
> java.lang.NoClassDefFoundError:
> > org/netbeans/editor/GuardedDocument", e.g. in
> org.netbeans.modules.editor.
> > lib2.highlighting.HighlightingManagerTest . Seems like something I'm 
> > doing wrong with the build--unless there's an error in a static 
> > initializer somewhere. I tried a clean build of the entire 
> > incubator-netbeans repo, both on MacOS and Windows. I used "ant 
> > -Dtest-unit-sys-prop.ignore.random.failures=true
> > -Dtest.modules=editor.lib2 test" and inspected the output for failures.
> >
> > On 7/18/18, 6:24 AM, "Jaroslav Tulach"   > jaroslav.tul...@gmail.com>> wrote:
> >
> > FYI:
> > https://builds.apache.org/job/incubator-netbeans-linux/
> > and
> > https://builds.apache.org/job/incubator-netbeans-windows
> > run platform tests.
> >
> > -jt
> >
> >
> > Dne neděle 15. července 2018 18:47:51 CEST, Eirik Bakke napsal(a):
> > When I make a pull request on GitHub, there is a nice little 
> > checkmark saying "All checks have passed", with a link to a Travis CI build 
> > (e.g.
> > https://travis-ci.org/apache/incubator-netbeans/builds/
> > 395547620?utm_source
> > =github_status&utm_medium=notification ).
> > Looking at the raw output of the Travis build, am I correct that 
> > this does _not_ actually run the NetBeans test suite? I searched the 
> > console output and did not find expected messages such as "Tests run:"
> > or "do-junit" or "[junit]".
> > Is this also the case for the Jenkins builds at 
> > https://builds.apache.org/view/Incubator%20Projects/job/
> > incubator-netbeans-> release ?
> > Is the current codebase supposed to pass all tests at this point? 
> > When I check out the 9.0-vc3 tag, for instance, both of the 
> > following fail with various errors:
> > ant commit-validation
> > ant -Dtest-unit-sys-prop.ignore.random.failures=true test Are these 
> > supposed to work?
> > -- Eirik
> >
> >
> >
> >
> >
> >
>


--
http://timboudreau.com

RE: Does Travis and/or Jenkins run the NetBeans test suite?

[Eirik Bakke]

Partially--my follow-up questions are:
1) Am I correct that tests in editor.lib2 (and many other editor.* modules) are 
_not_ included in the tests run by Jenkins (at 
https://builds.apache.org/job/incubator-netbeans-linux ), since they are not 
part of the "platform" cluster?
2) Are anyone else able to run the tests in editor.lib2 without error? (I get 
"NoClassDefFoundError: org/netbeans/editor/GuardedDocument" errors there.)
3) Why does Jenkins not detect the failures in 
org.netbeans.junit.OrderHid.testSnd? (Seen in the console log e.g. for 
https://builds.apache.org/job/incubator-netbeans-linux/496 )

-- Eirik

-Original Message-
From: Geertjan Wielenga  
Sent: Wednesday, July 25, 2018 2:35 PM
To: dev 
Subject: Re: Does Travis and/or Jenkins run the NetBeans test suite?

But does this not answer the question:

FYI:
> https://builds.apache.org/job/incubator-netbeans-linux/
> and
> https://builds.apache.org/job/incubator-netbeans-windows
> run platform tests.
>

Gj



On Wed, Jul 18, 2018 at 1:43 PM, Eirik Bakke  wrote:

> Looking at the "last stable build" of incubator-netbeans-linux, this 
> one reports "no failures", yet has a failure in 
> org.netbeans.junit.OrderHid.testSnd
> (and a few more also in the nbjunit module):
>
> https://builds.apache.org/job/incubator-netbeans-linux/480
>
> Is there somehting special about the nbjunit module that makes Jenkins 
> ignore test failures there, and only there? (I don't see it in the 
> list of tests at 
> https://builds.apache.org/job/incubator-netbeans-linux/480/
> testReport/ .)
>
> These Jenkins builds also omit all the tests in the "ide" cluster, right?
> E.g. most of the editor.* modules? When I run tests in editor.lib2 
> myself, I get several errors [1]. I'm trying to figure out whether 
> this is due to my own setup, or whether it's a problem in the codebase itself.
>
> -- Eirik
> [1] All which boil down to "task failed due to: 
> java.lang.NoClassDefFoundError:
> org/netbeans/editor/GuardedDocument", e.g. in org.netbeans.modules.editor.
> lib2.highlighting.HighlightingManagerTest . Seems like something I'm 
> doing wrong with the build--unless there's an error in a static 
> initializer somewhere. I tried a clean build of the entire 
> incubator-netbeans repo, both on MacOS and Windows. I used "ant 
> -Dtest-unit-sys-prop.ignore.random.failures=true
> -Dtest.modules=editor.lib2 test" and inspected the output for failures.
>
> On 7/18/18, 6:24 AM, "Jaroslav Tulach"  jaroslav.tul...@gmail.com>> wrote:
>
> FYI:
> https://builds.apache.org/job/incubator-netbeans-linux/
> and
> https://builds.apache.org/job/incubator-netbeans-windows
> run platform tests.
>
> -jt
>
>
> Dne neděle 15. července 2018 18:47:51 CEST, Eirik Bakke napsal(a):
> When I make a pull request on GitHub, there is a nice little checkmark 
> saying "All checks have passed", with a link to a Travis CI build (e.g.
> https://travis-ci.org/apache/incubator-netbeans/builds/
> 395547620?utm_source
> =github_status&utm_medium=notification ).
> Looking at the raw output of the Travis build, am I correct that this 
> does _not_ actually run the NetBeans test suite? I searched the 
> console output and did not find expected messages such as "Tests run:" 
> or "do-junit" or "[junit]".
> Is this also the case for the Jenkins builds at 
> https://builds.apache.org/view/Incubator%20Projects/job/
> incubator-netbeans-> release ?
> Is the current codebase supposed to pass all tests at this point? When 
> I check out the 9.0-vc3 tag, for instance, both of the following fail 
> with various errors:
> ant commit-validation
> ant -Dtest-unit-sys-prop.ignore.random.failures=true test Are these 
> supposed to work?
> -- Eirik
>
>
>
>
>
>

Re: Does Travis and/or Jenkins run the NetBeans test suite?

[Eirik Bakke]

Looking at the "last stable build" of incubator-netbeans-linux, this one 
reports "no failures", yet has a failure in org.netbeans.junit.OrderHid.testSnd 
(and a few more also in the nbjunit module):

https://builds.apache.org/job/incubator-netbeans-linux/480

Is there somehting special about the nbjunit module that makes Jenkins ignore 
test failures there, and only there? (I don't see it in the list of tests at 
https://builds.apache.org/job/incubator-netbeans-linux/480/testReport/ .)

These Jenkins builds also omit all the tests in the "ide" cluster, right? E.g. 
most of the editor.* modules? When I run tests in editor.lib2 myself, I get 
several errors [1]. I'm trying to figure out whether this is due to my own 
setup, or whether it's a problem in the codebase itself.

-- Eirik
[1] All which boil down to "task failed due to: java.lang.NoClassDefFoundError: 
org/netbeans/editor/GuardedDocument", e.g. in 
org.netbeans.modules.editor.lib2.highlighting.HighlightingManagerTest . Seems 
like something I'm doing wrong with the build--unless there's an error in a 
static initializer somewhere. I tried a clean build of the entire 
incubator-netbeans repo, both on MacOS and Windows. I used "ant 
-Dtest-unit-sys-prop.ignore.random.failures=true -Dtest.modules=editor.lib2 
test" and inspected the output for failures.

On 7/18/18, 6:24 AM, "Jaroslav Tulach" 
mailto:jaroslav.tul...@gmail.com>> wrote:

FYI:
https://builds.apache.org/job/incubator-netbeans-linux/
and
https://builds.apache.org/job/incubator-netbeans-windows
run platform tests.

-jt


Dne neděle 15. července 2018 18:47:51 CEST, Eirik Bakke napsal(a):
When I make a pull request on GitHub, there is a nice little checkmark
saying "All checks have passed", with a link to a Travis CI build (e.g.
https://travis-ci.org/apache/incubator-netbeans/builds/395547620?utm_source
=github_status&utm_medium=notification ).
Looking at the raw output of the Travis build, am I correct that this does
_not_ actually run the NetBeans test suite? I searched the console output
and did not find expected messages such as "Tests run:" or "do-junit" or
"[junit]".
Is this also the case for the Jenkins builds at
https://builds.apache.org/view/Incubator%20Projects/job/incubator-netbeans-> 
release ?
Is the current codebase supposed to pass all tests at this point? When I
check out the 9.0-vc3 tag, for instance, both of the following fail with
various errors:
ant commit-validation
ant -Dtest-unit-sys-prop.ignore.random.failures=true test
Are these supposed to work?
-- Eirik

Does Travis and/or Jenkins run the NetBeans test suite?

[Eirik Bakke]

When I make a pull request on GitHub, there is a nice little checkmark saying 
"All checks have passed", with a link to a Travis CI build (e.g. 
https://travis-ci.org/apache/incubator-netbeans/builds/395547620?utm_source=github_status&utm_medium=notification
 ).

Looking at the raw output of the Travis build, am I correct that this does 
_not_ actually run the NetBeans test suite? I searched the console output and 
did not find expected messages such as "Tests run:" or "do-junit" or "[junit]".

Is this also the case for the Jenkins builds at 
https://builds.apache.org/view/Incubator%20Projects/job/incubator-netbeans-release
 ?

Is the current codebase supposed to pass all tests at this point? When I check 
out the 9.0-vc3 tag, for instance, both of the following fail with various 
errors:

ant commit-validation
ant -Dtest-unit-sys-prop.ignore.random.failures=true test

Are these supposed to work?

-- Eirik

Re: JigSaw-ing NetBeans?

[Eirik Bakke]

Ah, thanks for the explanation! -- Eirik

On 7/14/18, 1:27 PM, "Jan Lahoda"  wrote:

>On Sat, Jul 14, 2018 at 1:00 PM, Eirik Bakke  wrote:
>
>> One of the great things about the NetBeans module system is that adding
>>a
>> dependency on module X does _not_ permit you to use classes from X's own
>> dependencies (transitive dependencies).
>>
>
>In Jigsaw, module X can for each of its dependencies decide if it should
>be
>transitive or not. If it says "requires foo", that users of "X" won't be
>able to use stuff from "foo" without explicit dependency on "foo", if it
>says "requires transitive foo;" then users of "X" will be able to use
>stuff
>"foo" without explicitly depending on "foo".
>
>Jan
>
>
>>
>> Is this also the case with Jigsaw?
>>
>> -- Eirik
>>
>> On 7/14/18, 1:35 AM, "Laszlo Kishalmi"
>>> laszlo.kisha...@gmail.com>> wrote:
>>
>> Well this question is to Jaroslav Tulach mostly.
>>
>> From Java 9 there are three modularization system in Java. OSGI,
>> NetBeans and Java's JigSaw.
>>
>> My question is could NetBeans be ported on JigSaw? What would we gain
>> form that movement (if any), and what would be the pain points.
>>
>> I'd even would like to see a deep analysis on this topic on Jarda's
>>blog.
>>
>>
>> Thank you in advance!
>>
>> Laszlo Kishalmi
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
>> <mailto:dev-unsubscr...@netbeans.incubator.apache.org>
>> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>> <mailto:dev-h...@netbeans.incubator.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.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: JigSaw-ing NetBeans?

[Eirik Bakke]

One of the great things about the NetBeans module system is that adding a 
dependency on module X does _not_ permit you to use classes from X's own 
dependencies (transitive dependencies).

Is this also the case with Jigsaw?

-- Eirik

On 7/14/18, 1:35 AM, "Laszlo Kishalmi" 
mailto:laszlo.kisha...@gmail.com>> wrote:

Well this question is to Jaroslav Tulach mostly.

>From Java 9 there are three modularization system in Java. OSGI,
NetBeans and Java's JigSaw.

My question is could NetBeans be ported on JigSaw? What would we gain
form that movement (if any), and what would be the pain points.

I'd even would like to see a deep analysis on this topic on Jarda's blog.


Thank you in advance!

Laszlo Kishalmi


-
To unsubscribe, e-mail: 
dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: 
dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Running NB tests (Error initializing QuantumRenderer at com.sum.javafx.tk.quantum.QuantumRenderer)

[Eirik Bakke]

Hi, NetBeans people.

I have successfully managed to compile and run the Apache NetBeans from
the sources at https://github.com/apache/incubator-netbeans using "ant"
and "ant tryme".

Now I'm trying to run the tests by running "ant test". Eventually, the
command hangs after the stack trace pasted below, with the error "Error
initializing QuantumRenderer: no suitable pipeline found". It seems to be
JavaFX-related. It happens on both MacOS and Windows.

I'm using Java 1.8.0_172 to build and test NetBeans here.

Does anyone know how to fix this?

And on a more general note, are there instructions for running the test
suite somewhere? I assume this QuantumRenderer thing might be just one of
many things that are going to fail if my environment is not correctly set
up for testing...

Thanks!

-- Eirik



-do-testng:
   [testng] [TestNG] Running:
   [testng]   org.netbeans.api.htmlui
   [testng] 
   [testng] Graphics Device initialization failed for :  es2, sw
   [testng] Error initializing QuantumRenderer: no suitable pipeline found
   [testng] java.lang.RuntimeException: java.lang.RuntimeException: Error
initializing QuantumRenderer: no suitable pipeline found
   [testng] at 
com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unknown Source)
   [testng] at com.sun.javafx.tk.quantum.QuantumToolkit.init(Unknown
Source)
   [testng] at com.sun.javafx.tk.Toolkit.getToolkit(Unknown Source)
   [testng] at com.sun.javafx.application.PlatformImpl.startup(Unknown
Source)
   [testng] at javafx.embed.swing.JFXPanel.initFx(Unknown Source)
   [testng] at javafx.embed.swing.JFXPanel.(Unknown Source)
   [testng] at 
org.netbeans.modules.htmlui.ComponentsTest.loadFX(ComponentsTest.java:61)
   [testng] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   [testng] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:6
2)
   [testng] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
l.java:43)
   [testng] at java.lang.reflect.Method.invoke(Method.java:498)
   [testng] at 
org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHel
per.java:84)
   [testng] at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
   [testng] at 
org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
   [testng] at 
org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
   [testng] at 
org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.jav
a:127)
   [testng] at 
org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
   [testng] at org.testng.TestRunner.privateRun(TestRunner.java:767)
   [testng] at org.testng.TestRunner.run(TestRunner.java:617)
   [testng] at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
   [testng] at 
org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
   [testng] at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
   [testng] at org.testng.SuiteRunner.run(SuiteRunner.java:240)
   [testng] at 
org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
   [testng] at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
   [testng] at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
   [testng] at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
   [testng] at org.testng.TestNG.run(TestNG.java:1057)
   [testng] at org.testng.TestNG.privateMain(TestNG.java:1364)
   [testng] at org.testng.TestNG.main(TestNG.java:1333)
   [testng] Caused by: java.lang.RuntimeException: Error initializing
QuantumRenderer: no suitable pipeline found
   [testng] at 
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(Unknown
Source)
   [testng] at 
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(Unknown
Source)
   [testng] at java.lang.Thread.run(Thread.java:745)





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Importing the NekoBean page to netbeans.apache.org

[Eirik Bakke]

The website at http://nekobean.net is quite amazing.

If NetBeans ever wanted a *very distinctive* brand identity, here’s a sure 
candidate :-).

— Eirik

On 7/4/18, 1:55 PM, "Junichi Yamamoto" 
mailto:junichi0...@gmail.com>> wrote:

Hi,

We would like to import the NekoBean page[1] to netbeans.apache.org.
(NekoBean is the mascot of the Japanese community[2].)
Where is an appropriate category for it? Community? or new one?

[1] https://ja.netbeans.org/nekobean/
[2] http://wiki.netbeans.org/NekoBean

Thanks,
Junichi

-
To unsubscribe, e-mail: 
dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: 
dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Questions about contributing code and developing on top of Platform 9.0

[Eirik Bakke]

2) 10 minute turnaround time for fix-build-run-test cycle is too much.


This is only for the initial build. After that, you just need to rebuild
the module you¹re working on, which takes a few seconds.

For instance, this morning I was working on a small improvement in the
editor¹s line wrap feature, which is located in the ³editor.lib2² module.
To test a change I just do:

cd editor.lib2 && ant && cd .. && ant tryme

This takes 23 seconds on my 6-year old MacBook Air.

‹ Eirik


On 6/15/18, 8:02 PM, "Dmitry Avtonomov" 
wrote:

>Ok, so looks like as far as I got with it is actually the end of the
>rabbit
>hole.
>
>Just wanted to point out that:
>1) The Netbeans project is potentially loosing lots of people who would
>have liked to contribute, but can't find a way how.
>2) 10 minute turnaround time for fix-build-run-test cycle is too much.
>3) Most importantly I don't know how to start the whole thing in debug
>mode. Do I need to modify the ant script to make it wait for debugger
>connection?
>4) Just people fiddling around in debugger can lead to some fixes and
>contributions as we're observing system's behavior.
>
>Being able to run with debugger connected will benefit everyone trying to
>write plugins. Especially considering how inspection of lookups is a major
>pain - you don't know what's available there and even if you do (e.g. by
>using lookup-inspector plugin) you still don't know what those things are.
>
>By the way here's an example of what I'm asking for:
>http://batmass.org/tutorial/setting-up-development-environment/
>That's the manual that I wrote for setting up the environment for
>development of my application. Mostly for myself so that I didn't forget
>how to start from scratch a year or two down the road. It's not too long,
>only about 3 pages.
>
>
>
>
>On Fri, Jun 15, 2018 at 3:38 AM Geertjan Wielenga
> wrote:
>
>> On Fri, Jun 15, 2018 at 2:51 AM, Dmitry Avtonomov <
>> dmitriy.avtono...@gmail.com> wrote:
>>
>> >
>> >
>> > How do I try out my changes? The download
>> >  page tells you how
>>to
>> > build IDE from scratch, but that takes forever.
>>
>>
>>
>> Less than 10 minutes.
>>
>> And, indeed, if you have no idea what you want to contribute, it's
>>going to
>> be difficult.
>>
>> Start by thinking about what's missing or what's broken.
>>
>> Take a look at this, for example, i.e., this guy just shows up because
>>he
>> had a problem, then identified the cause, and provided a patch and pull
>> request:
>>
>>
>> 
>>https://lists.apache.org/thread.html/5c4907191ac953b02434a81ae2a40ba92a1f
>>0d62bb03597b00254e08@%3Cdev.netbeans.apache.org%3E
>>
>> In short, without an itch you're going to have a hard time scratching...
>> :-)
>>
>> Gj
>>
>>
>>
>>
>>
>>
>> > The only way I see is to
>> > generate an NBM and try installing it into the running IDE, which also
>> > doesn't look the right way.
>> >
>> > I've already asked in this mailing list if there is an example of an
>>app
>> > built on top of platform 9.0 and Gj pointed to visualvm
>> > . That one comes with its own
>> platform
>> > build
>> > > > nb90_visualvm_12022018.zip>.
>> > How do we make our own with only the clusters needed?
>> >
>> > This email starts getting too long, but I guess the premise is clear -
>> > what's the entry point for contributions? I'm following this project
>>and
>> > the dev mailing list, and still I couldn't find anything in a
>>reasonable
>> > amount of time.
>> >
>> > One suggestion is to choose one specific commit on github right now,
>>use
>> it
>> > as a starting point of the codebase. Also select one simple issue from
>> JIRA
>> > (better probably to create a fake one to use as an example) and walk
>> > through all the steps from getting the code to fixing the issue and
>> > publishing the PR.
>> >
>> > Best,
>> > Dmitry
>> >
>>


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: How to implement a new language support?

[Eirik Bakke]

Ah, sorry, here’s the latest version of the LexerInputCharStream file:

https://gist.github.com/eirikbakke/fdda0e6b43ed1b2d54eb

(This one avoids the Google Guava dependency.)

— Eirik

On 6/1/18, 2:03 PM, "Eirik Bakke" mailto:eba...@ultorg.com>> 
wrote:

I have used both JavaCC and ANTLR in the past, and I highly recommend using 
ANTLR for new projects.

You can use the following adapter class to hook ANTLR’s 
org.antlr.v4.runtime.CharStream interface up to NetBeans’ 
org.netbeans.spi.lexer.LexerInput interface:

https://gist.github.com/eirikbakke/51cf4c9375880acd4741

— Eirik

On 6/1/18, 1:02 PM, "Peter Nabbefeld" 
mailto:peter.nabbef...@gmx.de><mailto:peter.nabbef...@gmx.de>>
 wrote:


Hello,

latest tutorial I found is at
https://platform.netbeans.org/tutorials/nbm-javacc-lexer.html - but
JavaCC seems to be no longer actively supported. I'm also not sure, if
this is using latest language infrastructure: Though it states "Requires
NetBeans 8.1", it uses e.d. "org.netbeans.spi.lexer.LanguageHierarchy".
IIRC this is older than GSF/CSL API, which is used e.g. for the
(netbeans-internal) YAML module.

Which API should I use?

Kind regards
Peter

-
To unsubscribe, e-mail: 
dev-unsubscr...@netbeans.incubator.apache.org<mailto:dev-unsubscr...@netbeans.incubator.apache.org><mailto:dev-unsubscr...@netbeans.incubator.apache.org>
For additional commands, e-mail: 
dev-h...@netbeans.incubator.apache.org<mailto:dev-h...@netbeans.incubator.apache.org><mailto:dev-h...@netbeans.incubator.apache.org>

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: How to implement a new language support?

[Eirik Bakke]

I have used both JavaCC and ANTLR in the past, and I highly recommend using 
ANTLR for new projects.

You can use the following adapter class to hook ANTLR’s 
org.antlr.v4.runtime.CharStream interface up to NetBeans’ 
org.netbeans.spi.lexer.LexerInput interface:

https://gist.github.com/eirikbakke/51cf4c9375880acd4741

— Eirik

On 6/1/18, 1:02 PM, "Peter Nabbefeld" 
mailto:peter.nabbef...@gmx.de>> wrote:


Hello,

latest tutorial I found is at
https://platform.netbeans.org/tutorials/nbm-javacc-lexer.html - but
JavaCC seems to be no longer actively supported. I'm also not sure, if
this is using latest language infrastructure: Though it states "Requires
NetBeans 8.1", it uses e.d. "org.netbeans.spi.lexer.LanguageHierarchy".
IIRC this is older than GSF/CSL API, which is used e.g. for the
(netbeans-internal) YAML module.

Which API should I use?

Kind regards
Peter

-
To unsubscribe, e-mail: 
dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: 
dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: NetBeans celebrates 1.7 million active users

[Eirik Bakke]

Those are some great stats. Does/will the Apache version of NetBeans still
incorporate the telemetry that allows these statistics to be collected?
How does it work?

Does this exclude users that opted out of statistics collection? (Is there
even such an option somewhere?)

It would be great to have a way to keep gathering these numbers in the
future.

-- Eirik

On 5/31/18, 9:06 AM, "Jiří Kovalský"  wrote:

>Hi folks,
>
>do we want to promote this on our website?
>
>https://www.facebook.com/NetBeans/photos/a.438798692901609.1073741825.1158
>22851865863/1671584659623000
>
>Please enjoy and share. :)
>
>-Jirka
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
>For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Postgres JDBC driver

[Eirik Bakke]

> If Postgres is the last driver still bundled with NetBeans, are the above 
> steps even worth the effort?

Other JDBC drivers which could be included, with Apache-compatible licenses:
* Microsoft SQL Server: https://github.com/Microsoft/mssql-jdbc/tree/v6.5.2
* SQLite: https://github.com/xerial/sqlite-jdbc/tree/3.23.1

The MySQL/MariaDB ones are GPL/LGPL and so can’t be bundled, unfortunately. I’d 
still say it would be worth bundling PostgreSQL, SQL Server, and SQLite.

— Eirik

On 5/29/18, 9:16 AM, "Glenn Holmer" 
mailto:ce...@kolabnow.com>> wrote:

On 05/27/2018 02:21 PM, Matthias Bläsing wrote:
Hey Glenn,
Am Montag, den 23.04.2018, 06:22 -0500 schrieb Glenn Holmer:
The Postgres driver shipped with NetBeans is several years old. Any
chance that could be updated for 9.0?
I'm not sure when I'll have time to look at this. I doubt, that it will
make it into Netbeans 9.0. I opened NETBEANS-870 to track this:
https://issues.apache.org/jira/browse/NETBEANS-870
>From my POV this might be a good issue to work on as an outsider. What
needs to be done:
- get an updated driver
- check the license
- update the db.drivers module with the new binary and updated license
- get it reviewed and merged
If anyone wants to do it, I'll review.

I'd like to work on this. I'll have lots of questions, but I want to
learn the NetBeans internals. I'm studying "NetBeans Platform for
Beginners" and the API docs on netbeans.org.

I had a look at NETBEANS-170 (referenced by 870):

https://issues.apache.org/jira/browse/NETBEANS-170

If Postgres is the last driver still bundled with NetBeans, are the
above steps even worth the effort?

--
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."

-
To unsubscribe, e-mail: 
dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: 
dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: AW: (Git) Diff Window horizontal space rescue

[Eirik Bakke]

> Closing the frame would dock the contained TopComponent "back".


Ah, not a bad idea! I assume dragging an additional tab into the frame
would make tabs appear again.

On 5/9/18, 6:59 PM, "Emilian Bold"  wrote:

>> That would be nice--but how would one dock the TopComponent again if
>>there is no tab to right-click or drag?
>
>Closing the frame would dock the contained TopComponent "back".
>
>> Personally I don't see a reason to change the way undocked top
>> compoents are displayed. I work with netbeans and so I'm either on a
>> large enough laptop screen (15,4 inch) or a dual head setup. In both
>> cases, the overhead for the tab is neglectable.
>
>This might be a tricky thing to implement.
>
>Still -- the whole purpose of this thread is to get rid of all these
>negligible components that keep eating vertical space and leave our users
>see 10 lines for diffs. The classical 80x25 terminal has better
>ergonomics...
>
>Tangentially, I also speculate users generally have a single undocked
>topcomponent floating which means that title tab is redundant.
>
>--emi
>
>--- Original Message ---
>
>On 5 May 2018 12:42 AM, Eirik Bakke  wrote:
>
>> That would be nice--but how would one dock the TopComponent again if
>>there is no tab to right-click or drag?
>> 
>> On MacOS, there's a "Window.style" client property that can be set to
>>"small", like this:
>> 
>> rootPane.putClientProperty("Window.style", "small");
>> 
>> (See 
>>https://developer.apple.com/library/content/technotes/tn2007/tn2196.html#
>>WINDOWS )
>> 
>> This makes the title bar take up much less space, and omits the window
>>title, while still allowing the window to be dragged by its frame,
>>maximized, and such. I use it in my own NetBeans app, for a "filter"
>>widget, seen here: https://pasteboard.co/HjFRlqT.png
>> 
>> Unfortunately, no equivalent exists on Windows. It would have to be
>>emulated with a custom-painted undecorated window (which would also have
>>to implement drag-to-resize logic).
>> 
>> -- Eirik
>> 
>> On 5/4/18, 1:34 PM, "Emilian Bold"
>>mailto:emilian.b...@protonmail.ch> wrote:
>> 
>> I think Chris is mentioning that a floating (editor-) topcomponent
>>still has a tab with the topcomponent title, even if it's the single
>>topcomponent. So, what Chris wants is that if you make the Diff
>>topcomponent floating, only the operating system frame has the title /
>>icon and there's no other tab from the Windows System API.
>> 
>> I'm actually wondering myself why there is no Windows System flag for
>>this thing... it seems an obvious need for some topcomponens eg.
>>floating palette window.
>> 
>> --emi
>> 
>> --- Original Message ---
>> 
>> On 4 May 2018 6:39 PM, Matthias Bläsing
>>mailto:mblaes...@doppel-helix.eu> wrote:
>> 
>> Hi,
>> 
>> Am Freitag, den 04.05.2018, 14:42 + schrieb Eirik Bakke:
>> 
>> > On the other hand, I think the Diff panel should remain a regular
>> > 
>> > TopComponent--those can be undocked, full-screened, moved to different
>> > 
>> > monitors, and so on. Making it into a Dialog is a step backwards, in
>>my
>> > 
>> > opinion. But the internal layout of the diff panel could certainly be
>> > 
>> > rearranged to save some space.
>> 
>> I aggree with this assessment. Modifying the diff view to be a dialog
>> 
>> would be a step backwards.
>> 
>> Greetings
>> 
>> Matthias
>> 
>> 
>> 
>>-
>>-
>> 
>> To unsubscribe, e-mail:
>>dev-unsubscribe@netbeans.incubator.apache.orgmailto:dev-unsubscribe@netbe
>>ans.incubator.apache.org
>> 
>> For additional commands, e-mail:
>>dev-help@netbeans.incubator.apache.orgmailto:dev-help@netbeans.incubator.
>>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-unsubscribe@netbeans.incubator.apache.orgmailto:dev-unsubscribe@netbe
>>ans.incubator.apache.org
>> 
>&g

Re: AW: (Git) Diff Window horizontal space rescue

[Eirik Bakke]

That would be nice--but how would one dock the TopComponent again if there is 
no tab to right-click or drag?

On MacOS, there's a "Window.style" client property that can be set to "small", 
like this:

rootPane.putClientProperty("Window.style", "small");

(See 
https://developer.apple.com/library/content/technotes/tn2007/tn2196.html#WINDOWS
 )

This makes the title bar take up much less space, and omits the window title, 
while still allowing the window to be dragged by its frame, maximized, and 
such. I use it in my own NetBeans app, for a "filter" widget, seen here: 
https://pasteboard.co/HjFRlqT.png

Unfortunately, no equivalent exists on Windows. It would have to be emulated 
with a custom-painted undecorated window (which would also have to implement 
drag-to-resize logic).

-- Eirik

On 5/4/18, 1:34 PM, "Emilian Bold" 
mailto:emilian.b...@protonmail.ch>> wrote:

I think Chris is mentioning that a floating (editor-) topcomponent still has a 
tab with the topcomponent title, even if it's the single topcomponent. So, what 
Chris wants is that if you make the Diff topcomponent floating, only the 
operating system frame has the title / icon and there's no other tab from the 
Windows System API.

I'm actually wondering myself why there is no Windows System flag for this 
thing... it seems an obvious need for some topcomponens eg. floating palette 
window.

--emi

--- Original Message ---

On 4 May 2018 6:39 PM, Matthias Bläsing 
mailto:mblaes...@doppel-helix.eu>> wrote:

Hi,
Am Freitag, den 04.05.2018, 14:42 + schrieb Eirik Bakke:
> On the other hand, I think the Diff panel should remain a regular
>
> TopComponent--those can be undocked, full-screened, moved to different
>
> monitors, and so on. Making it into a Dialog is a step backwards, in my
>
> opinion. But the internal layout of the diff panel could certainly be
>
> rearranged to save some space.
I aggree with this assessment. Modifying the diff view to be a dialog
would be a step backwards.
Greetings
Matthias
--
To unsubscribe, e-mail: 
dev-unsubscr...@netbeans.incubator.apache.org<mailto:dev-unsubscr...@netbeans.incubator.apache.org>
For additional commands, e-mail: 
dev-h...@netbeans.incubator.apache.org<mailto:dev-h...@netbeans.incubator.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.incubator.apache.org<mailto:dev-unsubscr...@netbeans.incubator.apache.org>
For additional commands, e-mail: 
dev-h...@netbeans.incubator.apache.org<mailto:dev-h...@netbeans.incubator.apache.org>

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: AW: (Git) Diff Window horizontal space rescue

[Eirik Bakke]

I agree with Emi to avoid adding options for everything.

On the other hand, I think the Diff panel should remain a regular
TopComponent--those can be undocked, full-screened, moved to different
monitors, and so on. Making it into a Dialog is a step backwards, in my
opinion. But the internal layout of the diff panel could certainly be
rearranged to save some space.

-- Eirik

On 5/4/18, 6:18 AM, "Emilian Bold"  wrote:

>> +1 separate window
>> I'd like to also suggest having the separate window track selection
>>events
>in the windows that generated it so that you only have one window up.
>
>Interesting idea. This would only really be handy for a multi-monitor
>setup imho.
>
>> As we see some discussion like, we want a separate Dialog and some
>>doesn¹t
>> want it, we Need an Option for changing this. Because I¹m also for using
>> the separated window. So Default should be as it is, as a tab Maybe and
>> with anoption, we can switch to a more lightweight (w/o the tab stuff
>> inside etc.). So please don¹t decide to do it only in one way. We have
>> multiple situations for that. To fix the most for all, use an Option to
>>let
>> the user decide how to use it.
>
>At some point a decision has to be made. We cannot just add options for
>everything because each case has to be supported and this increases the
>complexity.
>
>--emi
>
>--- Original Message ---
>
>On 4 May 2018 11:11 AM, Peter Steele  wrote:
>
>> +1 separate window
>> 
>> I'd like to also suggest having the separate window track selection
>>events
>> 
>> in the windows that generated it so that you only have one window up. An
>> 
>> example of this would be the commit window, clicking of different files
>> 
>> would load the diff for that file and changing the selection would
>> 
>> automatically update the same window with the diff from the new file.
>> 
>> On Fri, 4 May 2018, 09:05 Christian Lenz, christian.l...@gmx.net wrote:
>> 
>> > As we see some discussion like, we want a separate Dialog and some
>>doesn¹t
>> > 
>> > want it, we Need an Option for changing this. Because I¹m also for
>>using
>> > 
>> > the separated window. So Default should be as it is, as a tab Maybe
>>and
>> > 
>> > with anoption, we can switch to a more lightweight (w/o the tab stuff
>> > 
>> > inside etc.). So please don¹t decide to do it only in one way. We have
>> > 
>> > multiple situations for that. To fix the most for all, use an Option
>>to let
>> > 
>> > the user decide how to use it.
>> > 
>> > Cheers
>> > 
>> > Chris
>> > 
>> > Von: cowwoc
>> > 
>> > Gesendet: Donnerstag, 3. Mai 2018 17:53
>> > 
>> > An: dev@netbeans.incubator.apache.org
>> > 
>> > Betreff: Re: AW: (Git) Diff Window horizontal space rescue
>> > 
>> > I'd be okay with "reuse diff topcomponent for identical diff". It
>>seems
>> > 
>> > like a reasonable default seeing as opening the same source file in
>>the
>> > 
>> > editor reuses the same tab. It would be consistent.
>> > 
>> > Gili
>> > 
>> > On 2018-05-03 6:07 AM, Sven Reimers wrote:
>> > 
>> > > Hi,
>> > > 
>> > > idea for solving this via configuration:
>> > > 
>> > > -   reuse diff topcomponent
>> > > -   reuse diff topcomponent for identical diff
>> > > 
>> > > I like the simple navigation between topcomponents, but having the
>>same
>> > > 
>> > > diff open multiple times is annoying.
>> > > 
>> > > Sven
>> > > 
>> > > John McDonnell mcdonnell.j...@gmail.com schrieb am Do., 3. Mai 2018,
>> > > 
>> > > 08:18:
>> > > 
>> > > > I'd be the same as you Emilian, I often end up with multiple
>> > > > 
>> > > > editor windows of the same diff, which is annoying. Maybe a
>>separate
>> > > > 
>> > > > dialog makes
>> > > > 
>> > > > sense?
>> > > > 
>> > > > Could this be a preference thing? I.e. allow this as an editor
>> > > > 
>> > > > component
>> > > 
>> > > > or as a separate dialog? or is that a lot of effort?
>> > > > 
>> > > > John
>> > > > 
>> > > > On 3 May 2018 at 03:14, cowwoc cow...@bbs.darktech.org wrote:
>> > > > 
>> > > > > Multiple diffs, probably not. But I don't like IDEA-style
>>separate
>> > > > > 
>> > > > > dialog.
>> > > > > 
>> > > > > I like being able to treat the diff as just another editor tab
>>so I can
>> > > > > 
>> > > > > casually move back and forth between it and the code.
>> > > > > 
>> > > > > Gili
>> > > > > 
>> > > > > On 2018-05-02 9:25 PM, Emilian Bold wrote:
>> > > > > 
>> > > > > > Now that you mention it, there is something odd about the
>>diff window
>> > > > > > 
>> > > > > > being another editor-like topcomponent.
>> > > > > > 
>> > > > > > I sometimes find myself having the same diff open multiple
>>times
>> > > > > > 
>> > > > > > (generally after I've excluded some file manually in the Git
>>bottom
>> > > > > > 
>> > > > > > topcomponent).
>> > > > > > 
>> > > > > > So, do people really need multiple diffs open at once?
>>Because it's
>> > > > > > 
>> > > > > > starting to make sense having this as a separate dialog.
>> > > > > > 
>> > > > > > --emi
>> > > > > > 
>> > > > > > --- Orig

Re: Time to branch for the release candidate?

[Eirik Bakke]

Here's a bug, with a pull request and some discussion, that's not quite a 
blocker (it existed in 8.2) but still arguably critical:

https://issues.apache.org/jira/browse/NETBEANS-403
"Pressing Home/End scrolls to beginning/end of whole document if tooltip is 
open"

There's an ongoing discussion on 
https://github.com/apache/incubator-netbeans/pull/507 .

-- Eirik


On 4/26/18, 6:53 PM, "Laszlo Kishalmi" 
mailto:laszlo.kisha...@gmail.com>> wrote:

I went though the open issues with PR-s list.

I've marked 17 issues resolved due to it's PR merged, and added some
flags for 9.0 as well.

Right now in JIRA we have 27 open issues with PR and 9 of them are
marked for 9.0 release.

We still have 31 open PRs.

As of 9.0: We have 40 issues open (I've marked the 3 blocker ones, that
pointed out by Geertjan)

3 blocker

6 critical

25 major

5 minor

1 trivial

9 of these has PR-s


Just one note: Our most voted/watched issue is supporting JUnit 5


On 04/26/2018 10:56 AM, Laszlo Kishalmi wrote:
Well,

I'm trying to collect the remaining things to do for 9.0 release for a
week now, from GitHub PR-s, JIRA and this mailing list. Regarding 9.0
in numbers are the following (none may be accurate, though):

We have 31 open PR-s in GitHub (not necessary 9.0 related)

We have 44 open issues with PR-s.

We have 32 open issues marked for 9.0

We also have 5 open issues with PR-s for 9.0

The issues and PRs are not really aligned.

Well this does not necessarily means that we should not branch for
release. I just would like to say, we probably need to be more focused
on what we are doing.

I could promise to go over the open issues and the PR-s and close
those which have merged PRs-.

Also I feel the number of open PRs is quite high, though it might
really mean that changes that we do not want to include into 9.0 are
piling up (indicates the need of the release branch).

Also those 5 issues with PR-s might just go into master in the
following days and we could make the release branch after that.

So If I would vote for release branch now it would be 0/-1 right now
as we (or maybe just me) can't really see clearly on 9.0.



On 04/17/2018 05:52 AM, Neil C Smith wrote:
On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach 
mailto:jaroslav.tul...@gmail.com>>
wrote:

Yeah, there are changes in the queue for the master branch that
could be
too destabilizing. To avoid something like that to negatively
influence the
9.0 release, I'd suggest to create a branch release/9.0 and put only
the
safe fixes ready for 9.0 there. The wild development would continue
in the
master branch.

+1 to branching and that.  Longer term perhaps a more gitflow-like
system
where PR's come into a develop branch too?

  A question, though - I assume this will branch off master now, not
from
the beta tag?  Given that in NetCAT we were testing the beta, I assume
there is nothing you'd consider "too destabilizing"  between then and
now?

Best wishes,

Neil



-
To unsubscribe, e-mail: 
dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: 
dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: dpi on Windows Java 9

[Eirik Bakke]

JDK now has a standard way of loading HiDPI icons on both MacOS, Linux,
and Windows: An icon named "foo.png" can be paired with an icon named
"f...@2x.png" of double resolution. Swing will then pick the best icon to
use at any given point, even when a window is dragged from a HiDPI screen
to a non-HiDPI screen in a multi-monitor setup. This kind of @2x
resolution loading works with standard Image APIs such as "new
ImageIcon(URL)". Relevant resolved JDK issues:

https://bugs.openjdk.java.net/browse/JDK-8011059 (MacOS support)

https://bugs.openjdk.java.net/browse/JDK-8073320 (Windows support)

https://bugs.openjdk.java.net/browse/JDK-8044189 (on making MacOS and
Windows HiDPI work the same)
https://bugs.openjdk.java.net/browse/JDK-8055212 (Windows & Linux)


I think NetBeans should follow the same convention. Generating PNG files
from SVG files is something that should be done at icon design time--often
the icon designer needs to do pixel-level tweaks to the small version of
the icon, or even remove some details for the icon to remain legible. This
is especially the case for tiny 16x16 icons, or for the super-tiny 8x8
icon "badges" that netbeans superimposes on project files to indicate
errors, repo changes, and such.

As far as NetBeans is concerned, the first step in better HiDPI support
would be to get ImageUtilities to support the @2x.png loading convention
on all platforms. I think Emilian has already some some of this work:
https://github.com/emilianbold/nextbeans/commit/0f99dba0c1b3e8e0bc4e7cec407
b53d30e85ead1 .

Questions for Emilian about the work you already did on ImageUtilities:
(1) Did you ever try this on Windows? (I know you're a Mac guy, like me :-)
(2) Are you taking advantage of the new interfaces that were added to
Swing to handle HiDPI rendering? If so, that will likely make it easier to
get your code working on Windows and Linux as well. I see you have a class
that extends from MultiResolutionImage, which bodes well.
(3) Does your code work when a window is dragged from a HiDPI screen to a
non-HiDPI screen in a multi-monitor setup?

Once ImageUtilities is made to support @2x loading, the next step is to
actually update some of the icons. Some icons are much more important than
others. In particular, just getting 2x versions of the Windows and Mac
icons in openide.awt/src/org/openide/awt/resources would go a long way.
Those are all the little UI buttons that are part of the core window
system (maximize/close tab etc.). If I knew that ImageUtilities would
support it, and if I have some free time one day, I might be tempted to do
some of these myself. I'd just make them look exactly as they currently
do, but at a double resolution (to avoid long design discussions).

My next laptop will be a HiDPI Windows one, so I might have a chance to do
more testing on that platform eventually.

-- Eirik

On 3/11/18, 5:13 PM, "Tim Boudreau"  wrote:

>IMO, if we wanted to do this and be future-proof, the thing to do would be
>to convert the icons to SVG or some similar vector format and update the
>icon loading code in ImageUtilities to use it.
>
>There are some tools - particularly potrace - that can assist in initial
>conversion, but deal in tracing lines and shapes and give 2- or 3- color
>output (potrace lets you set a single interior color for closed shapes),
>but which could be helpful as a start.
>
>Given that SVG is XML-based, I could imagine that just using something
>like
>Batik to load SVG would be unacceptable;  but SVG could be used as a
>designer-friendly input stage, and then be compiled by the build process
>into something more performant (either literal Java code that paints the
>contents of the svg, or some binary representation of drawing
>instructions), much the same way resource bundle message annotations are
>turned into static methods.
>
>I've written code before that implements a Graphics2D that simply stores a
>list of everything it was told to do - wouldn't be that hard to take the
>list of drawing instructions from there and generate Java code to
>reproduce
>those steps.
>
>Straw man example:
>
> - Code that uses an SVG icon is annotated with
>@Icon("org/netbeans/modules/x/myIcon.svg")
> - At build time:
>   - Annotation processor looks up that file, reads it with Batik, paints
>it into a code-generating Graphics2D which outputs a generated static
>method myIcon() on a generated class in the same package
>   - Code that wants to use the icon calls the static method, the same way
>bundle messages are loaded in modern NetBeans code
> - At run time:
>   - If using the generated static method, the output is just an image or
>an icon, no surprises
>   - For the case where icons are shared across modules (this happens),
>ImageUtilities could be tweaked to, in the case of a .svg extension, try
>to
>look up the generated class / method (and optionally fall back to Batik if
>nobody minded a dependency on it, but that could be pluggable via Lookup
>if
>it's even needed)
>
>The hard

Re: Netbeans encoding

[Eirik Bakke]

TB> That's not that uncommon, but the right solution is to *detect* that
the output is UTF-8 when the IDE runs whatever it is you're running.

That's hard to do in general, unfortunately. Web browsers do character set
detection by a statistical analysis of character frequencies in input
documents [1]--and it's not at all guaranteed to be correct (and magic BOM
characters are far from universal). Console output likely has a different
statistical profile of characters than that of web pages (making existing
libraries less accurate), and furthermore, console output is not available
"all at once" for analysis. After how many lines of output should the
console detect the encoding? Should it then switch from one encoding to
another? Should it switch again if more lines are printed and the analysis
can be made more accurate?

VWSdS> Netbeans should ... at least provide an easy and accessible way to
[l]et the user define it.
That will be more reliable. Options could be made available from the
right-click menu in the terminal. There could also be an option here that
tries to auto-detect the encoding only at the time that the "Auto-Detect"
option is invoked, based on whatever data is currently in the terminal.
That alleviates some of the previously mentioned issues.


Though this still sounds like a problem with the app--console text output
should generally be in whatever encoding the OS expects on its own
terminal/command-line tool. Otherwise the output would be equally garbled
in the OS terminal.

-- Eirik

[1] https://www-archive.mozilla.org/projects/intl/chardet.html



On 4/20/18, 8:33 PM, "Victor Williams Stafusa da Silva"
 wrote:

>In my case, I'm running in windows, with the dreaded and hated
>Windows-1252
>default encoding.
>
>Using default OS encoding is really bad for portability and causes a lot
>of
>encoding problems. See this JEP draft maybe for Java 11:
>http://openjdk.java.net/jeps/8187041 - There are three proposed
>alternatives: 1) Keep the status quo; 2) Deprecate all the methods that
>uses the platform default encoding; 3) Force UTF-8 deing the default
>regardless of anything.
>
>As a speaker of Portuguese, a language that is full of diacritics, I'm
>already very sick of years and years of being haunted by encoding problems
>in buggy software. But it could be much worse if my language was Chinese
>or
>Japanese.
>
>Since option 1 is unacceptable and 3 is too drastic and dangerous due to
>backwards-compatibility concerns, I think that this JEP, if it eventually
>gets delivered, will go to option 2.
>
>Anyway, regardless of this JEP or its future, Netbeans should either get
>the correct encoding in the console window or at least provide an easy and
>accessible way to et the user define it.
>
>Victor Williams Stafusa da Silva
>
>
>2018-04-20 20:00 GMT-03:00 Tim Boudreau :
>
>> Your problem is most likely your operating system's default file
>>encoding
>> here (perhaps MacRoman?).  The IDE is assuming that process output is
>> whatever your operating system's default encoding is, which is the right
>> assumption, since that *is* what command-line utilities will output.  It
>> happens that the process you're running is outputting UTF-8 *rather
>>than*
>> the
>> OS's default encoding.
>>
>> Setting that as a default would be assuming that every operating system
>> uses UTF-8 regardless of what it does - it would be wrong a lot of the
>> time.  It just happens to solve the case that whatever you're running is
>> outputting UTF-8 in spite of what the operating system provides.
>>
>> That's not that uncommon, but the right solution is to *detect* that the
>> output is UTF-8 when the IDE runs whatever it is you're running.
>>
>> So... what are you running?  Is this project output?  If so, what kind
>>of
>> project?  Or server output of some kind?  A correct fix would be to (if
>> possible), detect what that is and that it will output UTF-8, and have
>>the
>> IDE open the output of that process with the right encoding.
>>
>> -Tim
>>
>> On Fri, Apr 20, 2018 at 6:18 PM, Victor Williams Stafusa da Silva <
>> victorwssi...@gmail.com> wrote:
>>
>> > I frequently had some long-standing problems with the console output
>> > encoding in Netbeans. Which always presented garbled non-ascii
>>characters
>> > for me.
>> >
>> > After deciding that it was enough, I went to search for a solution and
>> did
>> > found a very simple one in StackOverflow. Just add
>> -J-Dfile.encoding=UTF-8
>> > into the netbeans_default_options line of netbeans.conf file and
>>voilà,
>> it
>> > works!
>> >
>> > However, this make me think about it:
>> >
>> > 1. Is there a reason to not add it there by default?
>> >
>> > 2. If it can't be added there by default for some reason, can it at
>>least
>> > be something more user-friendly and less arcane to be configured by
>>the
>> > normal user?
>> >
>> > Victor Williams Stafusa da Silva
>> >
>>
>>
>>
>> --
>> http://timboudreau.com
>>


-

Re: Exception reporting broken

[Eirik Bakke]

Could this be a case of someone importing java.sql.Date by accident when
only java.util.Date is needed? In JDK8 this would not cause an immediate
problem, but JDK9 might have moved the java.sql.* classes to a separate
now-inaccessible module.

On 3/28/18, 10:06 AM, "Antonio"  wrote:

>Mmmm java.sql.Date? That's weird.
>
>AFAIK JIRA uses a JSON REST API, so no sql is involved (I think).
>
>I wrote some instructions at [1] for setting up the JIRA plugin, but it
>threw some NullPointerExceptions while running... :-(
>
>
>[1]
>https://cwiki.apache.org/confluence/display/NETBEANS/Submitting+issues+in+
>JIRA
>
>On 28/03/18 13:50, Peter Nabbefeld wrote:
>> Thank You, Geertjan!
>> 
>> BTW, when trying to add Apache NetBeans Jira to Services/Task
>> Repositories, I get an exception ("java.lang.NoClassDefFoundError:
>> java.sql.Date"). Probably a JDK 9 issue.
>> 
>> Kind regards
>> Peter
>> 
>> 
>> Am 28.03.2018 um 13:18 schrieb Geertjan Wielenga:
>>> https://issues.apache.org/jira/projects/NETBEANS/issues/NETBEANS-491
>>>
>>> Gj
>>>
>>> On Wed, Mar 28, 2018 at 11:46 AM, Peter Nabbefeld
>>> 
>>> wrote:
>>>
 Hello,

 trying to submit an exception report leads me to
 http://statistics.netbeans.org/analytics/detail.do?id=232241

 As I'd expect JIRA on Apache web site should be used (and NetBeans
 BugZilla seems to be empty now), I'd see this as a broken (important)
 feature.

 My original problem is a regression with NB Hints system (using Java
 editor). Surely, the bug is already in JIRA database and I guess
You're
 working on it - where can I track progress?

 Kind regards
 Peter

 -
 To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
 For additional commands, e-mail:
dev-h...@netbeans.incubator.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.incubator.apache.org
>> For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
>For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Bugs potentially relating to nb-javac

[Eirik Bakke]

Yes, good point, I will try to gather more information and add it to the
JIRAs as each of these bugs reappear. Each of these bugs are intermittent,
so I'm not quite sure how to reproduce them yet.

For a start, I added some sample class files to
https://issues.apache.org/jira/browse/NETBEANS-430 , which reappeared
today.

-- Eirik

On 3/28/18, 6:19 AM, "Jan Lahoda"  wrote:

>Hi Eirik,
>
>Thanks for reporting the bugs. One thing I'd like to point out is that
>while it is sometimes possible for someone working on the code to fix a
>bug
>based just on a stacktrace, having a way to reproduce a problem usually
>leads to much faster and efficient fix.
>
>This is particularly true for (nb-)javac, where the problem often is that
>something didn't happen even though it should have, and the observable
>exception is only a consequence of that.
>
>Jan
>
>
>On Tue, Mar 27, 2018 at 5:19 PM, Eirik Bakke  wrote:
>
>> I've now used NetBeans 9.0 Beta for the six weeks since it was
>>released. I
>> found several bugs that are potentially related to the nb-javac plugin:
>>
>> NETBEANS-455<https://issues.apache.org/jira/browse/NETBEANS-455> "The
>> bytes do not represent a valid class" error while invoking the "Apply
>>Code
>> Changes" action
>> NETBEANS-454<https://issues.apache.org/jira/browse/NETBEANS-454>
>> AssertionError/"Wrong diagnostic handler ... DeferredDiagnosticHandler"
>> when opening Java autocomplete
>> NETBEANS-453<https://issues.apache.org/jira/browse/NETBEANS-453>
>> "Incorrect number of type arguments" exception during Java editing
>> NETBEANS-430<https://issues.apache.org/jira/browse/NETBEANS-430>
>>"Invalid
>> or deleted file", "Absent Code attribute" exceptions during Java editing
>> and app/test running
>> NETBEANS-531<https://issues.apache.org/jira/browse/NETBEANS-531>
>> "Duplicate method name&signature in class" when running maven app with
>>CoS
>> enabled
>>
>> Might any of these be related to the changes that were made to separate
>> out nb-javac from the Apache distribution? Or could it be a JDK9 thing?
>> Note that the Maven projects in question were all JDK8, while the IDE
>>was
>> running JDK9.
>>
>> -- Eirik
>>


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Help wanted with fixing NetBeans 9.0 blockers

[Eirik Bakke]

> Right now there are only 4 blockers so let's not allow this number to grow! :)

If I were to nominate a few bugs for high priority (though maybe not 
blocking-level priority), here are some:
* NETBEANS-403 Pressing 
Home/End scrolls to beginning/end of whole document if tooltip is open
* NETBEANS-346 Tabs, 
characters, and the right Margin don't line up
* Various new bugs relating to nb-javac (see my separate email with subject 
"Bugs potentially relating to nb-javac").

NETBEANS-403 in particular I might be able to submit a patch for myself--but it 
would be nice to get a comment from someone who knows the editor actions system 
to confirm my understanding (see my comments in the JIRA issue). The relevant 
code is in editor.lib/src/org/netbeans/editor/PopupManager.java.

-- Eirik

On 3/27/18, 8:17 AM, "Jiří Kovalský" 
mailto:jiri.koval...@oracle.com>> wrote:

Hi NetBeans developers,

as NetCAT testing of Apache NetBeans IDE 9.0 development builds is
quickly progressing we have created a JIRA dashboard to monitor overall
quality and release blockers [1] in particular. That's the step A. :)

[1] https://issues.apache.org/jira/issues/?filter=12343308

Obviously, we also need to have a plan for step B, right? That's why
we are turning to you knowledgeable users of NetBeans platform and
plugin developers with our request for help.

If you can spare an hour here and there during the following couple
of weeks and volunteer for fixing one of the blocking issues or at least
trying to find their cause in the code/infra it would be a tremendous
help! Often the investigation itself represents significant part of the
fix or at least guides potential successors where to explore more or
where not at all.

If you decide to help with this critical effort, please assign the
selected issue to yourself and free the Assignee field as soon as you
know you cannot make any more progress.

Right now there are only 4 blockers so let's not allow this number to
grow! :) Anyone going to help?

Thanks to all brave geeks for contribution towards stable 9.0 release!

Best regards,
-Jirka

-
To unsubscribe, e-mail: 
dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: 
dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Bugs potentially relating to nb-javac

[Eirik Bakke]

I've now used NetBeans 9.0 Beta for the six weeks since it was released. I 
found several bugs that are potentially related to the nb-javac plugin:

NETBEANS-455 "The bytes do 
not represent a valid class" error while invoking the "Apply Code Changes" 
action
NETBEANS-454 
AssertionError/"Wrong diagnostic handler ... DeferredDiagnosticHandler" when 
opening Java autocomplete
NETBEANS-453 "Incorrect 
number of type arguments" exception during Java editing
NETBEANS-430 "Invalid or 
deleted file", "Absent Code attribute" exceptions during Java editing and 
app/test running
NETBEANS-531 "Duplicate 
method name&signature in class" when running maven app with CoS enabled

Might any of these be related to the changes that were made to separate out 
nb-javac from the Apache distribution? Or could it be a JDK9 thing? Note that 
the Maven projects in question were all JDK8, while the IDE was running JDK9.

-- Eirik

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Eirik Bakke]

All of Minecraft (acquired by Microsoft in 2014 for 2.5 
billion 
dollars)
 is written in Java, using LWJGL to access OpenGL. So 
even if Swing and AWT dies completely in 10 years, you can still use Java for 
high-performance desktop graphics applications.

And in fact, AWT & Java2D just got a brand new rendering pipeline: 
https://bugs.openjdk.java.net/browse/JDK-8131760

-- Eirik

On 3/12/18, 2:22 PM, "Kenneth Fogel" 
mailto:kfo...@dawsoncollege.qc.ca>> wrote:

This is most distressing to me. You point out that "no new rendering pipelines 
using new nifty features of graphics cards". It implies that serious graphics 
application will need to be written in C/C++ and OpenGL. By my twisted logic it 
can also be said that EE is dead too because its been spun off to Eclipse.

Ken



-Original Message-
From: Jaroslav Tulach [mailto:jaroslav.tul...@gmail.com]
Sent: March 12, 2018 11:59 AM
To: Apache NetBeans 
mailto:dev@netbeans.incubator.apache.org>>
Subject: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from 
Oracle JDK

"Oracle has begun conversations with interested parties in the Java

ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
referenced timeframes."



The official announcement is here and people are finally starting to realize 
the truth: There is no future for JavaFX, AWT and Swing. Nobody will sponsor 
development of anything new for these technologies. Even if they get transfered 
to their new owners, they will be in maintenance mode:
Bugfixes and little features. No bigger changes - no new rendering pipelines 
using new nifty features of graphics cards. Just sustaining. I've been 
explaining this would happen since 2012.

To help us out of this situation and save Java as a programming language I 
dedicated my days to smoothing out interoperability between Java and JavaScript 
with the goal to reuse the most flexible and portable rendering system of these 
days: the browser. My work has already been donated to Apache, see: 
https://github.com/apache/incubator-netbeans-html4j - let's use it to build new 
features of NetBeans and other future Java desktop applications. Get started by 
reading Javadoc at http://bits.netbeans.org/html+java/

Forget about AWT, Swing and JavaFX - the future is HTML. In case you still care 
about Java, then your future should be Apache HTML/Java API!
-jt

Migrating Bugzilla bugs to JIRA

[Eirik Bakke]

Is there an established process for creating new issues in JIRA that already 
exist in the old Bugzilla, once they have been confirmed to still exist in 
Apache NetBeans 9.0 Beta?

(I didn't find mention of this at 
https://cwiki.apache.org/confluence/display/NETBEANS/Submitting+issues+in+JIRA )

As an example, I just created the following new JIRA issues:
* https://issues.apache.org/jira/browse/NETBEANS-403 (corresponds to 
https://netbeans.org/bugzilla/show_bug.cgi?id=236403 )
* https://issues.apache.org/jira/browse/NETBEANS-404 (corresponds to 
https://netbeans.org/bugzilla/show_bug.cgi?id=270842 )

I put the old Bugzilla link in the "External issue URL" field. Is that what 
that field should be used for?

I also see that while the old Bugzilla system prevents the creation of new 
bugs, it still allows new comments to be added to existing bugs--with an error 
message being shown about the fact that at least certain notification emails 
cannot be sent out. I added comments to the two existing bugs about the new 
JIRA issues above.

Is adding a comment to an existing Bugzilla bug the best way to notify existing 
CCers that the bug has been migrated to JIRA? Do notification emails still 
actually get sent out?

Or should the ability to add comments to existing bugs maybe be disabled 
completely on the old Bugzilla system, since Bugzilla now seems to be a bit of 
a "black hole"?

-- Eirik

On 2/6/18, 12:10 PM, "Geertjan Wielenga" 
mailto:geertjan.wiele...@googlemail.com>> 
wrote:

NetBeans is an Apache project now. That means Apache JIRA.

Gj

On Tuesday, February 6, 2018, Peter Cheung 
mailto:mcheun...@hotmail.com>> wrote:

Hi All

 https://netbeans.org/bugzilla/enter_bug.cgi bugzilla is abandoned ? I
see Either no products have been defined to enter bugs against or you have
not been given access to any.


Thanks
>From Peter

Re: Do not use java.net.URL as keys in Maps

[Eirik Bakke]

Just to add another example of a NetBeans bug related to equals/hashCode on URL 
(fixed last year):
https://netbeans.org/bugzilla/show_bug.cgi?id=267962
("30s delay upon first connecting to a localhost database (due to 
URLClassLoader trying to DNS-resolve nbinst URL in URL.hashCode)")

-- Eirik

On 10/29/17, 5:45 AM, "Lars Bruun-Hansen" 
mailto:lbruunhan...@gmail.com>> wrote:

Thank you for this. Much appreciated.
I for one wasn't aware of this. I had to look into the JDK source because I
refused to believe you :-)
You are right.

I've done some basic grepping for

"Map[:space:]*<[:space:]*URL"

on the NetBeans source code and as I feared this pattern appears all over
the place.

The reason why it is not as bad as it seems is that the vast majority of
these are really jar URLs, and these URLs have their own URLStreamHandler
in the JDK which overrides the sameFile() method (used in equals()) and
hashCode() methods so that there's no longer any name lookup performed.
This is also true for the one you point to, namely PatchModuleFileManager.
Out of the box with JDK, the issue you point to affects "http(s)://",
"ftp://";, "file://", "mailto://";, but not "jar://".

On top of this - and perhaps more importantly - I can see the code base
makes heavy use of its own custom URLStreamHandlers and
URLStreamHandlerFactories so I would guess that this has been taken care
of. The developers have indeed been aware of this as far as I can tell. All
in all I think this has been taken into consideration.

But you are 100% right that most people would not expect url1.equals(url2)
to trigger a name service lookup (DNS query). Ouch!

I had to go over my own contribution, PR 161, but luckily it uses caching
by URI, not caching by URL. Phew.

Thanks.



On Sat, Oct 28, 2017 at 7:16 PM, Victor Williams Stafusa da Silva <
victorwssi...@gmail.com> wrote:

I was looking around an issue, when I landed in the class
PatchModuleFileManager (
https://github.com/apache/incubator-netbeans/blob/
master/java.source.base/src/org/netbeans/modules/java/source/parsing/
PatchModuleFileManager.java,
version of 20170921).

This class uses java.net.URLs as keys of a HashMap. This is a really bad
thing to do because URL has one of the worst implementations of
equals(Object) and hashCode() ever invented.

Let's see this snippet from the URL.hashCode()'s method javadoc (
https://docs.oracle.com/javase/9/docs/api/java/net/URL.html#hashCode--):

> The hash code is based upon all the URL components relevant for URL
comparison. As such, this operation is a blocking operation.

The equals(Object) method is also similarly bad:

> Two hosts are considered equivalent if both host names can be resolved
into the same IP addresses; else if either host name can't be resolved, the
host names must be equal without regard to case; or both host names equal
to null.

> Since hosts comparison requires name resolution, this operation is a
blocking operation.

> Note: The defined behavior for equals is known to be inconsistent with
virtual hosting in HTTP.
So, both equals(Object) and hashCode() method are blocking operations which
do DNS lookups dependent on the state of the internet. Also, it is at least
debatable the fact that hashCode() method is synchronized. At least, it
caches the hashCode() method results. I'm not sure, but I would not be
surprised if it is possible to construct two different instances of URLs
from the same String with different hashCodes()'s due to a network topology
change in the meantime.

This all means that the URL class, by not having a sane equals(Object) and
hashCode() implementation shouldn't be used as a key to a HashMap or
LinkedHashMap nor be used in a HashSet or LinkedHashSet.

In fact, I'm in favor of putting a very big and loud @Deprecated in
java.net.URL. It is an innocent-looking, but actually very dangerous,
performance bottleneck and bug factory. Although it is actually possible to
use it safely if you never call equals(Object) and hashCode(), this is
something extremely hard and error-prone to do in practice, since
equals(Object) and hashCode() usage is widespread as it should be. And
arguably, a class that features ill-conceived equals(Object) and hashCode()
methods are itself ill-conceived. However, that is something that should be
done with the JDK guys.

Now, back to the PatchModuleFileManager, it uses URL as a key to a HashMap.
That is nasty, so I propose that it should be replaced with URI or String.
The PatchModuleFileManager uses the FileObjects class in the same package,
which also uses the URL.equals(object) method. The codebase is huge, and
those are just the first two classes that I checked, so it is very likely
that the URL class is misused in a lot of other places in the code base,
deserving a major effort to check for that.

I'm not familiar with the internal details of netbeans nor is that anything
that I could quicky learn, so I'm not in position of creating a PR to fix
that, so 

Re: AW: Introductory Email

[Eirik Bakke]

Yes--I've used both ANTLR and JavaCC, and for new projects, ANTLR4 seems to be 
the best alternative these days. That may not always have been the case, but 
ANTLR is now very mature and generally a pleasure to work with.

Note that to use ANTLR with the NetBeans language infrastructure, an adapter 
class is needed between org.antlr.v4.runtime.CharStream and 
org.netbeans.spi.lexer.LexerInput . A ready-to-use adapter is available here: 
https://gist.github.com/eirikbakke/fdda0e6b43ed1b2d54eb

-- Eirik

On 6/16/17, 4:11 AM, "Christian Lenz" 
mailto:christian.l...@gmx.net>> wrote:

An alternative could be ANTLR. Only as a hint.

Gesendet von Mail für Windows 10

Von: Peter Blemel
Gesendet: Freitag, 16. Juni 2017 06:57
An: dev@netbeans.incubator.apache.org
Betreff: Re: Introductory Email

Hi Ross,


I have written two JavaCC based language editors on the NetBeans platform (for 
AI applications). There used to be a plugin (see 
http://plugins.netbeans.org/plugin/20277/javacc), but once I had my basic 
language support in place I didn't have much need to go back and edit my 
grammars so I've lost track of it.  I don't know if it works in recent versions 
of NetBeans.


I would be happy to contribute to a grammar editor, either based on that 
project or something new.  In my opinion a user should never see the JavaCC 
grammar implementation if it can be avoided (unless they really want to), 
favoring autocoding from some kind of model instead.  I have some ideas about 
using the visual API and wizards to assist in the development process. Given a 
model, maybe Rule based, we can graph the structure, identify problems, analyze 
lookahead, etc to help develop and debug new grammars without getting bogged 
down in JavaCC specific issues (not to mention debugging problems in the 
grammar).  Such a system could be re-targeted to other parsers and language 
implementations.


I don't know how big the user community for such an editor might be (small, I 
imagine), so it might be a good first step to dust off that other project first 
and use it to look at auto-coded JavaCC grammars from a rapid prototype before 
deciding if we want to put in any more effort.


Drop me a line and we'll see about getting something started.

Best,
Peter Blemel

From: Ross Lamont mailto:rlam...@componentcorp.com>>
Sent: Thursday, June 15, 2017 9:32 PM
To: dev@netbeans.incubator.apache.org
Subject: Introductory Email

Hi everyone,

I am an independent developer, previously architect at genbook.com and other 
places.  I’ve been developing software for over 20 years, and using netbeans 
since around 2003.  I have dabbled with plugins from time to time, but I’m now 
hoping to make a serious contribution in the XML space.  I’ve been working on 
some RelaxNG editing plugins, as well as looking into improving the general XML 
validation approach as it looks like it hasn’t been touched in a while.

I’m also going to have a crack at a javaCC editor, as it will assist others 
writing other language support for Netbeans.

Best Regards
Ross

Re: Reproducible Builds

[Eirik Bakke]

That sounds quite useful. When setting up a custom build of the NetBeans
Platform for use with a platform application, I love the idea of being
able to verify that my build system's output matches the official binaries
exactly before I start applying any patches myself.

-- Eirik

On 4/8/17, 9:07 AM, "Emilian Bold"  wrote:

>Hello,
>
>I've been interested in reproducible builds for quite some time.
>
>They promote trust and by being cacheable they are essential for shared
>build systems like Google (https://bazel.build/ ) or Facebook use (
>https://buckbuild.com/).
>
>I'm tracking my progress here: https://nextbeans.com/reproducible
>
>Basically, the NetBeans Platform is reproducible!
>
>I have to polish the code and push it to a new repository.
>
>Then I'll look into the full IDE (I assume the installer might have some
>issues).
>
>--emi

Re: Aw: Re: Please vote for a new NetBeans logo

[Eirik Bakke]

Not sure who's eligible to vote, but I would vote for number 3.

-- Eirik
(Platform developer)

On 12/25/16, 2:00 PM, "Christian Lenz"  wrote:

>Please if someone can't vote, leave a comment for what you want to vote
>and I will change the number.
>Yes a feather and apache would be ok for me (in my opinion if it is
>needed). Apache would be enough I think.
>Instead of the IDE it could be the feather.
>
>
>Merry Chris-mas
> 
> 
>
>Gesendet: Freitag, 23. Dezember 2016 um 12:45 Uhr
>Von: "Emilian Bold" 
>An: dev@netbeans.incubator.apache.org
>Betreff: Re: Please vote for a new NetBeans logo
>I think we are voting too soon.
>
>First we should gather some submissions then have a vote.
>
>The timing is also not good considering Christmas is the day after
>tomorrow.
>
>
>--emi
>
>On Fri, Dec 23, 2016 at 12:29 PM, Neil C Smith 
>wrote:
>
>> On 23 December 2016 at 09:58, Ognyan Kulev 
>>wrote:
>> > Now taking the opposite position, perhaps putting additional visual
>> element
>> > will add too many of them and I would prefer simpler logo :-)
>>
>> Absolutely! Trying to merge two logos into one rarely works well.
>>
>> OTOH, +1 to changing the text (when it's used) to Apache NetBeans
>> ...and losing the emphasis on Net! ;-)
>>
>> Best wishes,
>>
>> Neil
>>
>> --
>> Neil C Smith
>> Artist & Technologist
>> www.neilcsmith.net[http://www.neilcsmith.net]
>>
>> Praxis LIVE - hybrid visual IDE for creative coding -
>>www.praxislive.org[http://www.praxislive.org]
>>