Re: NetBeans Cache Cleanup

[Tim Boudreau]

Since I keep two user dirs and cache dirs on purpose (because projects that
use jigsaw that depend on libraries that use Automatic-Module-Name on their
manifest get broken in the editor if you ever open the non-modular project
in the IDE), it could really use a “Don’t ask this again” checkbox.

-Tim

On Sun, Dec 11, 2022 at 10:39 AM Eric Bresie  wrote:

> I went ahead and created the following
> https://github.com/apache/netbeans/issues/5069
>
> Eric Bresie
> ebre...@gmail.com
>
>
> On Sun, Dec 11, 2022 at 9:17 AM Eric Bresie  wrote:
>
> > Hey Laszlo, did any updates around the orphaned "cache" get made?  I see
> > it showing up again in NB 16 so assume note.
> >
> > Should I create an issue on this?
> >
> > Eric Bresie
> > ebre...@gmail.com
> >
> >
> > On Mon, Jul 4, 2022 at 10:13 AM Eric Bresie  wrote:
> >
> >> So then a manual workaround is to change the permissions on
> >> %USERPROFILE%\AppData\Local\Netbeans\Cache to be not just read only and
> >> then running it should fix it then?
> >>
> >> I like the idea of the enhancements...are further follow-up enhancements
> >> in work?
> >>
> >>
> >> Eric Bresie
> >> ebre...@gmail.com
> >>
> >>
> >> On Fri, Jul 1, 2022 at 9:02 AM Laszlo Kishalmi <
> laszlo.kisha...@gmail.com>
> >> wrote:
> >>
> >>> Hi Eric,
> >>>
> >>> That was my "enhancement" for NB-14. The janitor module would detect
> >>> abandoned cache directories.
> >>>
> >>> Usually there is an /netbeans-14 and  >>> parent>/netbeans-14. When the janitor encounters a directory in
> >>>  which has no pair in  then it would
> >>> think, that cache dir is abandoned and would offer it for removal.
> >>>
> >>> My primary intent was to clean up the leftover cache directories when
> >>> using the Snap distribution.
> >>>
> >>> On 7/1/22 06:35, Eric Bresie wrote:
> >>> > Has anyone else had this problem?
> >>> >
> >>> > I've a number of versions (13 and 14) of Netbeans installed/used
> with a
> >>> > bunch of older versions since removed (i.e. 12.x and a mixture of rc
> >>> for
> >>> > these).  When I startup I keep getting notifications that "Netbeans
> >>> xx.xx
> >>> > was last used xx days ago" with a "Remove unused data and cache
> >>> directories
> >>> > of xxx Free up xxx MB of space."  Sounds great so clicking on this
> goes
> >>> > away.  However, a little later, restart Netbeans and the same
> >>> notifications
> >>> > show up even after clicking the remove link.
> >>> >
> >>> > Eric Bresie
> >>> > ebre...@gmail.com
> >>> >
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> >>> For additional commands, e-mail: dev-h...@netbeans.apache.org
> >>>
> >>> For further information about the NetBeans mailing lists, visit:
> >>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >>>
> >>>
> >>>
> >>>
>
-- 
http://timboudreau.com

Re: Tests triggered via push to master of fork?

[Tim Boudreau]

I’ve run into this elsewhere - if you’re naively triggering off of pushes
using GitHub actions, well, when someone clones your repo, they’re also
cloning your actions, and if they reach out to something to trigger a build
(or in the case where I ran across this, publishing notifications to
Zulip), well, something is going to be triggered.

Either the action could mark itself as skipped when the repo url is not
what it expects, or the thing called could (if the caller sends it and does
not lie).

-Tim

On Wed, Oct 12, 2022 at 11:58 AM Michael Bien  wrote:

> On 12.10.22 17:10, John Neffenger wrote:
> > On 10/12/22 3:00 AM, Michael Bien wrote:
> >> if you clone the project you getting the same behavior, just on your
> >> own copy.
> >
> > Thank you, Michael. Four years in, and I'm still learning GitHub. :-)
>
> So am I :). Some of the features we enabled recently are fairly new. 1-2
> years ago i wouldn't recommend gh actions for large projects due to its
> limitations. But it is getting better now.
>
>
> >
> >> its defined on the very top of the .github/workflows/main.yml file in
> >> your master branch.
> >
> > Got it. I see now that the other projects I'm familiar with (JDK and
> > JavaFX) simply exclude the master branch:
> >
> > https://github.com/openjdk/jdk/blob/master/.github/workflows/main.yml
> >
> > on:
> >   push:
> > branches-ignore:
> >   - master
> >   - pr/*
> >
> > https://github.com/jgneff/jfx/blob/master/.github/workflows/submit.yml
> >
> > on:
> >   # Run GitHub actions on every push to all branches except the main
> >   # production branches, also exclude any branch starting with "WIP".
> >   push:
> > branches-ignore:
> >   - master
> >   - main
> >   - 'jfx[0-9]+'
> >   - 'WIP*'
>
> we actually do want to run tests on master when a PR is integrated (PR
> merge is just a push). We did setup a conditional pipeline a few days
> ago. PRs run tests based on their labels, push (e.g a merge) to master
> runs everything.
>
> Its likely that we are going to have to change this one day, since
> running all tests on merge might be too much for the limited node runner
> resources apache has. We test much less in PRs now, but more on master.
>
> JDK uses a fairly advanced setup which sidelines github a bit. (e.g
> there is no merge button, its a command).
>
> https://github.com/openjdk/skara
>
>
> >
> > I thought that was somehow built-in behavior. Maybe this is the first
> > time the tests ran because I'm no longer a first-time contributor?
> >
> >
> https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks
> >
> >
> >   About workflow runs from public forks
> >
> >   "To help prevent this, workflows on pull requests to public
> > repositories from some outside contributors will not run
> > automatically, and might need to be approved first. By default, all
> > first-time contributors require approval to run workflows."
>
> the NB repo has this enabled. PRs from non-committers would not trigger
> CI until someone approves the workflow run.
>
> Btw I am 99% sure that actions on clones don't actually run on apache
> resources, it would use your account I believe. So watch out or you
> might reach your monthly limit - NB tests a lot.
>
>
> >
> > For now, I switched to "Disable actions."
>
> right. Most clones don't need actions since opening a PR does already
> everything you need.
>
> best regards,
>
> michael
>
>
> >
> > Thanks again,
> > John
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.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.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
> --
http://timboudreau.com

Re: my plugins rely on maven plugin but don't know how to load it programatically

[Tim Boudreau]

I have used its API in my antlr plugins and would be happy to look it over.

On Wed, Jul 20, 2022 at 12:31 PM Svata Dedic 
wrote:

> It is, but I'd like at least some time (and ideally some
> colleague/companion for the work - it's big) for +- reviewing /
> polishing the API before publishing
>
> -S.
>
> On 20. 07. 22 17:45, Neil C Smith wrote:
> > On Tue, 19 Jul 2022 at 21:36, Svata Dedic 
> wrote:
> >>
> >> On 19. 07. 22 18:32, Peter Cheung wrote:
> >>> Hi
> >>>
> >>>   I am creating a new project type for RISC-V. The below code only
> work when my netbeans loaded maven plugin. Is it possible to let netbeans
> load my plugin and auto load maven plugin together?
> >>>
> >>
> >> Well, that's bad. Maven module's API is just 'friend API'; so it is only
> >> available to a certain set of modules. Mainly because the API is too
> >> broad and the original author perhaps did not feel (?) it's rock solid
> >> to be published and maintained for good.
> >>
> >> If it was a regular API, you could just add a module dependency.
> >
> > Well, I'll +1 a PR to stop it being a friend API.  It's been like that
> > for a long time, it's got a friends list as long as your arm, some of
> > which are external.  It's just API by stealth now.
> >
> > Best wishes,
> >
> > Neil
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.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.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
> --
http://timboudreau.com

Re: Netbeans Output Encoding

[Tim Boudreau]

When you say “NetBeans output”, do you mean

 - Process output in the output window? (which, by the way, is UTF-16 under
the hood, but whatever writes to it needs to know what character set it’s
feeding to it if it’s coming from a process)
 - The encoding of logs Means NetBeans emits?
 - Some other thing that writes to stdout?

-Tim

On Mon, Jul 18, 2022 at 6:36 AM Neil C Smith  wrote:

> On Mon, 11 Jul 2022 at 20:18, 多多氷氷 
> wrote:
> > My next idea was to change the order by which the encoding is inferred
> to the behavior introduced by JEP400. This would result in first checking
> Console.charset()/sun.stdout.encoding thennative.charset and as a fallback
> for JDK16 and lower Charset.defaultEncoding()/file.encoding
> >
> > Neil said that best place to discuss a fix to Issue #4261 would be this
> mailing list, hence this mail.
>
> Well, there doesn't seem to have been much interest in discussing a
> fix for this here either! :-\
>
> I think your idea above sounds more useful, also taking into account
> the new system properties here -
> https://bugs.openjdk.org/browse/JDK-8283620 and
> https://git.openjdk.java.net/jdk/pull/8270
>
> That way preferring values of the system properties stdout.encoding >
> sun.stdout.encoding > native.encoding ?
>
> As mentioned in the issue, in some ways it might make sense to pick up
> overrides to these properties in the launching process eg.
> `exec.vmArgs`?  But that might be something to look at as a later
> enhancement.
>
> Getting the revised system properties lookup into NB15 would be good
> IMO.  Do you want to propose a PR against delivery branch?
>
> Best wishes,
>
> Neil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
> --
http://timboudreau.com

Re: API change

[Tim Boudreau]

The way this has been handled in the past has been to make the method (or
class) non-public, so it’s not visible in, say, javadoc, and then have the
build bytecode-patch it to be public so it’s binary compatible.

At least I know we did it for some classes in openide.aww, because I
deleted a non-public, unused class there once and found out the hard way.

Don’t know if we ever did that for methods. Jarda might.

-Tim

On Tue, May 10, 2022 at 5:01 PM Łukasz Bownik 
wrote:

> Vicrims of popularity? ;)
>
> On Tue, May 10, 2022, 1:56 PM Laszlo Kishalmi 
> wrote:
>
> > Also some of the platform modules are in other exotic IDE-s like
> > JDeveloper.
> >
> > On 5/10/22 13:38, antonio wrote:
> > > Hi,
> > >
> > > You're welcome! That's a way of building trust :-).
> > >
> > > Some of the committers around (not me, though) use NetBeans as a
> > > platform for building applications, or to build plugins, so it's
> > > always a good idea to ask in the mailing list when suggesting an API
> > > change.
> > >
> > > Kind regards,
> > > Antonio
> > >
> > > El 10/5/22 a las 22:17, Łukasz Bownik escribió:
> > >> Thank You for explaining the process and reasoning behind it.
> > >> It is also good to know the community's attitude towards backward
> > >> compatibility.
> > >>
> > >> I'll close the current PRs and try to spoon feed changes while
> > >> optimising
> > >> for "diff-readability" until we build some trust.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > > For additional commands, e-mail: dev-h...@netbeans.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.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>
-- 
http://timboudreau.com

nb-javac on JDK 17

[Tim Boudreau]

Is there an update for using nb-javac with JDK 17?

I've been finding, for some runs of NetBeans, parsing and semantic
highlighting do not work, and you get some log messages saying that a null
parser was returned for whatever file is being parsed.

I had been using version 15 (or is it JDK 15 specific - it was the suffix
to the JAR name), patched to fix the maven scanning bug with a pull request
I sent last year.

Building the trunk and copying it over the JARs in modules/ext in my
userdir solved that problem, but - is there an actual release that contains
this code?  Known problem?

-Tim

-- 
http://timboudreau.com

Visual Tabs update

[Tim Boudreau]

For anyone using my blingy Visual Library based editor tab control
https://github.com/timboudreau/visual-library-tabcontrol

I just pushed a few updates, and it's available from my update server:
https://timboudreau.com/modules

In particular, an optimization to defer and coalesce rapidly fired changes
results in a nice startup time improvement (one you won't get from the
default tab displayer), since the window system opens editor documents
one-by-one on startup, and if you fire a selection change for each one
(about 100ms apart), you wind up driving the whole selection machinery of
the IDE as a side-effect, and that generates a bunch of unnecessary work.

-Tim
-- 
http://timboudreau.com

Re: Cannot retrieve key publish_apidoc, this is forShould we publish this Apidoc

[Tim Boudreau]

FWIW, the following patch and deleting nbbuild/build manually got things
building.  It may be that the patch is unnecessary and just manually
cleaning would have done it (I didn't really examine what the code I
patched does, but it appears to be something that is trying to generate
release details and assumes it is always running in a continuous build or
something).

The build also now fusses that a bunch of my local branch names "is not
having good pattern" (so what?).

diff --git a/nbbuild/antsrc/org/netbeans/nbbuild/ReleaseJsonProperties.java
b/nbbuild/antsrc/org/netbeans/nbbuild/ReleaseJsonProperties.java
index 3a0bd09028..761620f70b 100644
--- a/nbbuild/antsrc/org/netbeans/nbbuild/ReleaseJsonProperties.java
+++ b/nbbuild/antsrc/org/netbeans/nbbuild/ReleaseJsonProperties.java
@@ -109,7 +109,10 @@ public class ReleaseJsonProperties extends Task {
 JSONObject releaseList = (JSONObject) jsonParser.parse(reader);
 log("Processing release: " + releaseList.keySet().toString());
 for (Object object : releaseList.keySet()) {
-ri.add(manageRelease(object.toString(),
releaseList.get(object)));
+ReleaseInfo info = manageRelease(object.toString(),
releaseList.get(object));
+if (info != null) {
+ri.add(info);
+}
 }
 } catch (ParseException | IOException ex) {
 throw new BuildException(ex);
@@ -227,7 +230,11 @@ public class ReleaseJsonProperties extends Task {
 ReleaseInfo ri = new ReleaseInfo(key);
 // mandatory element
 JSONObject jsonrelease = (JSONObject) arelease;
-ri.setPosition(Integer.parseInt((String) getJSONInfo(jsonrelease,
"position", "Order of release starting")));
+String r =(String) getJSONInfo(jsonrelease, "position", "Order of
release starting", false);
+if (r == null) {
+return null;
+}
+ri.setPosition(Integer.parseInt(r));
 // previous release date
 JSONObject previousrelease = (JSONObject) getJSONInfo(jsonrelease,
"previousreleasedate", "Apidoc: Date of previous Release");
 ri.setPreviousRelease(
@@ -285,6 +292,10 @@ public class ReleaseJsonProperties extends Task {
 }

 private Object getJSONInfo(JSONObject json, String key, String info) {
+return getJSONInfo(json, key, info, true);
+}
+
+private Object getJSONInfo(JSONObject json, String key, String info,
boolean shouldThrow) {
 Object result = json.get(key);
 if (result == null) {
 throw new BuildException("Cannot retrieve key " + key + ",
this is for" + info);

Re: Cannot retrieve key publish_apidoc, this is forShould we publish this Apidoc

[Tim Boudreau]

I just pulled and am unable to build anything either.

-Tim

On Sat, Jan 29, 2022 at 10:14 AM Eric Bresie  wrote:

> Any ideas?
>
> Eric Bresie
> ebre...@gmail.com
>
>
> On Fri, Jan 28, 2022 at 1:54 PM Eric Bresie  wrote:
>
> > Pulled from upstream master and see the following when attempting and
> > build of any type and I get the below. Any ideas?
> >
> >
> > ...
> > bootstrap:
> >  [echo] Bootstrapping NetBeans-specific Ant extensions...
> >
> > getjsonfile:
> >  [copy] Warning: Could not find file
> > C:\git\nb.latest\netbeans\nbbuild\netbeansrelease.json to copy.
> >  [copy] Warning: Could not find file
> > C:\git\nb.latest\netbeans\nbbuild\gitinfo.properties to copy.
> >
> > -gitinfo.ispresent:
> >
> > -git.up:
> >  [echo] Processing build with branch master and hash
> > 7e0f15f5edcbdb7e0c71aa70c5fcf441f0048449
> >
> > -git.down:
> >
> > getgitinformation:
> >  [echo] Building branch: ${metabuild.branch}
> > [releasejson] Taking release info from json
> > [releasejson] Processing release: [release1253, release1243, release90,
> > master, release110, release121, release120, release112, release123,
> > release100, release111, release122, release125, release113, release124,
> > release126]
> >
> > BUILD FAILED
> > C:\git\nb.latest\netbeans\nbbuild\build.xml:134: Cannot retrieve key
> > publish_apidoc, this is forShould we publish this Apidoc
> >
> > Eric Bresie
> > ebre...@gmail.com
> >
>


-- 
http://timboudreau.com

Re: License Changer Netbean Plugin

[Tim Boudreau]

There are a few updates to it in the Mavenized contrib repo on GitHub and
builds available from my update center server:
https://timboudreau.com/modules

-Tim


On Sun, Jan 16, 2022 at 10:45 PM Sean Carrick  wrote:

> Eric,
>
> If you are just wanting a copy of the License Changer plugin, you can still
> download it from here:
>
>
> https://web.archive.org/web/20161204021339/http://plugins.netbeans.org/plugin/17960/license-changer
> (download link works, though this is for NB8.2)
>
> I checked some later dates, but didn't see that the License Changer plugin
> was ever updated beyond NB8.2. At least you will be able to have it back in
> your installation, and I've not had problems with a lot of the old plugins
> from the 8.x days working in NB as late as 12.4 and 12.6, so there's hope
> that it will work...
>
> Sincerely,
>
> Sean Carrick
> Owner - PekinSOFT Systems
> s...@pekinsoft.com
> (309) 989-0672
>
>
> On Sun, Jan 16, 2022 at 8:58 AM Eric Bresie  wrote:
>
> > FIgured I'd check here to see if anyone may be able to help.
> >
> > I started working on some code in Netbeans and forgot to change the
> default
> > license and ended up with a lot of "default license" present with the
> > template references to how to set it up.
> >
> > However as I understand it, once set this only works on new files
> > and was curious if there is a way to do so with existing files.
> >
> > I've read (
> >
> >
> https://www.codejava.net/ides/netbeans/how-to-update-license-header-for-java-files-in-netbeans
> > )
> > further about an older "license-changer" plugin previously found here
> > http://plugins.netbeans.org/plugin/17960/license-changer but not
> available
> > on the new plugin portal (
> > https://plugins.netbeans.apache.org/?search=license-changer== ).
> >
> > One of the above articles mentions it was developed by Tim Boudreau in
> one
> > of the snapshots.
> >
> > I tried looking on the older archived plugin sites but from a cursor
> check
> > (unless I missed it), didn't find it here either.
> >
> >
> >
> https://cwiki.apache.org/confluence/display/NETBEANS/Where+to+download+plugins+for+NetBeans+10.0+and+earlier
> >
> > I'm also aware of the netbeans-tool Converter tool as mentioned here
> > https://www.mail-archive.com/dev@netbeans.apache.org/msg07114.html
> >
> > But was curious if a way to do within Netbeans and/or revive the plugin?
> >
> > Eric Bresie
> > ebre...@gmail.com
> >
>
-- 
http://timboudreau.com

Re: Add support for other programming languages

[Tim Boudreau]

FWIW, I took a crack at making https://github.com/drrb/rust-netbeans work
better a few years ago, with limited results. In particular, their Antlr
grammar generates insanely deep trees that are not great for performance.

I have been working on something more performant, also based on an ANTLR
grammar, but using Antlr's lexer modes to handle things like macro_rules!
which is almost an embedded language, based off of the generic Antlr
language support I built here:
https://github.com/timboudreau/ANTLR4-Plugins-for-NetBeans (all of the
parser and lexer glue is generated for you from a few [big] annotations).

There are a few things I'm looking forward to trying:  Rust's borrow
checker is really just a reference-graph cycle checker with a few rules
about when cycles are allowed (things that implement the Copy trait, e.g.
primitives and things with #[derive Copy]);  the Antlr stuff lets you hang
arbitrary analyzers off a parse that collect patterns you describe in
source trees and store them in a couple of very tight int-array-based data
structures that are binary-searchable, so you can collect a tree of
variable references (yes, you *can* build a tree with a pair of int[]'s -
https://j.mp/31O7Ir6 ), build a graph (just some arrays of bit-sets where
intersection operations are cheap - this is how graphs should be modeled in
code, not as actual trees of objects) and the analysis is pretty simple.

This has been a spare-time kind of thing, but I could share it somewhere if
anyone is interested.

-Tim

j2seplatform?

[Tim Boudreau]

I attempted to update dependencies on a huge suite of modules last night,
and notice that builds fail trying to download j2seplatform - and indeed,
the newest version of that that seems to be available is RELEASE123:
https://mvnrepository.com/artifact/org.netbeans.modules/org-netbeans-modules-java-j2seplatform

while the latest version of, say, Lookup, is RELEASE126 in Maven Central:
https://mvnrepository.com/artifact/org.netbeans.api/org-openide-util-lookup

Did it get removed, renamed, or did some modules not get published?  It
seems to still exist in source.

Thanks,

Tim

-- 
http://timboudreau.com

Re: Maven Daemon

[Tim Boudreau]

For multi-module builds, where it works (not everywhere), `mvn -T 8`
(really you want `numCores * 2`) buys much faster builds.  I'm not sure
exactly how it falls down in topologically sorting the graph of what to
build, but it occasionally does (for example, with my Antlr suite of 50+
modules, it works well until it gets to building the test netbeans
application project, and then tries to build that before some dependencies
are built), but if we could detect the cases where it might fail and avoid
those, it might provide a nice speed boost to building in the IDE as well.

-Tim

Mavenized NetBeans contrib/

[Tim Boudreau]

FYI, thanks to Jarda’s mirror of the old bits.NetBeans.org maven repo, the
Mavenized fork of the old NetBeans contrib/ repo is buildable once more:

https://github.com/timboudreau/netbeans-contrib

Is there a plan for this stuff ever to be contributed officially to Apache?
Oracle would have to do that.

I’ve made a fix or two in there, I think too paintcatcher and
quick-file-chooser.

Everything buildable is a module in the parent Pom.

FYI, because I created it from Hg, it accidentally contains NetBeans entire
source history back to 1998, up to the time it was split out as a separate
repo (probably during conversion to CVS in 2000 or so).

-Tim
-- 
http://timboudreau.com

Re: Apache JIRA vs GitHub issues / discussions

[Tim Boudreau]

GitHub’s bug tracker was, a few years ago, my gold standard for bug
trackers - precisely because it lacked the oceans of useless enterprise
features two people on earth actually want but everyone has to suffer with,
which Jira is thick with. Alas it seems they started adding them. IMO, it
is a thing where less is more.

Nonetheless, I would vote for the leaner and corner of the options, which
is decidedly Github’s issue tracker.

-Tim
-- 
http://timboudreau.com

Re: Project opening blocked on network I/O

[Tim Boudreau]

Well, great, but blocking on long running I/O is not cool (particularly if
you’re on a VPN that is flaky, the time out for the connection to fail
seems to be several minutes).

So, first, the check should be asynchronous wherever possible, not blocking
project opening. Second, it should not happen on every single project open
- have a TTL for the answer to the question, and don’t ask it again until
that has expired.

Multi minute project opening does not make a good impression.

-Tim

On Tue, Nov 23, 2021 at 6:26 AM Jaroslav Tulach 
wrote:

> Hello Tim,
> it is a known behavior present since 11.3 version. E.g. nothing new.
> Actually with
> https://github.com/apache/netbeans/pull/3251
> which makes nb-javac@17 part of NetBeans distributions, the FoD
> downloading/check could disappear for Java, Java EE clusters.
> -jt
>
> PS: It is still going to be needed for JavaFX cluster.
>
> st 17. 11. 2021 v 21:37 odesílatel Tim Boudreau 
> napsal:
>
> > I’ve noticed since I built a new build of NetBeans for coding a few weeks
> > ago, that opening projects got dramatically slower.
> >
> > Pulling a few thread dumps, it appears to be Feature-on-Demand
> triggering a
> > query of all update servers just in case a project will need some absent
> > feature.
> >
> > Known problem? Known fix?
> >
> > -Tim
> > --
> > http://timboudreau.com
> >
>
-- 
http://timboudreau.com

Re: 13+17

[Tim Boudreau]

Ugh, phone swipe typing

profile -> profiler

Tara -> that’s

Sorry,

Tim

On Wed, Nov 10, 2021 at 7:16 PM Tim Boudreau  wrote:

> FWIW, today locally I added a dep from the profile to an atomic bit set
> library I wrote Tara in maven central.
>
> Just add the maven coordinates and hash (upper case for some reason) to
> external/binaries-list.
>
> Have a look at the groovy modules for the format - it’s pretty
> self-explanatory.
>
> I don’t know if there’s some further process for getting a new dep into a
> release, but that will get you going.
>
> -Tim
>
> On Wed, Nov 10, 2021 at 4:57 PM Laszlo Kishalmi 
> wrote:
>
>> Well that would be nice if we can download Gradle binaries from their
>> repository.
>>
>> I try to recall what was the issue we needed to upload those binaries to
>> OSUOSL.
>>
>> If there is no legal problem to add Gradle's artifact repository to our
>> build, it would be really easy to move on.
>>
>> On 11/10/21 10:42, Michael Bien wrote:
>> > Hello,
>> >
>> > I got encouraged by Neil to start a new thread - its not my fault.
>> >
>> > current status:
>> >
>> > JDK 11 is the latest non-EOL JDK, NetBeans can be build or tested on.
>> >
>> >
>> > Building NB on JDK 17 involves most likely just a few property bumps
>> > and library updates. I could make the java cluster build just by doing
>> > that and by updating the build-time gradle wrapper.
>> > (https://github.com/apache/netbeans/pull/3278)
>> >
>> > I can't actually update the gradle wrapper myself (outside of making
>> > it point to a local zip for testing purposes) because i am not
>> > familiar with the lib hosting service the NB build uses - that is why
>> > its not part of the PR - someone else would have to do that (why can't
>> > it just use a maven repo?).
>> >
>> >
>> > That would be the easy part, testing on JDK 16+ is going to be more
>> > interesting, since NetBeans appears to hook into a very old version of
>> > osgi (3.9 via the netbinox module and friends as far as i see, which
>> > doesn't even officially support JDK8 btw). There need to be also some
>> > updates to junit JVM flags and build configs, but i have those in my
>> > stash and it isn't really worth mentioning, beside that its all over
>> > the place as to be expected in a big project. Using JDK 16 as a
>> > intermediate step before progressing to 17, might help there since the
>> > module system of 17 became more restrictive on top of all that.
>> >
>> >
>> > If NetBeans 13 would like to claim to support JDK 17 i would recommend
>> > to start with some of this early in the development cycle, esp with
>> > the low hanging fruits (gradle wrapper, which unblocks the
>> > build-java-cluster-on-17 PR etc).
>> >
>> > best regards,
>> >
>> > michael
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
>> > For additional commands, e-mail: dev-h...@netbeans.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.apache.org
>> For additional commands, e-mail: dev-h...@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>> --
> http://timboudreau.com
>
-- 
http://timboudreau.com

Re: 13+17

[Tim Boudreau]

FWIW, today locally I added a dep from the profile to an atomic bit set
library I wrote Tara in maven central.

Just add the maven coordinates and hash (upper case for some reason) to
external/binaries-list.

Have a look at the groovy modules for the format - it’s pretty
self-explanatory.

I don’t know if there’s some further process for getting a new dep into a
release, but that will get you going.

-Tim

On Wed, Nov 10, 2021 at 4:57 PM Laszlo Kishalmi 
wrote:

> Well that would be nice if we can download Gradle binaries from their
> repository.
>
> I try to recall what was the issue we needed to upload those binaries to
> OSUOSL.
>
> If there is no legal problem to add Gradle's artifact repository to our
> build, it would be really easy to move on.
>
> On 11/10/21 10:42, Michael Bien wrote:
> > Hello,
> >
> > I got encouraged by Neil to start a new thread - its not my fault.
> >
> > current status:
> >
> > JDK 11 is the latest non-EOL JDK, NetBeans can be build or tested on.
> >
> >
> > Building NB on JDK 17 involves most likely just a few property bumps
> > and library updates. I could make the java cluster build just by doing
> > that and by updating the build-time gradle wrapper.
> > (https://github.com/apache/netbeans/pull/3278)
> >
> > I can't actually update the gradle wrapper myself (outside of making
> > it point to a local zip for testing purposes) because i am not
> > familiar with the lib hosting service the NB build uses - that is why
> > its not part of the PR - someone else would have to do that (why can't
> > it just use a maven repo?).
> >
> >
> > That would be the easy part, testing on JDK 16+ is going to be more
> > interesting, since NetBeans appears to hook into a very old version of
> > osgi (3.9 via the netbinox module and friends as far as i see, which
> > doesn't even officially support JDK8 btw). There need to be also some
> > updates to junit JVM flags and build configs, but i have those in my
> > stash and it isn't really worth mentioning, beside that its all over
> > the place as to be expected in a big project. Using JDK 16 as a
> > intermediate step before progressing to 17, might help there since the
> > module system of 17 became more restrictive on top of all that.
> >
> >
> > If NetBeans 13 would like to claim to support JDK 17 i would recommend
> > to start with some of this early in the development cycle, esp with
> > the low hanging fruits (gradle wrapper, which unblocks the
> > build-java-cluster-on-17 PR etc).
> >
> > best regards,
> >
> > michael
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.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.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
> --
http://timboudreau.com

Re: Mocking framework

[Tim Boudreau]

Well, yes, but it doesn’t invent an entire implementation for you that
returns null for everything, including things that can’t be.

Mock services is fine - because you still wind up writing mocks, you just
use that to plumb them into the default lookup. Different species of thing.

-Tim

On Tue, Oct 12, 2021 at 2:58 AM Jaroslav Tulach 
wrote:

> so 9. 10. 2021 v 19:27 odesílatel Karl-Philipp Richter  >
> napsal:
>
> > Hi,
> > I wanted to contribute some unit tests to the project. As far I
> > understand there's no mocking framework in use currently looking
> >
>
> That's not  entirely true. There is `MockServices` class:
>
> https://bits.netbeans.org/dev/javadoc/org-netbeans-modules-nbjunit/org/netbeans/junit/MockServices.html
>
> It may not be as comfortable as Mockito & co., but it is enough to test
> everything as NetBeans architecture is based on "injectable singletons"
> pattern:
>
> http://wiki.apidesign.org/wiki/Injectable_Singleton
>
> -jt
>
-- 
http://timboudreau.com

Re: Mocking framework

[Tim Boudreau]

I think it will buy you less than you think, but it’s probably harmless.

I’ve got north of 20 years experience writing NetBeans’ code, and never
felt the need for one.

And I have to say, in my current gig I deal with a codebase with a lot of
existing mock based tests. They are mostly useless other than their one
purpose: To generate artificially high code coverage numbers management
likes to see, without having to do the work it takes to actually test that
the software does the right thing. It is trivial to write broken code that
all of the unit tests pass for. But the thing those tests DO test is call
sequences - what called what in what order. And they are incredibly fragile
to changes in that - you wind up with tests of the implementation details
of things, but not of whether or not they work.

So you have to run a bunch of harder to set up integration tests if you
actually want to know if you broke something. The unit tests are a lovely
Potemkin village that show fabulous “coverage” and tell you nothing about
whether the software works. They are useless.

You know what an integration tests really is? A unit test developers don’t
like running. Usually because it’s slow or needs databases or other
plumbing. That’s the actual bug, and the place that deserves investment -
making those things easy, so developers exercise as much of the code as
possible in every build. You can do that for most anything.

The one thing mocks shine for is if you depend on libraries that routinely
make incompatible changes - if the mocking library generates the
implementations, changes in things you don’t call don’t matter.

And that particular problem is one that NetBeans just doesn’t have - API
contracts are taken seriously.

So, do it if you’re excited about it, but consider whether you’ve exhausted
the paths to writing a real test instead. Or submitting a patch to the
thing you feel the need to mock to make what you want to do easier.

There are only two purpose tests serve:
 - Keeping the investment made in code by not breaking it
 - Giving developers rapid feedback when they do

Now, will investing in mocks actually improve either of those things? Or is
a better investment making it easier to test the thing you’re having
trouble with, so your tests run against the actual code they need to work
against in real life?

Coverage reports are a scourge. The dopamine hit of making that number go
up is too tempting, as is the urge to compete with everyone else’s numbers,
and you wind up writing tests of things like toString{} methods that are
used in logging if at all. Coverage > 80% is a strong indication that
developers are wasting time.

-Tim

On Sat, Oct 9, 2021 at 1:26 PM Karl-Philipp Richter 
wrote:

> Hi,
> I wanted to contribute some unit tests to the project. As far I
> understand there's no mocking framework in use currently looking at the
> test classes and answers to my recent "Getting Started" post.
>
> I think this is odd and a framework should be introduced quickly. I
> recommend Mockito. If you don't believe it's useful try writing a unit
> test which passes a reference to
> org.netbeans.modules.parsing.spi.indexing.Indexable to a unit under
> test. In under two minutes. This should take seconds.
>
> So far, I don't know how you measure coverage and what your requirements
> for minimal coverage are for new code and bugfixes is. High coverage
> isn't a guarantee for maintainable code and a high quality product,
> however low coverage in a safe indicator for the opposite. Having a
> mocking framework available and promoting it for new code in reviews
> will increase your development speed and reduce bugs severely.
>
> I'm opening a different thread from my "Getting Started" post since it's
> a more concrete issue.
>
> -Kalle
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
> --
http://timboudreau.com

Re: System.out.print buffered to Output Window

[Tim Boudreau]

Maven does awful things with console output - particularly in tests.

For tests, in the surefire configuration you can set
false for real time output. Also set it not to fork or
fork only once.

-Tim

On Sat, Aug 28, 2021 at 5:49 PM David Green  wrote:

> Probably good advice but I was trying to follow the direction of NetBeans
> to use Maven as the preferred build tool.
>
> At this point, for this semester, I am way too committed to Maven (it is an
> online course with all the course content is done).  This was a simple type
> it in like the textbook example (that I did not try) that bit me .
>
> For our immediate purpose, we just went with a println substitution but I
> felt I should report the bug with context for eventual repair (or at least
> consideration/documentation of a limitation).
>
> Thanks!
>
> On Sat, Aug 28, 2021 at 4:36 PM László Kishalmi  >
> wrote:
>
> > For those kind of projects use Ant or Gradle. They do not suffer from
> this
> > issue, and probably better suited for small student projects.
> >
> > On Sat, Aug 28, 2021, 13:16 David Green  wrote:
> >
> > > Thanks for the reply and insight.
> > >
> > > That does work at the command line (as did running it from a jar file).
> > I
> > > am seeking to have it work in the NetBeans Output window and I found
> that
> > > if I edited the Run (and Run File) Actions in the project properties to
> > use
> > > "java" instead of "exec", it does work.  It did generate a
> nbactions.xml
> > > file that was not there before.
> > >
> > > Should this be the default behavior when one generates Java with Maven
> |
> > > Java Application?  I am looking for configurations to use with students
> > who
> > > are learning the language and OO thinking and don't want to add any
> more
> > > friction than necessary.
> > >
> > > Are there any downsides of making this change?
> > >
> > > Dave
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Sat, Aug 28, 2021 at 2:15 PM Vladimir Machat 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > i believe it's exec:exec maven target problem, because if you run the
> > > > same code with exec:java it works perfectly, even without the flush()
> > > >
> > > > try 'mvn exec:java -Dexec.mainClass=dgreen.printbug.NewMain' from
> > > > command line
> > > >
> > > > On 28/08/2021 18:54, David Green wrote:
> > > > > In NetBeans 12.4 and verified to also behave this way on NetBeans
> > > > > 12.5-beta2, System.out.print is buffered such that it does not show
> > up
> > > in
> > > > > the NetBeans Output window until a System.out.println (or probably
> > > things
> > > > > like program end, and some buffer full scenario).
> > > > >
> > > > > Using JDK 15 and a Maven Project.  I am using macOS but my students
> > who
> > > > hit
> > > > > this problem are using Windows.
> > > > >
> > > > > Example code:
> > > > >
> > > > > package dgreen.printbug;
> > > > >
> > > > > import java.util.Scanner;
> > > > >
> > > > > /**
> > > > >   * Demo program showing that System.out.print's are not pushed to
> > > output
> > > > > window until a
> > > > >   * System.out.println
> > > > >   */
> > > > > public class NewMain {
> > > > >
> > > > >/** @param args the command line arguments */
> > > > >public static void main(String[] args) {
> > > > >  Scanner sc = new Scanner(System.in);
> > > > >  System.out.print("Enter your name: ");
> > > > >  System.out.flush(); // should not be necessary but does not
> work
> > > > either
> > > > >  String name = sc.nextLine();
> > > > >  System.out.println("Hi " + name);
> > > > >}
> > > > > }
> > > > >
> > > > > —-
> > > > > Running it after Clean & Build (or before)
> > > > >
> > > > > --- exec-maven-plugin:3.0.0:exec (default-cli) @ printbug ---
> > > > > dave
> > > > > Enter your name: Hi dave
> > > > >
> > >
> 
> > > > > BUILD SUCCESS
> > > > >
> > > > > where "dave" was typed in without the benefit of seeing the prompt.
> > > > >
> > > > > This works fine when run from true command line either inside a
> > > NetBeans
> > > > > Terminal Window or the real command line.
> > > > >
> > > > > In Jira as https://issues.apache.org/jira/browse/NETBEANS-5961
> > > > >
> > > > > Dave
> > > > >
> > > >
> > >
> >
>
-- 
http://timboudreau.com

Re: [DISCUSS] Compile with JDK-11 javac --release flag

[Tim Boudreau]

>
> Upgrading
> the javac.source (as opposed to target) might cause some issues, due to
> changes to type inferred, although these are probably not very likely.
>

...famous last words...

-Tim

Re: NetBeans platform: roadmap for compatibility with recent JDKs and the Java module system?

[Tim Boudreau]

I did the contrib modules - here -
https://github.com/timboudreau/netbeans-contrib

(did that stuff ever get officially donated to Apache?)

I think it's doable.  Have some (ugly, hacky, but worked), tooling I used
to generate pom files for modules and move stuff around - a project I
started in 2011 when I had to mavenize a huge project, that I just keep
around that grows a little whenever I have a refactor-lots-of-random
projects problem.

Most modules will be straightforward.  The hard part is the nbbuild
plumbing, which is very different than any Maven project type.  The maven
nbm plugin might be of some help, dunno.  Probably a lot of it could be
used as-is by the Antrun plugin (but too much of that and we've just
embedded an Ant build in a maven build, which kind of misses the point).

I'd start out by examining and cataloging *exactly* what all the stuff in
nbbuild does, make a list, or a play-by-play of doing a build noting which
pieces do what;  then for each one, make a list of standard maven tools
that could be harnessed to do those things, and the ones with nothing next
to them are the hard part.  Get that done, and the same stuff used to
convert contrib ought to be able to successfully convert most modules in
the codebase without much problem - all of those were written as NetBeans
source-tree modules, so other than a handful that do something unusual when
building, that ought to do the job.

-Tim





On Tue, Feb 9, 2021 at 8:57 AM Eric Bresie  wrote:

> I thought initial attempts to “mavenize” Netbeans had already been
> attempted (I believe by Tim) although maybe that was the contrib projects.
> Are there any plans to switch over to that (i.e. add all the Pom.xml files,
> updated any build documentation, etc.)?  Seems that would help some with
> dependency management in the whole build process
>
> Eric
>
> On Tue, Feb 9, 2021 at 3:43 AM Geertjan Wielenga
>  wrote:
>
> > The Gephi engineers are welcome to introduce Layrry to Apache NetBeans,
> > which appears to imply that all of Apache NetBeans needs to be Mavenized
> as
> > well, which the Gephi engineers are also welcome to contribute. Anyone
> else
> > here are welcome to do the same, it does appear to be a lot of work,
> though
> > it is always welcome.
> >
> > Gj
> >
> > On Tue, Feb 9, 2021 at 10:29 AM Clement Levallois <
> > clementlevall...@protonmail.com> wrote:
> >
> > > The support for loading / offloading of java modules at runtime has
> > > emerged: https://github.com/moditect/layrry
> > >
> > > For the compatibility with recent JDKs, I was referring to:
> > > - nbm-maven-plugin relies on pack200, which has been removed from the
> > JDK (
> > >
> >
> http://mail-archives.apache.org/mod_mbox/netbeans-users/202102.mbox/browser
> > ).
> > > Granted, this is a plugin not the NetBeans platform itself, but as a
> user
> > > of the tool this is blocking.
> > > - not sure about this one but: I think the NetBeans platform relies on
> > > libraries with java.xml or org.w3c namespaces (like batik)? These cause
> > > trouble when loaded in a java modular application.
> > >
> > >
> > >
> > >
> > > --
> > > Clément Levallois
> > > Associate Professor
> > > emlyon business school
> > > Twitter and Skype: @seinecle
> > > mobile: +33(0)6 59 08 33 92
> > >
> > > Sent with ProtonMail  Secure Email.
> > >
> > > ‐‐‐ Original Message ‐‐‐
> > > On Tuesday 9 February 2021 10:11, Geertjan Wielenga <
> > > geertjan.wiele...@googlemail.com> wrote:
> > >
> > > What does it mean "it is not entirely compatible with recent JDKs"?
> > >
> > > Of course, NetBeans uses the NetBeans module system. Let's move to the
> > > Java module system once it supports updates at runtime, i.e., you
> cannot
> > > plug new Java modules into a running Java application, can you?
> > >
> > > Gj
> > >
> > > On Tue, Feb 9, 2021 at 10:05 AM Clement Levallois
> > >  wrote:
> > >
> > >> Dear all,
> > >>
> > >> This is my first message to this list, happy to join!
> > >>
> > >> Gephi (www.gephi.org / https://github.com/gephi/gephi) is a
> successful
> > >> opensource desktop app built on top of the NetBeans platform
> > (release82). I
> > >> am not the maintainer of Gephi but I support its community of users
> > (8.4k
> > >> Facebook group: https://www.facebook.com/groups/gephi), and I have an
> > >> interest in integrating the headless version of Gephi in my own Java
> > >> projects.
> > >>
> > >> If I understand correctly, it seems that NetBeans (release82) is not
> > >> compatible with the Java module system. Also, it is not entirely
> > compatible
> > >> with recent JDKs as far as I am aware.
> > >>
> > >> May I ask what is the roadmap of development for the NetBeans
> platform,
> > >> with regards to compatibility with recent JDKs and in relation with
> the
> > >> Java modules? This would help understand better how is the future of
> > Gephi
> > >> shaping.
> > >>
> > >> Thank you!
> > >>
> > >> Clement
> > >>
> > >> --
> > >> Clément Levallois 

Abominable Groovy scanning performance

[Tim Boudreau]

Hi, all,

So, about 8 weeks ago I took a new job at Amazon, working on some
server-side tools stuff. Amazon, famously, has their own build system with
some interesting quirks.  Naturally I spent the first weekend after
starting there writing a NetBeans plugin for it, which is getting pretty
good - NetBeans project system is a much more natural fit for it than what
other IDEs offer.

One thing is killing me, though:  Lots of tests written in Groovy.  I've
managed to go to heroic lengths to manage the classpath and events fired
from it with tweezers and get times reasonable for very large Java
projects.

But those that have hundreds or thousands of Groovy tests are just brutal -
as in, run test-single *once* and that triggers a full *source *scan, and
for the next 20 minutes things like tab-expanding code templates and even
fix imports hang for a long time followed by the dreaded "Lengthy Operation
in Progress" dialog.

Anyone know of any way to improve this?  Is there a newer, faster Groovy
parser than whatever we're using that could be integrated?  Other ideas?

-Tim

-- 
http://timboudreau.com

Re: NB 12.2-rc2 Fedora 33 upload on run via SSH key stops working

[Tim Boudreau]

Is there a way to get NetBeans, if it shells out and calls an ssh binary,
to pass, say, -vv to ssh so you can see what’s being exchanged (keep adding
v’s for more verbose logging)?

Did the keys on the host you’re connecting to change?  Is the error message
bogus and what’s really happening is your client is noticing that the
public key of the remote host changed and is bailing because you might be
being MITM’d?

-Tim

On Sat, Nov 14, 2020 at 11:25 AM Jack W.  wrote:

> I'm pretty sure this is not a NB problem but you're such smart folks maybe
> you can help!
>
>- Running NB 12.2-rc2 on Ubuntu 20.04.1
>- Remote server *was* Fedora 32 server
>- SSH login from terminal via key worked
>- SSH upload on run in NB via key worked
>- *Last night upgraded remote server to Fedora 33 server*
>- SSH login from terminal via key *works*
>- SSH upload on run in NB via key *fails* with *"Cause: invalid
>privatekey"*
>- Using password for NB upload on run works
>
> Tried recreating the connection in NB.  Checked authorized_keys file etc.
> Read audit.log for SELinux. Googled. Fiddled around with SELinux. No luck.
>
> D'oh. Any tips?
>
> --
> ---
> Jack Woehr   # Woehr's Asymptote: The ratio of the time spent
> Box 51, Golden CO 80402  # administering productivity software over the
> time
> http://www.softwoehr.com # saved by said software eventually approximates
> 1.
>
-- 
http://timboudreau.com

Re: [Module] How to create a module that plays a sound whenever the Java parser detects an error

[Tim Boudreau]

You probably don't actually want to play a sound whenever the IDE detects
an error - different parts of the IDE may request a reparse of the
currently edited file (or any other file) for any reason at any time,
including a single edit triggering several consecutive reparses, depending
on the order things happen in.

You also likely don't want to play a sound every time an error is
encountered ANYWHERE in the currently edited file, as it's easy to, say,
change the signature of a method at the bottom of a file, turning calls to
that method into errors.

You *also* probably don't want to play a sound on every character of an
incompletely typed keyword until it is complete.

There is one thing I can't stress enough:  *In an IDE, the normal state of
source files is broken.*

What I *think *you actually want to do is:
 * Listen for changes in which document is currently being edited (listen
for changes on TopComponent.getRegistry(), try to get an EditorCookie from
the currently active component, if it has a document, get it and listen on
it;  or EditorRegistry may offer a simpler path to get the current editor)
 * Listen for changes in that document (plain old Swing document listener,
but probably ask - I think it is one of NbEditorUtilities,
LineDocumentUtilities or NbDocument - has a method
isTypingModification(DocumentEvent) that will let you differentiate
automated document changes like pastes and refactorings, from actual user
typing
 * Listen for changes in the caret position in that document - from the
document, get the editor from EditorRegistry, then
JTextComponent.getCaret().addCaretListener()
 * Listen for updates to the *error annotations* on that document.  I don't
know a fabulous, supported way to get that - the one module I ever wrote
that needed to do that achieved it via the hack of replacing the default
editor AnnotationViewFactory (thing that supplies the component with the
marks in the right margin of the editor on syntax errors, diffs, etc.) with
my own clone of the default one, which I could then get the error
annotations from:
https://github.com/timboudreau/netbeans-contrib/blob/master/fisheye/src/main/java/org/netbeans/modules/fisheye/hacks/FisheyeAnnotationViewFactory.java
 * Make your sound *only when:*
* The user has stopped typing for some threshold number of milliseconds
(350 is probably a good starting point) - RequestProcessor.Task is your
friend for rescheduling the pending potential beep on keystrokes
* An error annotation exists or comes into existence shortly after
typing stops *within one character of the caret position*

Now, all that said, I have to ask:  Is what you're building a torture
device?  What is the actual problem you're trying to solve?

-Tim

On Thu, Oct 15, 2020 at 8:35 AM  wrote:

> Greetings:
>
>
>
> I hope that you and all your loved ones are safe and healthy.  I write to
> you because I have spent days scouring over the documentation trying to
> find
> out how could I create a Netbeans module that plays a feedback sound
> whenever the user makes a syntax mistake when typing (Java) code.  All
> documentation I have read requires me to create my own Java lexer and
> parser, which I think can be avoided if I could just piggyback on the
> built-in Java parser and install a listener or something somewhere (I don't
> know!) that allows me to playback the sound when the error is detected.
> Please help!  This is for my doctoral dissertation.
>
>
>
> Best regards,
>
> Henry F. Bruckman Vargas
>
>
>
>

-- 
http://timboudreau.com

Re: API was: SVG icon graphics

[Tim Boudreau]

I tried mocking this up with auxiliary look and feel first, and it failed
horribly, hence the current approach.  Not sure if the problem was
something broken in JDK-14 - my goal was just to demonstrate it could be
done, so I moved on.  In general, auxiliary look and feels tickle a lot of
very rarely touched code-paths in Swing;  I'd expect breakage.  And it,
too, changes the type of the look and feel you get from
UIManager.getLookAndFeel(), so there's no clear win if you want to avoid
that.

All of the look and feel checking code *I ever wrote* and all of the code
Dafe Simonek wrote for the look and feel support in core tests on
lookAndFeel.getId(), which is the correct way to test that.

I don't know if anything elsewhere is doing it wrong - I suppose there
might be a case or two - but it ought to be pretty easy to find.

-Tim


On Mon, Sep 21, 2020 at 10:03 AM Neil C Smith  wrote:

> On Mon, 21 Sep 2020 at 13:58, Tim Boudreau  wrote:
> > The objection I forsee is "But that would mean aggressively loading stuff
> > into UIManager from every module".
>
> Surely only if you don't want to fix the problem?!
>
> > So here's how you solve that (the
> > delegating look and feel stuff would live in core.swing.plaf and just
> wrap
> > the LookAndFeel that's currently set on startup;
>
> I think delegation would break a bunch of hideous code that checks for
> LaF in many modules.  But auxiliary LaF might work for this?
>
> Best wishes,
>
> Neil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

-- 
http://timboudreau.com

Re: IDE Icon Registry (The SVG Story Continues) (AKA What about to clean up some mess)

[Tim Boudreau]

I have thought long ago that if we wanted to have svg icons in NetBeans, we
would be better off “compiling” them to a binary format that encapsulates
the drawing instructions (could result in much smaller files than either
XML, or PNG/GIF) - there are not many necessary bytes of information in
“move to x,y; set the color to...; draw a line to a,b”.

I wouldn’t turn them into classes - how many icons do we have, and what’s
the footprint of one in the perm gen multiplied by that number?

FWIW, I have the classes you’d need to do this “compiling” of svg - part of
imagine, which I use for the “native” file format for vector layers.

-Tim

On Wed, Sep 23, 2020 at 6:58 AM Jaroslav Tulach 
wrote:

> XML is bad. Does it mean that SVG is bad as well?
>
>
>
> XML, as implemented in Java with Xerces parser is a massive piece of
> software.
>
> It composes of about three thousand of classes. Does our current
>
> infrastructure for rendering SVG uses Xerces? That means we need to load
> all
>
> the infrastructure when drawing first SVG icon. That obviously has to slow
>
> NetBeans startup down.
>
>
>
> Once upon time an XML parser was necessary to start NetBeans (think of
>
> `layer.xml` files, of `config/Modules/*.xml` files, etc.). However when I
> was
>
> working on the NetBeans performance team, we eliminated all of that with
>
> caches. The goal was: No XML parsing on (second and subsequent) startup.
>
>
>
> Now, when we are switching to SVGs, we are reintroducing the Xerces
> overhead
>
> again. Can we avoid it?
>
>
>
> Here is a plan which, by a chance, also addressed the IDE Icon registry
>
> problem. Let's process the SVG icons during compile time and turn them
> into
>
> Java classes. Such technologies (based on Batik) exist (for example http://
>
> ebourg.github.io/flamingo-svg-transcoder/) and it is just a matter or
>
> integrating them into our build system. Let's imagine an annotation
> processor
>
> to process @SVG annotation:
>
>
>
> ```
>
> @SVG(resource="resources/wait.svg", className="GenericIcons")
>
> @SVG(resource="resources/wait-too-long.svg", className="GenericIcons")
>
> package org.openide.util;
>
> ```
>
>
>
> That would generate a class like
>
>
>
> ```java
>
> public GenericIcons {
>
>   private GenericIcons() {}
>
>   public static ImageIcon wait() {...}
>
>   public static ImageIcon waitTooLong() { ... }
>
> ```
>
>
>
> The class would contain all the instructions `fillRect`, `arc`, `lineTo`,
> etc.
>
> in the form of Java code. The SVG files would be removed from our JARs.
> E.g. we
>
> would immediately solve the problem of comments, long meta-data and XML
>
> parsing. All the icons would be available as Java code, ready to run and
> ready
>
> to be GCed once no icon from a generated class is in use.
>
>
>
> In addition to that this class would hook into existing resource oriented
> API,
>
> so all icons could be referred via their location. Moreover we could also
>
> implement Tim's suggestion to hook into UIDefault resources with
>
>
>
> ```java
>
> @SVG(uid={"wait-icon"})
>
> ```
>
>
>
> The `GenericIcons` class could be in private packages, or it could be
> placed
>
> into public packages. Then it would form an API other modules can use[1]
> and
>
> could avoid the duplication of icons.
>
>
>
> Would that work? If so, and we can eliminate all the XML parsing on
> startup,
>
> I'd be in support of some form of SVG icon registry.
>
>
>
> Best regards.
>
> -jt
>
>
>
> PS:  There is `@StaticResource` annotation currently, so there is no need
> to
>
> copy `wait` icon 30 times at various places even now...
>
>
>
> Dne úterý 22. září 2020 8:15:28 CEST, Laszlo Kishalmi napsal(a):
>
> > Dear all,
>
> >
>
> > We have about 4200 icons/images in the repository. most probably many of
>
> > them are duplicates, triplicates, multiplicates copied to different
>
> > locations.
>
> >
>
> > Just in a recent PR, Eirik added 34 new svg icons to 192 places.
>
> > (https://github.com/apache/netbeans/pull/2387)
>
> >
>
> > We have 28 instances of wait.gif (and 4 wait.png).
>
> >
>
> > I think before jumping into the svg era, we need to stop, look around
>
> > and think. Could we do better?
>
> >
>
> > I think, yes, there is a demand for a common icon catalog. Or more icon
>
> > catalogs (per cluster?)
>
> >
>
> > I've done a very raw sketch to get the base of a discussion. It is a raw
>
> > Idea I have in my mind: https://github.com/apache/netbeans/pull/2388
>
> >
>
> > My two main goals:
>
> >
>
> >   - Move reusable icons to a centralized place catalog. I'd imagine
>
> > these catalogs as public java Enums
>
> >   - Provide backward compatibility based on icon resource names
>
> >
>
> > Feedbacks/requirements/insights are welcome!
>
> >
>
> > BTW, I'm completely Ok if we do not do anything about this. I just
>
> > wanted to draw some attention on this issue.
>
> >
>
> > --
>
> >
>
> > Laszlo Kishalmi
>
> >
>
> >
>
> >
>
> > -
>
> > To 

Re: Re: Status of converting icons to SVG

[Tim Boudreau]

I have that a shot to - probably put more time into it than I should have.
The killer is identifying gradients in order to detect shapes that are
contiguous. Best results were simply finding a combination of channels in
one or another color space that got you the most contiguous pixels up to a
threshold.  There are some neat matrix multiplication tricks you can do to
get a gradient to cancel itself out, IF it is linear and IF you test
folding it on itself at close to the right angle.

Some icons got to a tolerable starting place for editing using a hacked
copy of potracej. But I wouldn’t say there’s much bang for the buck in
trying to automate it, it’s just fun to play with.

Re the issue of multiple designers, I think the trick does not have to be
one designer does it, but to have a style guide - a sort of shared
vocabulary of shapes, shadow thicknesses and angles, and color palettes.

Funny, I wish Imagine were closer to really usable - the thing I’m really
after with that is the thing I’ve wanted since I designed a lot of icons
for NetBeans in ’99 (most soon replaced when Sun mandated everything had to
have the Metal “flush 3D” look: I.e. an easy way to build up libraries for
reusable visual elements that are exactly the kind of vocabulary I’m
talking about.

-Tim

On Wed, Sep 16, 2020 at 1:00 PM Eirik Bakke  wrote:

> I've tried various automated approaches to vectorizing the icons--they
> don't produce very good results. Vectorizing algorithms don't work well for
> low-resolution images (16x16 in this case), and pixel art scaling
> algorithms (e.g. xBRZ or Kopf-Lischinski) don't work well for anti-aliased
> images (as our bitmap icons are).
>
>
>
> See for example https://people.csail.mit.edu/ebakke/misc/icons2xBRZ.html
> , which used the xBRZ algorithm.
>
>
>
> -- Eirik
>
>
>
> -Original Message-
>
> From: Eric Bresie 
>
> Sent: Sunday, September 13, 2020 10:20 AM
>
> To: dev@netbeans.apache.org
>
> Subject: Re: Re: Status of converting icons to SVG
>
>
>
> Was just looking around and saw this link [1]. Seems to favor Inkscape but
> there may also be ways to leverage gimp (another popular graphics tool -
> not specifically vector based but has some abilities to export with a
> little work).
>
>
>
> [1] https://askubuntu.com/questions/301540/export-image-as-svg-in-gimp
>
>
>
> Eric Bresie
>
> ebre...@gmail.com
>
>
>
> > On September 13, 2020 at 1:47:26 AM CDT, Jaroslav Tulach <
> jaroslav.tul...@gmail.com> wrote:
>
> > Hello Eirik,
>
> > thank you for your reply and these lists...
>
> >
>
> > > [2]
>
> > > https://people.csail.mit.edu/ebakke/misc/netbeans-icons/prioritized.
>
> > > html [3] https://people.csail.mit.edu/ebakke/misc/netbeans-icons/
>
> >
>
> > ...they are helpful. There was a question about the amount of NetBeans
>
> > icons to redraw inside of OracleLabs and it is great there already is an
> answer.
>
> >
>
> > > Graphic designers on UpWork ...
>
> > > ... crowdsourced effort ...
>
> > > ... the ideal way to do this would be to crowdfund the effort ...
>
> >
>
> > Apache can certainly accept donations. If you guys organize a
>
> > crowdfounding effort and use the money to draw icons that are then
>
> > donated to Apache, then great!
>
> >
>
> > The effort would have to be supported by users of NetBeans, not
>
> > developers - at least that's what I get from comments like the one by
> Matthias:
>
> >
>
> > > I still fail to see the difference between repetetive work on the
>
> > > code base working on source code and repetetive work on graphics.
>
> >
>
> > I also consider it unfair to pay a designer, but not pay me as an
>
> > architect
>
> > ;-) But if somebody wants to donate the money, then be it!
>
> >
>
> > > how to draw icons in
>
> > > Illustrator
>
> >
>
> > Again, if somebody pays for that fun, be it. However as others noted,
>
> > we are Apache and as such it would be better to adhere to open source
>
> > style. No Adobe, please, try [Apache
>
> > Draw](https://www.openoffice.org/) or at least [Inkscape](
> https://inkscape.org/).
>
> >
>
> > -jt
>
> >
>
> >
>
> > PS: A note on design...
>
> >
>
> > > If many people are working on the effort, a single
>
> > > > person will still ...
>
> > > > cleaning them up to a consistent standard
>
> >
>
> > People used to claim that [design cannot be done in a
>
> > committee](http:// wiki.apidesign.org/wiki/Teamwork). NetBeans is a
>
> > proof that it can be done - one just need to sit down and [specify
>
> > guidelines](http://wiki.apidesign.org/
>
> > wiki/API_Design_Checklist).
>
> >
>
> > > * Programming and graphic design are two different skillsets
>
> >
>
> > I believe there are common meta-design principles behind API design
>
> > and UI/ icon design. As such guidelines (like
>
> > https://material.io/design/guidelines-overview) could help. Of course,
>
> > there is an overhead to it, but when the scale is large (there cannot be
> a single designer for all Android apps, right?), there is no other way to
> move forward 

Re: API was: SVG icon graphics

[Tim Boudreau]

 Now, while we're discussing the API for SVG icons, one thing that seems
painfully missing from VectorIcon - I did some considerable work on Imagine
this winter - it now is more a vector editor than image editor, and loads
and saves SVG - though it needs some more work whenever I get back to it.
And in the spirit of eating my own dogfood, it now has mostly SVG icons
(created in it, of course :-)).

Anyway, this is the issue:  There is no way to specify a custom size for an
icon and get an instance of it.  Something like
someVectorIcon.getScaledInstance (width, height).  So we have scalable
icons...that are only available at *one fixed size?!*

The hideous workaround is to do something like:

class DoubleScaledIcon implements Icon {
 private final Icon original;
 public void paintIcon (Graphics g, Component c, int x, int y) {
  Graphics2D gg = (Graphics2d) g.create();
   try {
gg.setTransform(AffineTransform.getScaleInstance(2, 2));
original.paintIcon(gg, c, x, y);
   } finally {
   gg.dispose();
   }
 }
 public int getIconWidth() { return original.getIconWidth() * 2; }
 // ...
}

which is kind of ridiculous.  Yes, the idea is to have icons that scale to
the toolkit's scale.  But if you're going to have resolution-independent,
scalable icon objects in the first place, it seems bizarre to provide no
way other than hacks to scale them.

-Tim

Re: API was: SVG icon graphics

[Tim Boudreau]

>
> For example we have 28, hopefully the same, wait.gif in our current
> codebase (also there is 4 incarnation of a wait.png)
>
> So I think the need of some kind of API is there.
>

You know, I think there is one already:
https://docs.oracle.com/javase/9/docs/api/javax/swing/UIManager.html#getIcon-java.lang.Object-

The objection I forsee is "But that would mean aggressively loading stuff
into UIManager from every module".  So here's how you solve that (the
delegating look and feel stuff would live in core.swing.plaf and just wrap
the LookAndFeel that's currently set on startup;  it could cache loaded
values into the LAF's defaults table or whatever seems like a good idea):

static final class LAF extends LookAndFeel {

private final LookAndFeel delegate;
private final UID defaults;

public LAF(LookAndFeel delegate) {
this.delegate = delegate;
defaults = new UID(delegate.getDefaults());
}

@Override
public UIDefaults getDefaults() {
return defaults;
}
// implement getName(), etc. to delegate here...
}

static class UID extends UIDefaults {
private final UIDefaults delegate;

public UID(UIDefaults delegate) {
this.delegate = delegate;
}

@Override
public Object get(Object key) {
Object result = delegate.get(key);
if (result == null) {
result = lazyLoad(key);
}
return result;
}

private Object lazyLoad(Object key) {
if ("hello".equals(key)) {
return "world";
}
// lazy load from modules however you want here;
// could be as simple as
Lookup.getDefault().lookupAll(UIDefaults.class)
// and generate and register that class at build time for all
.svg files,
// or whatever you want
return null;
}
}

public static void main(String[] args) throws
UnsupportedLookAndFeelException {
UIManager.setLookAndFeel(new LAF(new MetalLookAndFeel()));
EventQueue.invokeLater(() -> {
JFrame jf = new JFrame();
String txt = UIManager.getString("hello");
jf.setContentPane(new JLabel("text is: '" + txt + "'"));
jf.pack();
jf.setVisible(true);
});
}

-Tim

Re: Speed of Maven build

[Tim Boudreau]

For larger multi-module projects, I'd tend to suspect that a substantial
chunk of the time is I/O-bound, parsing
XML - build one project with a substantial dependency tree.  How many POM
files both in the project and
under ~/.m2 need to parsed?  It would be interesting to instrument Maven
and get some timings out of that.

My fairly sprawling Antlr-IDE-support +
build-ide-plugins-with-a-compiled-antlr-grammar-and-some-annotations
framework clocks in at 68 pom files (probably 20 of these are projects for
tests to run against and test-support
libraries).  Certainly there are other in-the-ide performance issues
(change the version of one thing in the
dependency management section of the parent POM and plan not to use the IDE
for a few minutes while
scanning the universe brings the IDE to its knees).

It would be worth doing some measurements of.  I'd imagine if that proves
to be a root cause, some sort of
fast and queriable binary cache not unlike those the IDE uses for layer
contents and such in its cache
directory could be very helpful.  The trick would be identifying those
changes to POM files that do *not* require
invalidating the cached POM of every project that depends on it.

The 1.5 second improvement of a warm VM would be helpful on small projects,
but in any large tree of projects
where a build can take several minutes, it's not going to be significant.

I don't know if small monolithic single-pom projects are the common case,
or multi-module projects.  If multi-module
projects are the more common case, the warm-VM approach may not be worth
the engineering effort, given the
things that can go wrong and the effort required to defend against them.
You could have it internally cache and
keep hot information about dependencies to avoid I/O on subsequent builds,
but that could start to have a
substantial memory footprint.

My experience running with, say, -T 8 can have a substantial impact on
build times, but it appears not to take
into account test dependencies when sorting the projects into a build
order, so if you run tests, at some point
you wind up running against something that is in the process of being built
and it crashes.

-Tim

On Thu, Sep 3, 2020 at 4:10 PM Jesse Glick  wrote:

> On Thu, Aug 27, 2020 at 1:30 AM Jaroslav Tulach
>  wrote:
> > Hypothesis: Probably different Ant and Maven integration into the
> NetBeans IDE.
> > While Ant is executed in the same JVM as the IDE in an isolated
> classloader,
> > Maven is probably always started as a separate process.
>
> Yes this likely accounts for a lot of the difference.
>
> For a regular edit-test-edit-test cycle you can use the misleadingly
> named “compile on save” feature to save time, but in the case of Maven
> projects it still does launch `mvn`, just with a minimal set of mojos.
> At one point Maven CoS used the IDE’s built-in test runner
> (incidentally implemented with in-JVM Ant), just passing along the
> classpath introspected from the POM, but we switched to launching
> actual Maven to get better compatibility with projects with subtler
> configuration (IIRC).
>
> At any rate, I like the idea of reusing a JVM in the style of `mvnsh`
> for repeated Maven invocations in routine developer workflows. It
> would be important to keep not only Maven core loaded, but mojo class
> loaders, since these are often large and expensive to initialize. You
> would have to tune it in various ways, for example
>
> · Shut down automatically after some idle period.
> · Avoid sharing an instance between projects.
> · Run a regular forked `mvn` for executions that smell production-y,
> such as anything using the `clean` or `install` phases.
>
> It is possible that given a warm JVM, we could dispense with any
> special CoS tricks and still get reasonable performance from the stock
> lifecycle up to the `test` phase. It depends in part on the project
> config: if your POM is requesting a ton of plugins run in earlier
> phases (CheckStyle, etc.), there will still be lots of overhead unless
> the IDE passes a bunch of `-DskipSomething` properties.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

-- 
http://timboudreau.com

Handy way to switch JDKs quickly from a shell

[Tim Boudreau]

Since I wind up testing things on multiple JDKs frequently, I thought I'd
share a handy tool for quickly swapping both JAVA_HOME, and its values from
$PATH:

http://timboudreau.com/files/fixpath

You just set up shell aliases source the output of it.  Usage:

0.  Have nodejs on your path (depending on your Linux distro, you may need
to change the shebang at the top to reference "nodejs" instead of "node" -
Debian based distros use "nodejs")

1. Copy this script to some place like ~/bin/fixpath (you'll use that in
the shell aliases0

2. Set up some environment variables for different JDKs in your .bashrc:

export JDK_7=/opt/jdk7
export JDK_8=/opt/jdk8
export JDK_9=/opt/oracle-jdk-bin-9.0.4
export JDK_10=/opt/jdk10
export JDK_14=/opt/jdk14

3. Set up some aliases in your .bashrc too:
# Fast switch java versions for the current shell
alias jdk7='. <(~/bin/fixpath JDK_*/bin JDK_7/bin JAVA_HOME)'
alias jdk8='. <(~/bin/fixpath JDK_*/bin JDK_8/bin JAVA_HOME)'
alias jdk9='. <(~/bin/fixpath JDK_*/bin JDK_9/bin JAVA_HOME)'
alias jdk14='. <(~/bin/fixpath JDK_*/bin JDK_14/bin JAVA_HOME)'
alias jdkGraal='. <(~/bin/fixpath JDK_*/bin JDK_GRAAL/bin JAVA_HOME)'

4. Open a new shell, or `. ~/.bashrc` and you're good to go.  Just run the
command jdk14 and you're using JDK 14, etc.

Thought I'd share,

Tim

-- 
http://timboudreau.com

Re: Status of Ant vs Maven

[Tim Boudreau]

My 2c:

 - Ant and Ant-based projects are never going away, the same way that
Makefiles are never going away - even if nobody uses them for new projects
anymore, the need to interoperate with legacy code will not disappear
 - I'd be in favor of making Maven projects the default thing that's
pre-selected when users create a new project, and updating tutorials to
focus on it - I don't think Ant makes sense to push people towards for new
projects
 - Maven is here to stay.  Yes, it's slower than Ant, but as hardware gets
faster, that is less and less relevant.  And probably there are tons of
optimizations that could be done to Maven to make it much faster, so maybe
that's a place to contribute if it annoys you.
 - Gradle is neat;  the fact that it targets native build systems as a
first-class thing is a really good thing (ever tried to incorporate
building some C libraries into a Maven project build with a bunch of
Jenkins slaves on different OS's and bundle the artifacts?  I have.  It
ain't pretty).
  - However, in terms of ease of setup - say, you're a new developer on a
large existing project - how much coaching is it going to take from the
*one* person who understands the build system (because there always is one,
and rarely more than one) to get your system set up to build things?
Gradle's scriptability aims the evolution of a project's build squarely at
the bad old days of needing magic properties files in special locations,
and things like that:  https://timboudreau.com/blog/maven/read - basically,
whenever possible, the workflow to onboarding with a new project should be
"git clone foo; cd foo; do-the-build"

I once chatted for an hour or two with Hans Doktor (gradle creator) in
their office in San Francisco - it could be summed up as Me: "You're kind
of encouraging people to engage in practices that are known to cause long
term problems"; Hans: "Yup, and our customers like it."  The bottom line
from my perspective:  If you have a cohort of people that are really into
hitting themselves in the head with hammers, you can make good money
selling helmets and head pillows to make that practice cause less harm -
and if your goal is to make money, it's probably smart business to do
that.  If your goal is to improve the state of the art of engineering so
that there are less people in the world who ever want to hit themselves in
the head with a hammer, head-pillows probably aren't your thing.  IMO an
IDE should encourage the path of user-doesn't-hit-themselves-with-hammer as
the path of least resistance.  If there are a lot of head-hammer-hittters
out there, maybe supplement that with some head pillows, but don't hand
them the hammer.

-Tim


On Mon, Aug 10, 2020 at 12:06 PM Will Hartung  wrote:

> Ant has been the historic underlying build tool for Netbeans projects, but
> over the years, not only has NB been a very good companion with Maven,
> Maven is also much more popular industry wide.
>
> There was a comment on the user list recently about Java FX, and one reply
> was, paraphrasing, "the best way to use Java FX was to use Maven".
>
> I was also looking at the legacy NB Platform tutorials, which use Ant, but
> certainly need some updating.
>
> But that brought the question. Should one style of build be promoted over
> the other, are both systems "faithfully and fully supported", or is Ant
> going to perhaps slowly die on the vine of disinterest?
>
> Is there any internal mandate of ensuring compatibility between the two
> build system, especially in terms of ensuring high level things like
> wizards and whatnot work for both systems? If someone adds a new feature,
> contrived, "Create a Microprofile web service", is the project obligated
> (as much as it's obligated to do anything) to create a wizard for both Ant
> and Maven, or is it acceptable to only use one mechanism?
>
> Just curious if there's any formal position on the two systems and their
> status within the NB environment today.
>


-- 
http://timboudreau.com

Re: Post-install user experience

[Tim Boudreau]

>
>
> From the history of the PR: It breaks existing code/tests, so is
> basicly not mergeable.
>
> One observation about High DPI/antialias changes: Work should be done
> to fix Swing Upstream to provide sensual defaults, its not as if
> netbeans is the only Swing Application. If it is not done on the JDK
> level, future changes in the JDK might cause further problems.
>

No, no, 1 times no.  Been there, done that.

You do not wait for someone else to fix your problem.  What's the logic
there?  Well, who cares if nobody uses our product - it's not my job to fix
it, it's their fault, it's their problem.  How well do you think that
actually works?

One of the biggest handicaps NetBeans had, up through 2002, was that, post
Sun-acquisition, we were forced into using Metal Look & Feel regardless of
it looking alien on desktops of the day.  Aesthetics matter.  Readability
matters.  It is NOT a workable solution to just hope someone else solves
the problem.

As for High DPI, many monitors and video cards *do not accurately report
resolution or physical size.*  In the case of going through things like
projectors, HDMI to DVI adapter boxes and such, the information simply does
not exist.  No change in Swing is ever going to fix that.  No
auto-detection will ever work for that.

Asking the user on start needs to be coordinated with the other startup
> dialogs (Import Settings, Anonymous data sending). We already have an
> appearence tab to choose the LAF, why not add options there?
>

So, show the UI once with microscopic fonts and no antialiasing, and say
"Hey user, this looks awful, doesn't it?  How about we fix it and then
restart?".  We *could*, but why?  It's certainly not better user experience
to pop up something ugly, then pop something up in front of it to fix it,
then tear it all down and put it back again.  This isn't a "Oh, some users
might want to change this sometime, so let's add an option" thing.  It's a
"This will make most users run it once and uninstall it" thing.

The only thing that should be needed for tests to pass is for a variable to
be set in netbeans.conf *only when tests are run* that tells the startup
script the configuration is already set.

-Tim

Re: Post-install user experience

[Tim Boudreau]

I am not a committer here.  I was a committer on netbeans.org.

-Tim

On Sat, Aug 8, 2020 at 1:07 PM Geertjan Wielenga 
wrote:

> Hopefully we won’t need nb-javac forever and since you’re a committer, why
> not merge your PR?
>
> Gj
>
> On Sat, 8 Aug 2020 at 17:57, Tim Boudreau  wrote:
>
> > In order to double check that my update server had complete
> dependencies, I
> > installed a freshly-built build from master a couple of days ago and ran
> it
> > on a clean userdir - same experience anyone downloading it for the first
> > time will have.
> >
> > Issues:
> >  - Microscopic font sizes on a high-dpi screen and not antialiased (I
> > submitted a pull request to fix this almost a year ago -
> > https://github.com/apache/netbeans/pull/1446 )
> >  - J2SE projects (Ant-based) are not recognized.  On using Open File to
> > open a file in such a project, I get the admonishment to install nb-javac
> >  - After installing nb-javac, J2SE Ant-based projects are *still* not
> > enabled and such projects are not recognized (maven projects are)
> >
> > Basically, unless you're a netbeans expert, you are not going to know
> > about, or easily find information on
> >  - Adding -J-Dawt.useSystemAAFontSettings=lcd_hrgb to
> > $NB_HOME/etc/netbeans.conf
> >  - Adding --fontsize nn to $NB_HOME/etc/netbeans.conf
> >  - Manually enabling J2SE projects and dependencies in Tools | Plugins -
> a
> > new user doesn't know what a plugin is.
> >
> > Are we just producing builds for NetBeans experts, and we don't care if
> > anyone else uses it?  Because this is a recipe for "I installed it and I
> > couldn't read the text and couldn't open anything.  It's junk.  Don't
> > bother with it."  If we have the slightest ambition of releasing
> > professional-quality software, failing to fix low-hanging-fruit problems
> > any new user is going to encounter in the first five minutes using it and
> > have no idea how to fix is totally, totally unacceptable.
> >
> > Do *not* reply with "Well, some nice vendor is going to create their own
> > distribution and fix the user experience."  It's a cop-out and in fact
> > nobody is doing that.
> >
> > -Tim
> >
> > --
> > http://timboudreau.com
> >
>


-- 
http://timboudreau.com

Post-install user experience

[Tim Boudreau]

In order to double check that my update server had complete dependencies, I
installed a freshly-built build from master a couple of days ago and ran it
on a clean userdir - same experience anyone downloading it for the first
time will have.

Issues:
 - Microscopic font sizes on a high-dpi screen and not antialiased (I
submitted a pull request to fix this almost a year ago -
https://github.com/apache/netbeans/pull/1446 )
 - J2SE projects (Ant-based) are not recognized.  On using Open File to
open a file in such a project, I get the admonishment to install nb-javac
 - After installing nb-javac, J2SE Ant-based projects are *still* not
enabled and such projects are not recognized (maven projects are)

Basically, unless you're a netbeans expert, you are not going to know
about, or easily find information on
 - Adding -J-Dawt.useSystemAAFontSettings=lcd_hrgb to
$NB_HOME/etc/netbeans.conf
 - Adding --fontsize nn to $NB_HOME/etc/netbeans.conf
 - Manually enabling J2SE projects and dependencies in Tools | Plugins - a
new user doesn't know what a plugin is.

Are we just producing builds for NetBeans experts, and we don't care if
anyone else uses it?  Because this is a recipe for "I installed it and I
couldn't read the text and couldn't open anything.  It's junk.  Don't
bother with it."  If we have the slightest ambition of releasing
professional-quality software, failing to fix low-hanging-fruit problems
any new user is going to encounter in the first five minutes using it and
have no idea how to fix is totally, totally unacceptable.

Do *not* reply with "Well, some nice vendor is going to create their own
distribution and fix the user experience."  It's a cop-out and in fact
nobody is doing that.

-Tim

-- 
http://timboudreau.com

Re: nb-javac is now available !

[Tim Boudreau]

I do seem to be seeing fewer AssertionErrors from deep in the bowels of
javac while typing, so it seems like an improvement.

-Tim

On Thu, Aug 6, 2020 at 5:21 AM Neil C Smith  wrote:

> On Thu, 6 Aug 2020 at 10:15, Arvind Aprameya 
> wrote:
> > Neil, can we let you know by end of today if we can wait or go ahead
> with other fixes, will that be ok ?
>
> That's fine, no problem, thanks.
>
> Best wishes,
>
> Neil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

-- 
http://timboudreau.com

Re: How to debug netbeans

[Tim Boudreau]

Google it and you will find plenty of tutorials.  Geertjan's blog is full
of stuff - hopefully it survived his transition from Oracle.

-Tim

On Thu, Aug 6, 2020 at 8:21 AM marcos paulo 
wrote:

>  Tim Boudreau,
>
> thanks for your suggestion, i agree with you!!!like you said, that wrote
> code to netbeans for 21 years, i found your blogand your netbeans modules,
> that is great, fine work;
> i have a question, do you have some tutorial or do you suggest some
> tutorialhow write plugin and module to netbeans???
> Thanks
> Att,Marcos Paulo
>
> Le jeudi 6 août 2020 à 04:13:09 UTC−3, Tim Boudreau <
> niftin...@gmail.com> a écrit :
>
>  I've been developing NetBeans itself and plugins for it for 21 years now.
> In that time I have run a debugger against NetBeans maybe ONCE, to see if
> it worked.
>
> The startup time penalty, and the odds of winding up stepping through code
> you actually need to see, rather than marching endlessly through
> java.util.Logger's source code and other irrelevant stuff, are
> infinitesimal.  Debuggers are a great tool for debugging algorithms you can
> isolate in a test or tiny application, or for learning how programs work
> when you're learning to program.  As a tool for fixing things in huge
> applications with deep stacks, they're pretty much useless - way too much
> distracting noise and way to little signal.
>
> My suggestion is, learn to love logging statements and
> System.out.println().  You can isolate problems quite fast if you do a sort
> of logging-binary-search - add a logging statement entering the code where
> something goes wrong, and one at a point where that thing probably has
> already gone wrong.  If that works as expected, add logging at the midpoint
> between those two points.  Still okay at the midpoint?  Add one between the
> middle and end - and so forth until you're on the line where things really
> do go wrong (usually just narrowing down the scope lets you see it).
>
> Sorry to be a downer on debuggers, but I can count on one hand the number
> of times I have learned anything useful from a debugger, and all of those
> times I could have probably found it faster if I'd just read the code.
>
> -Tim
>



-- 
http://timboudreau.com

Re: How to debug netbeans

[Tim Boudreau]

I've been developing NetBeans itself and plugins for it for 21 years now.
In that time I have run a debugger against NetBeans maybe ONCE, to see if
it worked.

The startup time penalty, and the odds of winding up stepping through code
you actually need to see, rather than marching endlessly through
java.util.Logger's source code and other irrelevant stuff, are
infinitesimal.  Debuggers are a great tool for debugging algorithms you can
isolate in a test or tiny application, or for learning how programs work
when you're learning to program.  As a tool for fixing things in huge
applications with deep stacks, they're pretty much useless - way too much
distracting noise and way to little signal.

My suggestion is, learn to love logging statements and
System.out.println().  You can isolate problems quite fast if you do a sort
of logging-binary-search - add a logging statement entering the code where
something goes wrong, and one at a point where that thing probably has
already gone wrong.  If that works as expected, add logging at the midpoint
between those two points.  Still okay at the midpoint?  Add one between the
middle and end - and so forth until you're on the line where things really
do go wrong (usually just narrowing down the scope lets you see it).

Sorry to be a downer on debuggers, but I can count on one hand the number
of times I have learned anything useful from a debugger, and all of those
times I could have probably found it faster if I'd just read the code.

-Tim

Re: How to extend the Find Usages

[Tim Boudreau]

Register a RefactoringPlugin (IIRC) against text/x-java that responds to
WhereUsedQuery (double check these names - this is from memory). Google the
javadoc for that and it should get you started.

-Tim

On Sat, Jul 11, 2020 at 11:59 PM Rafael Santini 
wrote:

> Hi,
>
> What is the entry point to extend the Find Usages? I would like to extend
> the find for fields to support getters and setters generated by Lombok.
>
> Thanks,
>
> Rafael Santini
>
-- 
http://timboudreau.com

Re: Bypassing NetBeans Plugin Portal

[Tim Boudreau]

>
> What does this offer in practice, assuming any catalogue is downloaded from
> a trusted location over https, above validating the file against the file
> hash in the catalogue?
>

Not all that much, given that if you can compromise the download, you can
also compromise the hash.  Mostly just that the bits you downloaded were
saved correctly by your local machine.

Signing really becomes useful when you are downloading from mirror B and
want to verify the bits from trusted origin A.  But in this case, that
isn't really useful - if you can fake the bits, and the bits are the only
source of information about where the "trusted" origin of the bits is, then
of course that can be faked too.

Which is the problem certificate authorities exist to solve.  I'm not sure
treating Maven Central as a de-facto one is a fabulous idea though - and
certainly fails the test for non-open-source modules.

-Tim

Re: Bypassing NetBeans Plugin Portal

[Tim Boudreau]

On Thu, Jul 9, 2020 at 12:00 AM Ernie Rael  wrote:

> On 7/8/2020 6:48 PM, Tim Boudreau wrote:
> > Isn’t that security threat the reason JAR signing was invented?
>
> I've heard that all, or almost all, plugin portal nbm's are self-signed.
>
> How does that affect the security implications?
>
> I've also heard that PP3 doesn't require jar signing; see
> https://issues.apache.org/jira/browse/NETBEANS-2331


Absolutely there are issues with the fact that code-signing certificates
are expensive.  FWIW, I sign the NBMs I distribute with my timboudreau.com
certificate - which is *not* a code-signing certificate, so the build
generates a warning that the signature will only be valid for a short
time.  Curiously, the IDE reports them as self-signed, which is wrong.

I think it would be great if large organizations such as the ASF could
pressure or work with the LetsEncrypt folks to offer code-signing
certificates - it is ridiculous that they cost more than an ordinary SSL
cert.

As for what security signing offers, it offers exactly the same thing as
HTTPS does:  You can verify that the bits are the same bits that the author
signed, unmodified.   Just as with HTTPS, that does not tell you that the
author is trustworthy - that is up to you - it just tells you that the
author is who you think it is and the bits are what you think they are.


Limiting the universe to a single plugin portal does *absolutely nothing* to
change the security situation.  Whether you have one portal *full of
self-signed nbms* or 10,000 portals *full of self-signed nbms*, the
situation is exactly the same.

The *really, really right way* to solve this is to fix the situation with
code-signing certificates (and make it less of a PITA to use them - I
seriously think most tools and APIs for working with encryption are
intentionally obfuscated, and Java's support for encryption made that even
worse by inventing new abstruse and wholly unnecessary concepts to make it
even more initimidating - whether that's due to governments not wanting
people to use encryption, or because being a cryptographer is mutually
incompatible with understanding usability I leave as an exercise to the
reader).

That said, since we're unlikely to change the situation with regard to
code-signing certs worldwide any time soon, Jesse's suggestion in the bug
linked above is the more reasonable way to go:  As long as signature
information is downloaded via HTTPS from the same origin as the NBM, and
the receiver knows how to verify the bits with it, the HTTPS connection is
solving the "am I being man-in-the-middled" problem, and that's the only
thing the certificate in JAR signing adds to the picture.  The IDE just
needs to enforce that the signature must by downloaded from the same domain
using the same HTTPS cert as the NBM.

There's no reason to limit the places NBMs can be downloaded from to Maven
Central - just define the metadata (which could *be* the same as the gpg
signatures Maven uses) and have the code that downloads it enforce the
same-domain requirement, so that anyone running an update server can
provide signatures.

-Tim

Re: Bypassing NetBeans Plugin Portal

[Tim Boudreau]

Isn’t that security threat the reason JAR signing was invented?

-Tim

On Mon, Jul 6, 2020 at 1:12 PM Jaroslav Tulach 
wrote:

> Hi.
> Recently I have noticed discussion explaining how to bypass NetBeans
> Plugin Portal. The
> usual way is to create a NetBeans module extension to provide own update
> center
> definition and register it in NetBeans Plugin Portal. Once a user
> downloads such module,
> the provided update center gets activated and can distribute new updates
> or new
> modules.
>
> Isn't this a security thread? Shouldn't we ban modules that register own
> update centers?
>
> When we worked on designing the new update center based on Maven central
> repository,
> I wanted to benefit from the organizational structure of Maven repository:
>
> - identity of people who publish there is known to some extent
> - it is not possible to alter once published content
> - there are sources next to each published module
>
> With such constraints we can more properly verify what 3rd party NetBeans
> extensions do
> before we approve them.. With modules that bypass our Plugin Portal by
> installing their
> own catalog, we loose any control. Owners of such catalogs can publish
> anything, anytime
> to anyone and change that whenever they want. It's just a matter of time
> till somebody
> exploits that.
>
> Shouldn't we require 3rd party modules available via the default NetBeans
> Update center
> to avoid such bypassing and always release new versions via Maven Central
> and NetBeans
> Plugin Portal?
>
> -jt
>
> --
http://timboudreau.com

Re: Lookup, optional method

[Tim Boudreau]

A year or two ago I might have +1'd this.  Having used my own lookup-like
API for something unrelated, that returns Optional, I can relate the
following:

 - About half the time, if the Optional is actually not present, something
has gone horribly, horribly wrong; so you either write code that assumes
it's always present, or you get annoyed that you stupidly used it when you
have to unwrap it.  Typical case:  Two pieces of code both have a reference
to the Lookup (equivalent), they don't know about each other, but they do
have an order of precedence they run in, and if the first isn't run, the
second one won't be either.  Yeah, they could share a reference to the
object they want to look up, but then they'd be carrying around a reference
to the Lookup and the object (greater leak potential), or they may
parameterize on different types and can't practically share a reference to
the same type - plenty of reasons you can wind up in that situation.

 - The thing that's actually worthwhile about it is the methods that take a
lambda, but they ones on Optional have some serious shortcomings - you call:
public void ifPresent(Consumer consumer) {
and there is nothing to tell you if your consumer was called or not (you
could call orElse() on optional - with some Lookups, that's going to
trigger a bunch of work a second time, when the code you're calling could
simply return a boolean.

 - In the non-lambda usage, there's nothing but aesthetics to differentiate if
(foo == null) from if (foo.isPresent()) - which is to say: Java has nulls.
It's not going to stop having nulls, and everyone needs to get over it.
Yeah, James Gosling called it the billion dollar mistake or something like
that, but whether it is or isn't, pretty drapes in the foyer isn't going to
un-make it.

I could imagine +1'ing something like

 boolean ifPresent(Class type, Consumer consumer)

though

 R ifPresent(Class type, Function processor)

would probably, in the common case, be more useful, since the function
author can return a result that indicates if it ran easily enough.  But you
can also create this for yourself anywhere:

public static  ifNonNull(Supplier, Function processor)

public static  specializedForLookup(Lookup lkp, Class type,
Function func) {
T obj = lkp.lookup(type);
 return obj == null ? null : func.apply(obj);
}

and, well, you have to pass the Lookup, but is the value of not having to
pass one argument worth a potentially breaking change in a core class?

-Tim

On Thu, Jul 2, 2020 at 12:32 PM Hector Espert 
wrote:

> A few months ago, I created a draft PR to add a method in the Lookup class
> that returns a Java optional.
>
> https://github.com/apache/netbeans/pull/2063
>
> There wasn't any special reason. Only I used it to study how the Netbeans
> documentation works.
>
> If anybody is interested in that, I will continue with the development. If
> not, I will close the PR.
>
> Regards, Hector
>


-- 
http://timboudreau.com

Re: How to self host the plugins

[Tim Boudreau]

One option is this - follow the link in the page head:

https://timboudreau.com/modules

So, set up Jenkins or similar somewhere to build your modules and archive
the nbm file for each module.

Run the server (just java -jar, no application servers), and add URLs to
the last successful build link from , in the form at the bottom of the home
page.

The server will poll the URLs periodically, and if updated, the new version
will be served. Tiny and efficient.

One caveat: set up your build so the version is NOT appended to the nbm
file’s name, so the URL is the same for every build.

-Tim

On Wed, Jul 1, 2020 at 10:08 PM Peter Cheung  wrote:

> Hi
>How to setup a web server to self-host the plugins?
> Thanks
> From Peter
>
-- 
http://timboudreau.com

Re: Compatibility was: Updates to Apache NetBeans 12.0

[Tim Boudreau]

>
>
> In case of Batik, there may be someone creating a plugin for NetBeans 12.0
> that depends on it. It is (shall be) in our interest to make sure that
> such
> plugin continues to work "eternally".


In fact, here is one right now (I've been giving some vector editor
goodness to my old modularity demo, Imagine):
https://github.com/timboudreau/imagine/tree/master/Imagine/svg-io  :-)

Currently it bundles its own Batik, but it really should use the NetBeans
one.

-Tim

Re: AW: NETBEANS-1678: Option for coloring EOL - Could someone point at similar code?

[Tim Boudreau]

Funny, I implemented HighlightsContainer a while back for performance
reasons (coalescing large numbers of overlapping highlights resulting in
multi-second hangs), for the Antlr preview stuff where the highlighting
gets regenerated frequently and can be very complex.  A handy library for
that (and in general working with coalescing intersecting ranges of
coordinates - I used it in a memory manager for a virtual filesystem as
well) is here: https://github.com/timboudreau/util/tree/master/range -
maven central coordinates are com.mastfrog:range:2.6.11.  I've thought
about patching OffsetsBag to use it - I have a whole bunch of
collections-based-on-primitive-arrays-and-binary-search classes that could
probably improve the performance of a lot of editor functionality that I've
developed over the years (ironically, I got started doing that with the
class that manages line offsets in the output window - autoboxed Integer
instances are around 9x slower, and that's critical path of painting code).

Looking at your code a bit, a few comments:

 - I don't think you need the call to fire events on changedUpdate() in
your DocumentListener - that *should* (YMMV) only be called for attribute
changes in the document, not text changes
 - You probably want StyleConstants.Background if you want anything to be
visible - newlines don't have a foreground color.  That said, the result is
probably not what you're trying to do -
https://timboudreau.com/files/screen/06-27-2020_10-07-18.png - since the
entire end of every line gets painted as a solid color.  There is a custom
NetBeans attribute for drawing top / left / bottom / right edges of a box
around a token (I think this is what the editor uses for boxes around
things during instant rename).  Setting that attribute for just the *left
edge* of the characters matched - EditorStyleConstants.LeftBorderLineColor
- ought to achieve the goal of simply drawing some sort of mark where the
newline is.  That might be closer to just an indication of where the
newline is, though it isn't terribly pretty:
https://timboudreau.com/files/screen/06-27-2020_10-27-04.png

  - In playing with it, I tried out a few other likely SwingConstants
options - draw a pilcrow in an icon and paint it, or use
ComposedTextAttribute to draw one, but it seems the editor doesn't support
those - so without a different approach to get hold of the Graphics during
painting, EditorStyleConstants.LeftBorderLineColor may be as good as it gets

 - In updateHighlightsOnRemoval(), don't you want the second argument to
fireHighlightsChange() to be removedBlockEndOffset?  Right now the change
is always zero-sized

 - Your code for the HighlightsContainer follows the tutorial code, which
is fine.  I've found it more efficient to weakly attach a ComponentListener
to the editor component, and when it becomes visible, start listening to
the document, and when it gets hidden/removed, detach the document
listener.  That way, if the user, say, does a Git pull in a shell while a
file is open in the IDE, you don't wind up recomputing a bunch of
highlights that will may never be shown

 - You will want to make the color settable and make it possible to turn
off EOL highlighting - options panel or added color in font color settings,
however you choose.  Hint:  If you don't want to make the color settable,
but want it to guarantee its shows up, but not annoyingly, just grab the
default foreground and background from FontColorSettings, and use
Color.toHSBColor() to convert both to HSB, and then adjust the brightness
component from the background some percentage toward the foreground
color's, and convert the result back to a Color and use that.

-Tim

On Tue, Jun 23, 2020 at 5:51 PM Dmitry Semikin 
wrote:

> Hello Everyone,
>
> The topic does not seem to attract too much attention, but I hope, it is
> just lack of time. It is the same for me, so the progress does not go as
> fast as I’d like it to…
>
> Nevertheless, meanwhile I updated the example implementation, so that it
> implements now HighlightsContainer directly instead of using OffsetsBag. If
> someone is interested it is still available on GitHub here:
> https://github.com/DmitrySemikin/nb-eol-highlighter
>
> Besides after some wandering around in the depths of NetBeans projects I
> found, where the highlightings for whitespaces are implemented. The
> following files are involved:
>
> HighlightsContainer implementation for Whitespaces:
>
> netbeans\ide\editor.lib2\src\org\netbeans\modules\editor\lib2\highlighting\WhitespaceHighlighting.java
>
> Corresponding factory:
>
> netbeans\ide\editor.lib2\src\org\netbeans\modules\editor\lib2\highlighting\Factory.java
>
> Registration of the factory is done in the following layer.xml:
>
> netbeans\ide\editor.lib2\src\org\netbeans\modules\editor\lib2\resources\layer.xml
>
> Specification of the categories (~FontsAndColors.xml)
>
> netbeans\ide\editor\src\org\netbeans\modules\editor\resources\NetBeans-editor.xml
> It's virtual path in 

Re: Zulu with NetBeans

[Tim Boudreau]

I think if Azul is asking for some labor from the community here, some sort
of contribution of value that supports the community might be a nice idea.

Like, say, hosting update center mirrors or, given that mirror-based
updates seem to be proving problematic for some people on corporate
networks, a formal update server that could be used in their place for
those users, would be good.  Show that it's a two-way street.

Seems like there are a number of areas when it comes to web infrastructure
where Apache is rather limited, where a company with global reach like Azul
could significantly contribute, and the cost of it would be the size of a
rounding error in their budget.  If you want to get, give.

-Tim

On Sat, Jun 27, 2020 at 2:33 AM Geertjan Wielenga 
wrote:

> Hi all,
>
> If Azul were to distribute a bundle of NetBeans with Zulu, i.e., the bundle
> would be downloadable from an Azul domain, would we as a community be
> interested in doing the work of putting that bundle together?
>
> It would be a process that would take place once a year, with our NetBeans
> LTS together with whatever the current LTS of Zulu is at that time.
>
> We in the NetBeans community would create and test the bundle, and would
> approve it as a community — sometime after the NetCAT process since the
> binaries would need to exist for the bundle to be created, so maybe simply
> by approving the bundle in a thread, not as an official vote thread since
> the bundle would not be an Apache release, of course.
>
> Potentially, Azul could create a plugin for updating Zulu after it’s been
> installed — and put that plugin into our Plugin Portal.
>
> This would solve our problem of not having a JDK vendor that provides the
> complete NetBeans out of the box experience. The bundle would be called
> “Apache NetBeans Zulu Bundle” and we’d point to it from our download page,
> with statements that it is not an Apache release, etc.
>
> With my three hats “Apache”, “NetBeans”, “Azul” on at the same time, this
> sounds good.
>
> Thoughts on this?
>
> Thanks,
>
> Gj
>


-- 
http://timboudreau.com

Re: NetBeans tests and character encoding

[Tim Boudreau]

>
>
> How can I fix opening file in
>
> https://github.com/apache/netbeans/blob/0636a9ece532761c582ff2062c7baebef72debf6/php/php.latte/test/unit/src/org/netbeans/modules/php/latte/indent/LatteIndenterTestBase.java#L61
> ?
>
> File is opened by calling "DataObject dobj = DataObject.find(fo);" where
> fo is instance of FileObject. I don't know how to read input as UTF-8.
>
> Opened file has wrong encoding, result of test is compared to (now
> correct) expected file content and test fails.
>

I'd try setting file.encoding in the setup() method.  Or if you want to get
fancy, put an instance of FileEncodingQueryImplementation that always
returns UTF-8 in MockServices in setup.  Or ensure an implementation of
FileEncodingQueryImplementation is in the DataObject's lookup if you're
supplying the DataLoader for it and can instantiate the DataObject subclass
you want for it.

The behavior in general is correct - if nothing exists to specify an
alternate encoding for a file (such as a project), assume the default
system encoding.  Something just needs to handle the special case of
running tests on a machine whose default encoding is *not* UTF-8 - to the
test, it's just a file with no encoding information associated with, so it
defaults to the best available option, which is the system encoding.
Trying to do something special globally for the case of tests would likely
just break tests that test encoding handling.

-Tim



>
> > I assume that in the past the unittests were developed on linux
> > machines and were run on the linux based CI infrastructure.
> Yes, I fixed different errors in tests on Windows caused by different
> directory separator.
> > You can try to pass the file encoding to the ant call. If you run the
> > unittest from the IDE, you can "rerun" (second green double arrow in
> > the output tab) and specifiy properties there.
> >
> > HTH
> >
> > Matthias
> >
> Thanks.
>
> Tom
>
>

-- 
http://timboudreau.com

Re: Gratuitous selenium dependencies added to Maven projects

[Tim Boudreau]

>
>
> Note that from 12.0 Beta 4 onwards, JUnit 4 is back in that dialog:
>

I'm running a build of git master from a couple of days ago, and it is
there in mine too.


> Maybe try that (I see in there right now in 12.0 Beta 5, the following:
> JUnit, TestNG, JUnit4, and Selenium) and see if it helps.
>

Any reason 12.0 beta 5 would substantially differ from master?  Not to
mention I've been seeing this bug occasionally for at least two years.

-Tim

Re: Gratuitous selenium dependencies added to Maven projects

[Tim Boudreau]

Just reproduced it again on a NetBeans module project, on a different
machine than I usually use for coding - different userdir, version of
NetBeans, etc.  I'm curious if anyone else can.  Steps to reproduce:

1. Clone this repo:
git clone g...@github.com:timboudreau/ANTLR4-Plugins-for-NetBeans.git

2.  Check out the commit I was working against:
cd ANTLR4-Plugins-for-NetBeans
git checkout 6c0fd2dbd76ab09182cafc937a961d4ff5abe391

3. Build it once
mvn -Dmaven.test.skip.exec=true clean install

4.  Open the subproject antlr-utils in the IDE, let it load and expand its
one package

5.  Right click the class Criteria.java and choose *Tools | Create/Update
Tests*

6.  Accept the defaults, change nothing in the dialog (which contains no
mention of Selenium), just click *OK* (note this means you are selecting
JUnit as the test framework, even though the parent project depends on
JUnit 4 and that's what should be used - perhaps this is the trigger?).

then see if this pile of dependencies gets added to the pom.xml (and the
build will fail because of dependency convergence - Selenium is sloppy
about dependency management) - note both JUnit 4 and JUnit are added, *and *the
parent pom specifies a different version of JUnit 4 which the version spec
overrides:


org.junit.jupiter
junit-jupiter-api
5.6.0
test


org.junit.jupiter
junit-jupiter-params
5.6.0
test


org.junit.jupiter
junit-jupiter-engine
5.6.0
test


org.seleniumhq.selenium
selenium-java
test
2.44.0


com.opera
operadriver
test
1.5


org.seleniumhq.selenium
selenium-remote-driver




junit
junit
test
4.11

Re: MultiView using the mavenized module project

[Tim Boudreau]

Any chance your module with the file type is configured to be an
*autoload* module?
If so, the jar may not be opened until something that depends on it
requires it, so your loader won't be registered.

-Tim

On Sun, May 17, 2020 at 4:56 PM John Kostaras  wrote:

> Hallo,
>
> I wonder if anybody has tried to create to create a new File Type using the
> mavenized module project. Let me be more specific.
>
>- NetBeans 11.3
>- Follow this tutorial
> to
> create
>a new File type, but instead of creating a "Java with Ant -> NetBeans
>Modules -> Module" to create a NB module, use a "Java with Maven ->
>NetBeans Module" NB module.
>- If you follow the steps of the tutorial using the Ant NB module,
>everything runs fine and you can open the file with the defined
> extension
>in a MultiView seeing both Source and Visual buttons (and History)
>- If you follow the tutorial's steps using the Maven NB module, then the
>file type registration seems to not be successful; when you open a file
>with the defined extension the MultiView only shows the Source (and
>History) button(s), i.e. no Visual and if you open the Properties
> window it
>says that the file type is not recognized.
>   - Steps are:
>  1. New > Other > Module Development > File Type, which
> creates the *DataObject.java,
>  VisualElement.java *and the *Template *file.
>
>
>1. Is it a bug or am I 'm doing something wrong?
>2. There seems to not be a lot of tutorials around; I would appreciate
>if you could point me to a better one than the one I mention, or I could
>write an updated tutorial (if it works and I have done something wrong)
>
> Thank you in advance for the prompt reply.
>
> John.
>


-- 
http://timboudreau.com

Re: Netbeans notifications API

[Tim Boudreau]

>
> I disagree with the "Much simpler". Everytime a java programm just
> execs an external programm "some how" handles its output and tries to
> do something intelligent with it, somewhere a small cute kitten dies.
>

As they do when you blindly assume some native library exists on a random
user's machine on an unknown version of Linux, is a version you know how to
talk to, and has kept binary compatibility with the way the IDE wants to
talk to it, and won't, say, segfault the JVM instead.  A script failing is
much less dramatic.

As someone who runs Gentoo Linux and configures my USE flags liberally to
de-bloat my OS by compiling common libraries with many features I have no
use for absent, I can tell you for sure that just because a library has the
same name as the one you're looking for does *not* mean it contains all the
calls a developer might think it does based on whatever happened to be on
their machine when they wrote a feature.

A script failing can't take the JVM with it.

-Tim

Re: Gratuitous selenium dependencies added to Maven projects

[Tim Boudreau]

Not using Selenium to test a NetBeans module, no :-)

I have written one library a long time ago which is part of this library
collection - https://github.com/timboudreau/mastfrog-parent and it has
happened in projects that used some other library with the same parent
POM.  But it's hard to believe that would be a path by which something
could assume that.  It can happen to projects completely unrelated to
Selenium or even web development.

A few times it has been especially painful, since either it drags in a
dependency on an older version of JUnit, or creates a dependency version
conflict the enforcer plugin complains about, and then I find that three
libraries deep, something got that damned selenium dependency added to it,
so it's hauling in a version of, say, log4j that conflicts with another
project.  Very annoying, and in particular, IDEs should not ever do this
sort of thing without checking with the user.

-Tim


On Mon, May 18, 2020 at 3:10 PM John Mc  wrote:

> Hi Tim,
>
> I cant help you with answering how its happening, as I've never used
> Selenium in NetBeans, but I think your right that its NetBeans adding it:
>
> https://github.com/apache/netbeans/blob/accdbada0a9c5105bd3f06e435024230c1618316/java/selenium2.maven/src/org/netbeans/modules/selenium2/maven/Selenium2MavenSupportImpl.java
>
> Do you have any Selenium Tests, or Unit Test, and NetBeans somehow assumed
> you wanted Selenium included?
>
> Regards
>
> John
>
> On Mon, 18 May 2020 at 19:59, Tim Boudreau  wrote:
>
> > Every now and then, maybe once every few months over the last few years,
> > I'll be working on a Maven project - maybe something completely unrelated
> > to web development (at the moment it just happened to a NetBeans module
> > project) - when I will notice the build behaving weirdly or downloading
> > things that could not possibly be dependencies of it.  And I will find
> that
> > some pom.xml file within the project has had this added to it:
> >
> > 
> > org.seleniumhq.selenium
> > selenium-java
> > test
> > 2.44.0
> > 
> > 
> > com.opera
> > operadriver
> > test
> > 1.5
> > 
> > 
> > org.seleniumhq.selenium
> > selenium-remote-driver
> > 
> > 
> > 
> >
> > It seems pretty clear that NetBeans is doing this - but what?  And why?
> > Accidental keyboard shortcut?  Something else?
> >
> > Thanks,
> >
> > Tim
> >
> > --
> > http://timboudreau.com
> >
>


-- 
http://timboudreau.com

Gratuitous selenium dependencies added to Maven projects

[Tim Boudreau]

Every now and then, maybe once every few months over the last few years,
I'll be working on a Maven project - maybe something completely unrelated
to web development (at the moment it just happened to a NetBeans module
project) - when I will notice the build behaving weirdly or downloading
things that could not possibly be dependencies of it.  And I will find that
some pom.xml file within the project has had this added to it:


org.seleniumhq.selenium
selenium-java
test
2.44.0


com.opera
operadriver
test
1.5


org.seleniumhq.selenium
selenium-remote-driver




It seems pretty clear that NetBeans is doing this - but what?  And why?
Accidental keyboard shortcut?  Something else?

Thanks,

Tim

-- 
http://timboudreau.com

Re: Netbeans notifications API

[Tim Boudreau]

If you're talking about notification-daemon, there is a command-line
utility you could just exec, if present (maybe not as elegant, but also not
as invasive or fragile).  As an example, the following is the script I put
in /etc/acpi/actions to make the volume button turn up the volume on my
laptop under Gentoo Linux:

export DISPLAY=:0
VOLUME=`/usr/bin/amixer -c 0 set Master 5%+ | grep Playback | grep "Front
Left:" | cut -b24-`
eval "export $(egrep -z DBUS_SESSION_BUS_ADDRESS /proc/$(pgrep -u tim
openbox)/environ)"
NSOUT=`sudo -u tim /usr/bin/notify-send -t 750 --icon
/usr/share/icons/gnome-human/32x32/status/audio-volume-high.png "Volume
$VOLUME"`

which generates a nice notification with what the volume has been changed
to.  What you need to do is simpler.  The relevant thing to call is
/usr/bin/notify-send - *but *you will need $DISPLAY and
$DBUS_SESSION_ADDRESS set correctly.  But unlike my situation, where the
script runs as another user and I have to fish around for all that stuff,
all you need to do is call /usr/bin/notify-send "Whatever you want to tell
the user"

Much simpler.

-Tim

On Sat, May 16, 2020 at 7:26 AM Hector Espert 
wrote:

> Hi everybody.
>
> After the first proposal to integrate the native linux notification system
> https://github.com/apache/netbeans/pull/1948, I started to work in the
> notifications module to expose an API.
>
>
> My idea is to allow to extend the notifications system and integrate it
> with the native notifications system via a future module or a external
> plugin without break the current behavior.
>
>
> I created a Draft PR with the first draft of the notifications API to
> receive your feedback about that.
> https://github.com/apache/netbeans/pull/2142
>
>
> Regards
>


-- 
http://timboudreau.com

Re: Auto completion support for Database languages.

[Tim Boudreau]

Well, that shows how often I do SQL in anything other than a text console
:-)

-Tim

On Mon, Mar 30, 2020 at 4:04 PM Matthias Bläsing 
wrote:

> Hi,
>
> Am Montag, den 30.03.2020, 21:04 +0600 schrieb Brain Rebooting:
> > Is there any possibility that Netbeans will support autocompletion for
> > database language like IntelliJ Idea in the near future?
>
> there already is. Create a ".sql" file and connect to a DB. You will
> get SQL completion and syntax highlighting.
>
> It is currently tied to a connected DB, but it could be improved. An
> issue is already filed for this:
>
> https://issues.apache.org/jira/browse/NETBEANS-189
>
> Greetings
>
> Matthias
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
> --
http://timboudreau.com

Re: NetBeans javadoc

[Tim Boudreau]

In a maven project, right click the dependency in the project tree and
choose “Download Javadoc”.

-Tim

On Sun, Mar 29, 2020 at 11:27 PM Ernie Rael  wrote:

> Can (and would) someone tell me how to hook up javadoc with code
> completion of IDE modules?
>
> I can't find a download link anywhere, or a way to specify https: target
> in the manage platforms dialog.
>
> -ernie
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
> --
http://timboudreau.com

Re: Auto completion support for Database languages.

[Tim Boudreau]

I could coach someone through writing a plug-in too do that pretty easily,
if someone digs up an Antlr grammar for SQL (the piece-de-resistance would
be handling’s the different dialects - but basic SQL would be trivial to
implement).

-Tim

On Mon, Mar 30, 2020 at 11:04 AM Brain Rebooting 
wrote:

> Dear Apache Netbeans,
>
> Is there any possibility that Netbeans will support autocompletion for
> database language like IntelliJ Idea in the near future?
>
> Also, I'm pretty much satisfied with the normal autocompletion speed and
> quality for java in Netbeans. It feels that autocompletion quality has been
> increased compared to earlier versions.
>
> I'm thinking about if Netbeans somehow attach autocompletion support for
> database languages, then it will be a wow moment for most of the developer
> and also there wouldn't be any reason for any developer to run IntelliJ
> Idea.
>
> Take my greetings.
>
> Samiul Alom Sium
> Associate of Science in computer science student at
> University of the people, California, USA
>
-- 
http://timboudreau.com

Re: Configure line endings for editor

[Tim Boudreau]

Don’t people usually solve this at the level of git these days? I recall
there was some setting for setting Unix line endings on the bits that get
committed.

-Tim

On Thu, Mar 26, 2020 at 3:16 PM Sven Reimers  wrote:

> Hi,
>
> we actually have an issue with development splitted between linux and
> windows based on the native line ending selection for new files.
>
> There once was a plugin
> http://plugins.netbeans.org/plugin/36810/show-and-change-line-endings
>
> from Jan Lahoda, allowing to change the line endings used for editing.
>
> @Jan, do you still have the sources (seems the project was hosted on kenai)
> and would you be willing to donate them? I think this might be a good
> addition for Apache NetBeans
>
> Comments?
>
> -Sven
>
-- 
http://timboudreau.com

Re: Memory usage text rendering issue

[Tim Boudreau]

Oh, sooner or later “flat” will look dated and old, and the gradients will
be back.

If you really wanted to do this right, create a MemoryMeterUI Swing UI
delegate, split the flat and gradient code into two implementation of it,
and have core.swing.plaf toss the name of the default one in UIManager on
startup, and the look and feel can override it if it wants.

(I’m not that serious that that’s a great use of anyone’s time, but it
would be the right way to solve it).

-Tim

On Fri, Feb 28, 2020 at 6:31 AM Emilian Bold  wrote:

> > I  believe the ugliness was caused by rendering the text + dropshadow
> into a buffer created with the 'nominal' pixel dimensions, then
> causing it to scale up a bit by drawing it on to the HiDPI screen
> (e.g. a 125% scale, which resulted in blockiness). As mentioned by
> David Green above it looks OK if the drop shadow effect is turned off.
> In this case text was drawn straight onto the Graphics2D.
>
> Can confirm I disabled dropped shadow on macOS and it was acceptable.
>
> I also never liked the gradient so if by getting rid of it we clean up
> some complex code, even better.
>
> --emi
>
> On Fri, Feb 28, 2020 at 1:04 PM Peter Hull  wrote:
> >
> > On Fri, 28 Feb 2020 at 10:37, Tim Boudreau  wrote:
> > > I happened to be around to chat with the author of that code
> > Thanks for the info; I mentioned above that the code seemed strangely
> > complicated and I could not find any comments or history to explain
> > it.
> > > The reason:  GradientPaint's allocate large rasters (large being
> int[width
> > > * height * 4])  on every repaint.
> > I did not know this. But, the updated widget doesn't use gradient
> > paints any more, just a flat colour filled polyline and some text, so
> > hopefully we won't get that problem.
> >
> > > Most likely the root of the problem is simply
> > > theGraphics.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
> > > RenderingHints.VALUE_ANTIALIASING_ON)
> > I believe the ugliness was caused by rendering the text + dropshadow
> > into a buffer created with the 'nominal' pixel dimensions, then
> > causing it to scale up a bit by drawing it on to the HiDPI screen
> > (e.g. a 125% scale, which resulted in blockiness). As mentioned by
> > David Green above it looks OK if the drop shadow effect is turned off.
> > In this case text was drawn straight onto the Graphics2D.
> >
> > If you wouldn't mind running an eye over the code that would be great!
> >
> > Pete
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.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.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
> --
http://timboudreau.com

Re: Platform has to continue to support Java 8, imho was: Pull the plug from Java 8 in 12.1?

[Tim Boudreau]

If you like broken builds :-)

On Fri, Feb 28, 2020 at 7:02 AM Eric Barboni  wrote:

> As I'm an expert in architecture :D kidding
>
> Can it be possible to have like two repository one for netbeans-platform
> and netbeans with platform "seen as library" ?
> With netbeans-platform jdk8 and the netbeans with jdk 8+ ?
>
> Regards
> Eric
> -Message d'origine-
> De : Neil C Smith 
> Envoyé : vendredi 28 février 2020 11:29
> À : dev 
> Objet : Re: Platform has to continue to support Java 8, imho was: Pull the
> plug from Java 8 in 12.1?
>
> On Fri, 28 Feb 2020 at 09:55, Jaroslav Tulach 
> wrote:
> > PS: The `nb-javac` issue: IGV is actually using Java editing modules,
> > so we are interested in having nb-javac working on JDK8. We bundle the
> > `nb-javac` as part of IGV - e.g. there is no need to download
> > `nb-javac`. Enough to use it when present. I assume we can help with
> > the maintenance of this part of the code base. Dušan Bálek, Tomáš
> > Zezula, Sváťa Dědic and last but not least Jan Lahoda have a lot of
> > expertise in this area and can make sure parsing of Java sources on
> > JDK8 still works (even it will not be used by Apache NetBeans IDE
> itself).
>
> This to me is the crux of the issue.  My comment on the users@ thread was
> more with thought of stopping default/official support of Java editing when
> running on JDK 8.  ie. at least making nb-javac far more optional from 12.1
> than it is now.
>
> It does not seem sustainable to keep telling people with refactoring
> issues to uninstall nb-javac.  Somehow those issues need addressing,
> particularly if they're in code we have no control of here.  I think more
> help on the maintenance of this part, particularly with regard to any
> updates for Java 14 support, might be good in the 12.0 timeframe.
> Java 13 updates for nb-javac during the 11.2 release (which also required
> 11.2u1) were a PITA!  That was my real reason for being in favour of
> shifting the whole schedule back a month - not Eric's Xmas.
> ;-)
> I'm sad :D
>
> Longer term we need to start making nb-javac less (then not) required.
> At least initially making it something legacy to opt in to rather than opt
> out of seems a good move?  From an ASF point of view I think the way
> nb-javac and JavaFX are currently installed may be pushing at the limits of
> compliance.
>
> Best wishes,
>
> Neil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.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.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
> --
http://timboudreau.com

Re: Memory usage text rendering issue

[Tim Boudreau]

>
>
> > and the current code *does* go through a BufferedImage.
> That's what I figured... I'd recommend redoing it without.
>

DO NOT.

I happened to be around to chat with the author of that code - Scott
Violet, at the time one of the lead developers on the Swing team, when he
rewrote that component - this was around the time of the defunct Swing
Application Framework JSR, and being friends with a few guys on the Swing
team, hung out in their offices in Santa Clara a good bit.

The reason:  GradientPaint's allocate large rasters (large being int[width
* height * 4])  on every repaint.  That creates a ton of GC pressure and
memory churn from something that's repainting itself on a timer, for
absolutely no reason.

The solution:  Keep an offscreen BufferedImage with the gradient, which
only ever needs to be painted *once*, and then clear area that was *not* the
graph.  A solution I suggested to Scott, who said (with an unspoken
trailing "you idiot") "Yeah, that's what I just wrote."

Anyway, it's like that for a very legitimate reason.

If there are scaling issues, try using (on the component)
getGraphicsConfiguration().createCompatibleImage(width,
height) (and if you want to be anal about it, keep track of the
GraphicsConfiguration and recreate it if it changes [window was moved to a
different size monitor]) - or if creating it independent of component
creation, 
GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration().createCompatibleImage(width,
height) (but don't expect it to necessarily be right in a multi-monitor
setup).

Most likely the root of the problem is simply

theGraphics.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
RenderingHints.VALUE_ANTIALIASING_ON)

At any rate, it is using an offscreen BufferedImage for a very good reason,
and I'd strongly recommend not ripping that out unless you want to cause a
completely pointless performance issue.

-Tim

Re: Pull the plug from Java 8 in 12.1?

[Tim Boudreau]

FWIW, I still run NetBeans daily on JDK 8, for reasons of stability -
particularly assertion errors and other misbehavior from javac-related
editor code, whenever I've tried to use 10 or later.

And similarly, for libraries, everything I release on Maven central is
still built against JDK 8 (there was a nasty backward incompatible change
in the JDK, with some method on ByteBuffer getting changed to return
ByteBuffer instead of Buffer, which has catastrophic consequences at
runtime if you mix code compiled against JDK 8 and JDK 10 or later, and my
Acteur library uses NIO heavily), so given the amount of the rest of the
world's code that is sitting in Maven Central, compiled on JDK 8, I expect
to be staying with that for a long time to come, for better or worse.

-Tim

Re: Github Actions: Quality: Codacy Reports

[Tim Boudreau]

Anything like that should be set up to use only a minimal subset of
warnings that indicate genuine problems. Most of the ones I see on the
linked page will be absurdly wrong at least some of the time.

For example, the warning not to use fully qualified class names (which is
harmless and in some situations more robust) will get triggered multiple
times on hundreds of classes containing generated code from the form editor.

The insistence on tests containing the tool’s idea of what an assertion is
is just silly - ever write a test of an API that calls you back on a
background thread? If you want to write that clearly, you use assertions
normally, catch them on the background thread and wait on a countdown latch
or similar in the test thread, and rethrow the assertion error - and as
soon as you’ve done that more than once, you’ll wrap that in a nice little
lambda based call so your test code is clear (but it’s very unlikely there
tool will recognize your assertions in that scope.

And so forth.

It’s not bad to have these things, but their authors generally compete on
how big a list of hints they support, so there will be a lot of garbage,
and you don’t want to wind up distorting the way you code to please a tool
rather than using common sense.

-Tim

-- 
http://timboudreau.com

Re: Remove outdated look and feels CDE/Motif and Windows Classic?

[Tim Boudreau]

If I recall correctly, at least at one time, the Windows classic tab
control delegates were used by some other look and feel plug-ins (they were
pretty generic and themeable, so they make a good vanilla tab delegate).
I’d keep those around, even if not directly supported from the UI, so a
plug-in can set their class name in UIManager if desired.

-Tim

On Tue, Jan 7, 2020 at 11:19 AM Karl Tauber  wrote:

> Hello all,
>
> in NetBeans 11.3 we have 4 new look and feels (Dark Metal, Dark Nimbus,
> FlatLaf Dark and FlatLaf Light). On Windows there are now 9 LaFs in the
> LaF combobox in the Options dialog.
>
> Should we reduce the number of supported LaFs a little bit and remove
> the outdated CDE/Motif and "Windows Classic" LaFs?
>
> Isn't Motif dead since nearly 20 years?
> And "Windows Classic" is Windows 95 style (as far as I remember)...
> Can't imagine that anybody is using them...
>
>
> The removal could be done in two steps:
>1. remove them from the LaF combobox, which is easy
>2. remove code related to the removed LaFs,
>   which is maybe more work and could be done later
>
>
> Karl
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
> --
http://timboudreau.com

Re: NB Platform apps only compile against the JDK running the IDE

[Tim Boudreau]

On Fri, Dec 13, 2019 at 11:12 AM Matteo Di Giovinazzo 
wrote:

> Hi thanks Tim,
> the 3-libraries case in my email was just an example: we actually have 52
> declared dependencies that end up resolving in 170 jar files... pretty
> unmanageable by hand...


Figuring out which version is problematic would be the hard part. I’d write
a script to generate all the wrapper modules and pick the newest version of
each, and then start testing and tweaking versions.

I guess having NetBeans application using transitive dependencies between
> NB modules would be a fundamental and disrupting change in the current
> architecture, isn't it?


Couldn’t possibly help. Each module gets its own class loader with multiple
parents. If module A depends on library N’1 and module B depends on library
N’2 passes a reference to a class to a type known to both, an instanceof
test in module A will fail - they are instances of unrelated types that
happen to have the same package and class names as far as the JVM is
concerned.

Your problem is not how dependencies are specified, it is the fact of
needing to depend on multiple versions of the same logical thing.

Now, as I think I said earlier, for things that really can’t mix and don’t
expose library types externally, there isn’t really a problem - they can
have their private dependency on their private copy of the library and
they’re fine (though it would be preferable to find a version to share). If
you were having a problem with jar name collisions (doubtful) in
modules/ext, you could build a fat jar of your module that includes the
class files from the library.

So the only hard cases are where
 - instances of library classes are passed BETWEEN modules depending on
different versions of the library
 - those truly cannot depend on the same version of the library in question

I expect most dependencies will not be a big deal. The main point of work
would be generating the wrapper modules.

-Tim



>
>
>
> On Thu, 12 Dec 2019 at 21:20, Tim Boudreau  wrote:
>
> > Did you try to find a workable combination of versions that would work to
> > simply have one version of each on the classpath of the libraries that
> need
> > them (hint: exclude the original dependency when building the wrapper
> > module and have it depend on the wrapper for the version you want to use
> of
> > that library).
> >
> > On Wed, Dec 11, 2019 at 11:53 PM Matteo Di Giovinazzo <
> matte...@gmail.com>
> > wrote:
> >
> > > Thanks Tim,
> > > but unfortunately the problem we are having with moving to Maven is the
> > one
> > > I described in [1].
> > >
> > > The solution we implemented is to create a Gradle plugin (because
> Gradle
> > > offers higher flexibility and dependencies configuration than Maven)
> that
> > > resolves the dependency tree from a declared list of dependencies in a
> > > build.gradle script.
> > > Then the plugin packages all artifact files in either:
> > >
> > >1. a single NB library wrapper module or
> > >2. a series of NB library wrapper modules whose inter-dependencies
> are
> > >exactly those of the dependency tree resolved by Gradle.
> > >
> > > The solution #2 is not ideal because NetBeans is using non-transitive
> > > dependencies: so in the client modules we would need to depend on all
> > > library wrapper modules of the subtree of the needed library.
> > > Have we used Maven we would end up with redundant libraries described
> in
> > > [1].
> > >
> > > We might share later on the Gradle plugin to help other developers
> facing
> > > the same issue.
> > > -Matteo
> > >
> > > [1]  NetBeans app with Maven with 3rd party libs
> > > <
> > >
> >
> https://lists.apache.org/thread.html/1377d9a39df8ac652d39c0d886ada3ce15bddb051517805363ea141b%40%3Cdev.netbeans.apache.org%3E
> > > >
> > >
> > >
> > > On Wed, 11 Dec 2019 at 19:37, Tim Boudreau 
> wrote:
> > >
> > > > No clue about the bug, but a mitigation would be to migrate your
> > platform
> > > > app to build with maven, which also makes dealing with libraries much
> > > > simpler
> > > > -Tim
> > > >
> > > > On Mon, Dec 9, 2019 at 9:39 PM Matteo Di Giovinazzo <
> > matte...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi there,
> > > > > has anyone any hint about this?
> > > > > https://issues.apache.org/jira/browse/NETBEANS-3278
> > > > >
> > > > > It would be great to have this fixed by 11.3
> > > > > I guess it is because the new JDKs (since 9) are missing
> > > "lib/tools.jar"
> > > > > (that's what it seems from a shallow look at harness/jdk.xml).
> > > > >
> > > > > Thanks!
> > > > > --
> > > > > Matteo Di Giovinazzo
> > > > >
> > > > --
> > > > http://timboudreau.com
> > > >
> > >
> > >
> > > --
> > > Matteo Di Giovinazzo
> > >
> > --
> > http://timboudreau.com
> >
>
>
> --
> Matteo Di Giovinazzo
>
-- 
http://timboudreau.com

Re: NB Platform apps only compile against the JDK running the IDE

[Tim Boudreau]

Did you try to find a workable combination of versions that would work to
simply have one version of each on the classpath of the libraries that need
them (hint: exclude the original dependency when building the wrapper
module and have it depend on the wrapper for the version you want to use of
that library).

On Wed, Dec 11, 2019 at 11:53 PM Matteo Di Giovinazzo 
wrote:

> Thanks Tim,
> but unfortunately the problem we are having with moving to Maven is the one
> I described in [1].
>
> The solution we implemented is to create a Gradle plugin (because Gradle
> offers higher flexibility and dependencies configuration than Maven) that
> resolves the dependency tree from a declared list of dependencies in a
> build.gradle script.
> Then the plugin packages all artifact files in either:
>
>1. a single NB library wrapper module or
>2. a series of NB library wrapper modules whose inter-dependencies are
>exactly those of the dependency tree resolved by Gradle.
>
> The solution #2 is not ideal because NetBeans is using non-transitive
> dependencies: so in the client modules we would need to depend on all
> library wrapper modules of the subtree of the needed library.
> Have we used Maven we would end up with redundant libraries described in
> [1].
>
> We might share later on the Gradle plugin to help other developers facing
> the same issue.
> -Matteo
>
> [1]  NetBeans app with Maven with 3rd party libs
> <
> https://lists.apache.org/thread.html/1377d9a39df8ac652d39c0d886ada3ce15bddb051517805363ea141b%40%3Cdev.netbeans.apache.org%3E
> >
>
>
> On Wed, 11 Dec 2019 at 19:37, Tim Boudreau  wrote:
>
> > No clue about the bug, but a mitigation would be to migrate your platform
> > app to build with maven, which also makes dealing with libraries much
> > simpler
> > -Tim
> >
> > On Mon, Dec 9, 2019 at 9:39 PM Matteo Di Giovinazzo 
> > wrote:
> >
> > > Hi there,
> > > has anyone any hint about this?
> > > https://issues.apache.org/jira/browse/NETBEANS-3278
> > >
> > > It would be great to have this fixed by 11.3
> > > I guess it is because the new JDKs (since 9) are missing
> "lib/tools.jar"
> > > (that's what it seems from a shallow look at harness/jdk.xml).
> > >
> > > Thanks!
> > > --
> > > Matteo Di Giovinazzo
> > >
> > --
> > http://timboudreau.com
> >
>
>
> --
> Matteo Di Giovinazzo
>
-- 
http://timboudreau.com

Re: NB Platform apps only compile against the JDK running the IDE

[Tim Boudreau]

No clue about the bug, but a mitigation would be to migrate your platform
app to build with maven, which also makes dealing with libraries much
simpler
-Tim

On Mon, Dec 9, 2019 at 9:39 PM Matteo Di Giovinazzo 
wrote:

> Hi there,
> has anyone any hint about this?
> https://issues.apache.org/jira/browse/NETBEANS-3278
>
> It would be great to have this fixed by 11.3
> I guess it is because the new JDKs (since 9) are missing "lib/tools.jar"
> (that's what it seems from a shallow look at harness/jdk.xml).
>
> Thanks!
> --
> Matteo Di Giovinazzo
>
-- 
http://timboudreau.com

Re: NetBeans bounty--earn $200!

[Tim Boudreau]

public class Bar {
> public int wazoo;
> }
>
> There is enough Information to know that the standard indentation is 1
> tab, but you don’t have enough information to know what the label
> indentation or continuation indentation should be.


The hard part is dealing with ambiguity. Real sources with a long history
may contain a mix of tabs and spaces, different indent levels etc.

Not to mention more esoteric things - for example, spaces inside
parentheses and how that deals with nested parentheses - e.g. “foo( bar(
baz ))” good and “foo( bar( baz ) )” bad (I have yet to find an incantation
off NetBeans’s own formatter that gets this right.

If you just want to detect tabs or spaces and how many, that might be a
$200 job. For detecting everything and not getting at least one thing
embarrassingly wrong, likely $100k is not enough.

So if someone does this, choose carefully what problems you DON’T want to
solve, or plan on going down an infinitely deep rabbit hole.

-Tim

>


The plugin would need to fall back to the NetBeans prefs to "figure out"
> sensible values for these.
>
> While not rocket science, this isn’t entirely straightforward because you
> can’t just copy the NetBeans prefs. Continuing the example above, if
> NetBeans specifies that the standard indentation is 2 spaces and the
> continuation indentation is also 2 spaces, you can figure out that the
> continuation indentation for this file should be one tab. If in NetBeans
> the continuation indentation was 4 spaces (twice the standard indentation),
> the continuation indentation for this file should be 2 tabs.
>
> -Alvin
>
> --
http://timboudreau.com

Re: phantom "ambiguous method" errors when using Lombok

[Tim Boudreau]

FWIW, I have had similar problems when developing modules referencing code
generated by the annotation processors for Antlr - doesn't happen often for
me, but it does happen.  Deleting the cache from the userdir fixes it
(nothing else does) - it seems like the indexing plumbing gets something
stuck in its craw that stays there forever.

What would be really useful is a command-line tool to view/query data from
the index files - when its working correctly, print the output of searching
on the class in question, and then do so again once it's broken - get the
query right, and the difference in the data will point to the culprit.

P.S. Don't use beans, for anything.  I'd highly recommend finding a
framework that encourages absolutely everything that possibly can be to be
immutable - the final keyword in Java is one of the powerful bug-prevention
tools in the language, because it turns what would be runtime bugs into
compile-time bugs.  One of these days I'm going to write a politically
incorrect blog with a title something like *Java:  Nice language. Too bad
about the cult of mediocrity it comes with*.  The fixation on beans is the
root cause of that cult of mediocrity.

-Tim

On Tue, Dec 10, 2019 at 12:29 PM Alvin Thompson 
wrote:

> Hi,
>
> I’ve been having a problem where in one of my projects, NetBeans is
> constantly highlighting references to methods generated by Lombok as an
> error. However, it’s not a "method not found error" as you’d expect, but
> rather the opposite—it claims that the method is ambiguous because there
> are two methods that match. The odd thing is that the methods mentioned are
> both the same—it’s just the method generated by Lombok—and the code
> compiles fine without warnings. See the picture at the bottom for an
> example.
>
> There’s nothing special about the code that uses Lombok; they’re just
> simple beans that use Lombok annotations to generate things like getters,
> setters, equals, hashcode, etc. Strangely, the issue doesn’t show up for
> *all* Lombok-annotated beans—just some of them. It seems random which
> beans are affected; with two seemingly semantically identical beans in the
> same package, one may be affected while the other may not.
>
> This makes working with this project in NetBeans unpleasant to say the
> least, because this project relies heavily on Lombok and many of the java
> files are filled with dozens of spurious error highlights. This issue has
> actually been happening since NetBeans 9. I believe I filed an issue for
> this in the old issue tracker, but I don’t see it here so I guess it didn’t
> get migrated. However, someone also created an issue for this in the new
> tracker (NETBEANS-1842), and it has several votes, so I guess others also
> have this issue.
>
> For more than a year, I’ve tried many things to isolate this issue without
> success. Any help with this issue would be appreciated. Below is
> information I’ve gleaned which may be useful to identify the problem, in no
> particular order:
>
>- This issue started with NetBeans 9. NetBeans 8 worked fine.
>- This is a Maven project, which uses generated code from both Lombok
>and Mapstruct.
>   - I have not proven that Mapstruct has anything to do with the
>   issue. I just mention it here as a potentially relevant piece of
>   information.
>   - I’ve tried using all Lombok versions since the issue started,
>   several Mapstruct versions, and various combinations.
>- This issue affects all generated methods (setters, getters,
>toString, etc).
>- The project uses a custom source path instead of src/main/java.
>Again, I’m not sure this is relevant.
>- The project platform is JDK 8, while NetBeans runs on JDK 13.
>   - I’ve tried running NetBeans with JDK 10,11, and 12 as well.
>- I’ve tried a clean install of NetBeans without importing preferences.
>- I’ve tried NetBeans on several different computers (all my computers
>are macOS, but the  reporter of the issue reported it against Windows).
>- I’ve tried many NetBeans-javac versions.
>- I’ve tried a clean install without installing nb-javac at all.
>- Editing and saving the Lombok-annotated bean will make the error
>highlights in the files that reference the bean go away temporarily, but
>they will eventually come back.
>   - This is not scalable because project has hundreds of beans, and
>   as I progress down the list of beans the error will eventually pop back 
> up
>   in the beans I already edited.
>- Stopping NetBeans, removing its cache, and restarting temporarily
>fixes the problem, but it eventually comes back.
>   - I haven’t figured out what sequence of events causes the error to
>   show up again, but it’s common enough that the problem resurfaces within
>   the day (often within minutes).
>   - Since it takes a long time to scan this project, and since it
>   takes a long time to rebuild other stuff in 

Re: Build failing locally

[Tim Boudreau]

FYI, I find myself needing to switch between JDKs enough that I set up some
tooling to make that a single shell alias to do that cleanly (actually
removing and replacing things from $PATH, rather then endlessly prepending
more JAVA_HOME/bin dirs to it).  That might make things simpler for anyone
who wants to build NetBeans with JDK 8 but do other things with something
else.

Here's the script (requires nodejs - my preferred command-line scripting
tool these days):
https://timboudreau.com/files/fixpath.txt

You'll want to rename it without the '.txt' extension, put it in ~/bin or
someplace like that, and follow the instructions in the comment at the top
to set up
shell variables and aliases for the various JDKs you use.  It's pretty
straightforward.

-Tim

On Tue, Dec 3, 2019 at 7:44 AM Steven Ingram 
wrote:

> I made my local repo pristine, set my system JDK to 11, and built the
> project with no issues. My original issue with “applemenu” has also
> vanished. I’ve made no other concessions for the project with local
> configuration, it just works out of the box now, which is fantastic.
>
> I did have to set my build command to allow jdk 9, but I’m taking the
> README as the truth.
>
> "Requirements
> Git
> Ant 1.9.9 or above
> JDK 8 or 11 (to build NetBeans)
> JDK 9 or above (to run NetBeans)"
>
> My problems started when I used a system set JDK 8 to build and run NB.
>
> Thanks everyone!
>
> Steven
>
> On Tue, Dec 3, 2019 at 05:21 Neil C Smith  wrote:
>
> > On Tue, 3 Dec 2019 at 09:56, Peter Hull  wrote:
> > > This means checking the PATH and JAVA_HOME and JDK_HOME and
> > > .nbbuild.properties and  nbbuild\user.build.properties for consistency.
> >
> > Possibly ANT_HOME missing there?  I know there was a line about
> > setting JAVA_HOME and ANT_HOME integrated into the readme during the
> > 11.2 release window.  Is this by itself still not enough?
> >
> > See https://github.com/apache/netbeans/pull/1554 and
> >
> >
> https://mail-archives.apache.org/mod_mbox/netbeans-dev/201910.mbox/%3C26c1f141-b021-4473-059f-41ec0b5e3613%40status6.com%3E
> >
> > Best wishes,
> >
> > Neil
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>


-- 
http://timboudreau.com

Re: Want to know info about nbpython

[Tim Boudreau]

There is also a mavenized version of all of it here (I'm hoping we can find
a process to have this become the "donation" whenever it gets approved -
the git history shows it is the same code):
https://github.com/timboudreau/netbeans-contrib

-Tim

On Fri, Nov 22, 2019 at 9:03 AM Geertjan Wielenga 
wrote:

> The source code of that is here: https://hg.netbeans.org/main/contrib/file
>
> That whole contrib repo needs to be donated to Apache still.
>
> The question is also whether we want all of it or some of it and who owns
> which module in the above.
>
> One of a handful of areas that we still need to resolve as part of the
> donation process.
>
> Gj
>
>
>
> On Fri, Nov 22, 2019 at 8:03 AM Samiul Alom Sium  >
> wrote:
>
> > What is the current condition of nbpython in 2019?
> > What's your plan how it should be in upcoming netbeans-12?
> > Don't you include more features like django, Machine learning with python
> > and AI related task in nbpython plugin for netbeans platform?
> >
>


-- 
http://timboudreau.com

Re: Using git push --force

[Tim Boudreau]

On Wed, Nov 20, 2019 at 2:36 PM Benjamin Asbach  wrote:

> So why
> having these information in project history when it does not deliver any
> additional value?
>

Because the point of developing software is to develop software, not please
hypothetical future historians.

-Tim

Re: Using git push --force

[Tim Boudreau]

I really don't see the point of squashing commits.  I know, everybody would
like to look like they write perfect, concise, error-free code the first
time.  But nobody does - and that seems to be the primary purpose.  If you
want to see the set of changes that implement a feature, it's not that hard
to come up with an incantation of git diff -r that will let you do that -
and that kind of forensics as far less common - not something you should
contort your development process and spend work on to optimize.  So it
seems to me, the main point of making commit history pretty is ego.  Which
is a silly thing to get excited about.

-Tim

Re: Clarify how to use locally built platform with maven

[Tim Boudreau]

Regardless, all you have to do is set it in the parent pom (ideally with a
good  section with everything you're going to use),
and then if the IDE adds  to anything, delete it (really, I think
the dependency adding feature should detect if the library is already
referenced from the parent's  section - but Maven can
get really weird about dependencies [add a library with a
provided library you already depend on, and it can make the
library disappear from your runtime classpath), so I can imagine that might
break things once in a while).

-Tim

On Mon, Nov 18, 2019 at 8:54 PM Dmitry Avtonomov <
dmitriy.avtono...@gmail.com> wrote:

> Thanks for the suggestion John, I tried both buttons - nothing worked for
> me. I also tried building the complete NBP:
>
> *ant -Dcluster.config=full build-nozip build-nbms build-source-zips
> build-javadoc*
>
> Tried building just the platform:
>
> *ant -Dcluster.config=platform build-nozip build-nbms build-source-zips
> build-javadoc*
>
> None worked.
> And I do see the built artifacts in ~/.m2/repository. They are right there
> next to RELEASE110, RELEASE111 etc downloaded by maven when I tried
> building a test app after first installing netbeans.
>
> The only difference between the downloaded artifacts (like RELEASE112)
> compared to my built ones is that the downloaded ones' pom files had the
> ** entry:
>
> *org.apache.netbeans *groupId>netbeans-parent
> *artifactId>2*
>
> That parent pom doesn't seem to add anything build-related, it's mostly
> license notices etc. But in the end I added parentGAV configuration entry
> to nb-repository-plugin like this:
>
>
>
>
>
>
> *  org.apache.netbeans.utilities
> nb-repository-plugin  1.4
> 
> org.apache.netbeans:netbeans-parent:2  *
>
> Now the NetBeans wizard (New Project -> Java with Maven -> NetBeans
> Application) still does not see my artifacts. But if I still create an app
> with one of the RELEASExxx versions it does see and change RELEASExxx in
> the parent project pom to my version, it seems to work. At least I don't
> get build errors as before. I frankly don't know what might have changed
> except for me adding the praentGAV, but it does seem to work. In the
> pom.xml of *...-parent* project created by the wizard set netbeans.version
> to RELEASE1236 (which is locally built):
>
>
>
> *RELEASE1236
>   mavenproject4*
>
> This is a new computer with a fresh install of everything, including the
> OS, so hard to tell.
> I also didn't have any luck building+running with Java 11 (tried zulu and
> adoptopenjdk) so switched everything back to 8.
>
>
>
>
> On Sun, Nov 17, 2019 at 10:43 AM John Neffenger  wrote:
>
> > On 11/17/19 2:06 AM, Dmitry Avtonomov wrote:
> > > I did do that - there's a button to re-index maven repos afair.
> >
> > If that's the button in the Options under Java > Maven, I think that
> > just pulls down the latest list from Maven Central again.
> >
> > Instead, open the Services Window (Ctrl-5), expand Maven Repositories,
> > right-click the entry for Local, and select Update Index to re-index the
> > local repository and save it in the NetBeans cache.
> >
> > That's how I got NetBeans to recognize the artifacts that I had copied
> > into the local Maven cache when working around NETBEANS-1396.
> >
> > John
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>


-- 
http://timboudreau.com

Re: Cloud Based NetBeans

[Tim Boudreau]

I suspect for that to ever have legs, it would require the redefinition of
what programming *is* to be amenable to one-finger, drag-and-drop
operations on a tablet.  And, well, people have been trying to do that
since there have been programming languages.  The complexity you need to
express to do anything real just isn't expressible that way - same as UML
becomes useless as soon as you touch anything non-trivial, or worse,
concurrency.  I don't see that changing any time soon.

Every big company that does languages / tooling, at some point, has
executives who aren't programmers, and think "Hey, programming should be
done the new cool way on phones and tablets - and then we could hold
people's software for ransom, make them dependent on our tooling and have
to deploy on our cloud!  Think of the $$!"  And they throw a bunch of money
at it and build something that sort of works and nobody wants or likes.
Rinse and repeat.

The big problem goes back to IBM's 1990s attempts with Visual Age, where
your code isn't files on disk, it's in this magical database.  That sounds
great until the first time you want to use an external tool against it,
only it's all kept in a locked vault by your IDE.

Maybe it will work someday, but not with any of the current programming
languages - it would need something designed from scratch for that
purpose.  And good luck making that not a tinker-toy.

-Tim


On Mon, Nov 18, 2019 at 12:32 PM Kenneth Fogel 
wrote:

> When I attended Microsoft Ignite, I was a guest of Microsoft, we were told
> of a new version of Visual Studio that will be hosted in the cloud. You can
> see it at https://online.visualstudio.com
> . You need a Microsoft account and
> a free Azure account. You can see the details for yourself and the purpose
> of this email is not to promote this offering.
>
>
>
> What this email is about is to discuss whether or not a cloud based
> NetBeans is possible. With more and more users, therefore potential new
> developers, using tablets and Chromebooks, less and less people will have
> traditional PCs. Other languages such as Python have browser based IDEs.
> Should we be investigating this?
>
>
>
>
>
> [image: cid:image011.jpg@01D58921.806E3550]
>
> *Ken Fogel*
> Faculty / Java Champion
>
> email: kfo...@dawsoncollege.qc.ca
> phone: (514) 931-8731 local 4799
>
> Dawson College, 3040 Sherbrooke St. W Westmount, Quebec, H3Z 1A4, Canada
>
> [image: facebook icon]  [image:
> twitter icon]  [image: youtube icon]
>  [image: linkedin icon]
>  [image: instagram icon]
> 
>
> [image: cid:16cd4bdce7eaf8d708] 
>
>
>
>
>


-- 
http://timboudreau.com

Re: Splitting the netbeans_default_options in netbeans.conf

[Tim Boudreau]

Just split the line with \n instead of spaces and alpha sort at build time.

FYI, my (ignores) font settings patch includes a parser/rewriter for
NetBeans.conf that does exactly that.

-Tim

On Sun, Nov 17, 2019 at 1:40 PM Emilian Bold  wrote:

> Hello,
>
> I see the build system uses now the rather neat @@metabuild.*@@
> pre-processor directives (or whatever they are called).
>
> Even in netbeans/nb/ide.launcher/netbeans.conf I see we use
> @@metabuild.logcli@@
>
> I wonder if there's any plan / way to split the annoyingly long
> netbeans_default_options into individual chunks? Maybe generate
> netbeans_default_options at build time?
>
> It seem impossible to notice what changed in netbeans_default_options
> based on a diff since it's such a long line. Luckily things get
> prepended, so it's not that hard in practice, but still...
>
> Just my 2c,
>
> --emi
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
> --
http://timboudreau.com

Re: Clarify how to use locally built platform with maven

[Tim Boudreau]

I think it won’t show up until NetBeans’s reindexes your local repository.
They eventually did for me. There may be a way to force it to in the
options dialog (or delete the cache dir so it has to).

-Tim

On Sun, Nov 17, 2019 at 1:12 AM Dmitry Avtonomov <
dmitriy.avtono...@gmail.com> wrote:

> But we've been through that already, I did use the repo you're pointing to,
> I changed the version to  RELEASE1234, it did build fine and I see all the
> stuff in my local m2 repo.
> Then I go to Netbeans IDE, create new maven nbp project, but the wizard
> only shows me the RELEASExxx that are found on Central. I tried creating an
> app with one of those versions available on Central (e.g. RELEASE111) and
> then changing all occurrences of RELEASE111 to RELEASE1234, but that didn't
> work. It doesn't want to check the local m2 repo at all.
>
> On Sat, Nov 16, 2019 at 8:29 PM Tim Boudreau  wrote:
>
> > Use this.  It will build NBMs of all NetBeans modules from a source
> > checkout and populate your local repo with them.  Just set the version
> > number to something unique and use that in your dependencies (hopefully
> as
> > a property set in one place).  See the readme for details:
> >
> > https://github.com/timboudreau/netbeans-local-maven-repo-populator
> >
> > -Tim
> >
> > On Sat, Nov 16, 2019 at 7:35 PM Dmitry Avtonomov <
> > dmitriy.avtono...@gmail.com> wrote:
> >
> > > I want to not be dependent on the platform nbms published to Central or
> > any
> > > other online repository. I want to be able to clone NB sources from
> > Github,
> > > disconnect from the internet, and create a maven-based platform app
> with
> > > just that. If the platform I build the app against ever becomes
> > unavailable
> > > online, I want to still be able to build the app.
> > >
> > > Like exactly the same as what Geertjan is showing in the first video
> from
> > > [1]: https://youtu.be/VC8gQJknPaU. He builds netbeans from sources,
> > > registers the built platform using the UI for that in Netbeans IDE
> (Tools
> > > -> Netbeans Platforms) and creates a NBP app that uses that platform. I
> > > wanted to do the same, but the maven way.
> > >
> > > [1]
> > https://netbeans.apache.org/participate/build-run-debug-tutorials.html
> > >
> > >
> > >
> > > On Fri, Nov 15, 2019 at 1:06 PM Tim Boudreau 
> > wrote:
> > >
> > > > If you mean, have a multi-module parent pom, and some way to run a
> > module
> > > > and have all its dependencies be found and included... as far as I
> > know,
> > > > there is simply no good way to do that with the nbm-maven-plugin - it
> > is
> > > a
> > > > glaring feature gap.
> > > >
> > > > The (painful) workaround is to create an nbm-application project,
> that
> > > > depends on everything you need, and build and run that (which means
> > > > rebuilding the entire application structure every time you want to
> run,
> > > > which can take several minutes).  Here's an example of that (see the
> > pom
> > > > and the shell scripts in this dir):
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/timboudreau/ANTLR4-Plugins-for-NetBeans/tree/master/antlr-suite
> > > >
> > > > I've thought about writing a patch for the nbm plugin to do the right
> > > thing
> > > > - build the application structure in the project's target/ dir, find
> > all
> > > > dependencies that can be resolved as projects in the reactor and only
> > > > update those that have changed - but I've only got about 2000 other
> > > things
> > > > I need to get done in front of that :-/
> > > >
> > > > -Tim
> > > >
> > >
> >
> >
> > --
> > http://timboudreau.com
> >
>
-- 
http://timboudreau.com

Re: Clarify how to use locally built platform with maven

[Tim Boudreau]

Use this.  It will build NBMs of all NetBeans modules from a source
checkout and populate your local repo with them.  Just set the version
number to something unique and use that in your dependencies (hopefully as
a property set in one place).  See the readme for details:

https://github.com/timboudreau/netbeans-local-maven-repo-populator

-Tim

On Sat, Nov 16, 2019 at 7:35 PM Dmitry Avtonomov <
dmitriy.avtono...@gmail.com> wrote:

> I want to not be dependent on the platform nbms published to Central or any
> other online repository. I want to be able to clone NB sources from Github,
> disconnect from the internet, and create a maven-based platform app with
> just that. If the platform I build the app against ever becomes unavailable
> online, I want to still be able to build the app.
>
> Like exactly the same as what Geertjan is showing in the first video from
> [1]: https://youtu.be/VC8gQJknPaU. He builds netbeans from sources,
> registers the built platform using the UI for that in Netbeans IDE (Tools
> -> Netbeans Platforms) and creates a NBP app that uses that platform. I
> wanted to do the same, but the maven way.
>
> [1] https://netbeans.apache.org/participate/build-run-debug-tutorials.html
>
>
>
> On Fri, Nov 15, 2019 at 1:06 PM Tim Boudreau  wrote:
>
> > If you mean, have a multi-module parent pom, and some way to run a module
> > and have all its dependencies be found and included... as far as I know,
> > there is simply no good way to do that with the nbm-maven-plugin - it is
> a
> > glaring feature gap.
> >
> > The (painful) workaround is to create an nbm-application project, that
> > depends on everything you need, and build and run that (which means
> > rebuilding the entire application structure every time you want to run,
> > which can take several minutes).  Here's an example of that (see the pom
> > and the shell scripts in this dir):
> >
> >
> >
> https://github.com/timboudreau/ANTLR4-Plugins-for-NetBeans/tree/master/antlr-suite
> >
> > I've thought about writing a patch for the nbm plugin to do the right
> thing
> > - build the application structure in the project's target/ dir, find all
> > dependencies that can be resolved as projects in the reactor and only
> > update those that have changed - but I've only got about 2000 other
> things
> > I need to get done in front of that :-/
> >
> > -Tim
> >
>


-- 
http://timboudreau.com

Re: NetBeans app with Maven with 3rd party libs

[Tim Boudreau]

The answer depends on whether the gitlab4j, batik and awsamazon libraries
will pass around objects created by commons-logging such that they will
collide (and not have the same Class objects).

If not, just wrap each one in its own wrapper module along with the version
of commons-logging they want, and each one should load its own copy of
commons-logging, and life is good (just be very sure YOUR code doesn't try
to call into commons-logging, or bad things will happen).

If that doesn't work, try to find the newest version of commons-logging
that is compatible with all of them, and:  Create your one or multiple
wrapper modules, but in each one's pom.xml, *exclude* the dependency on
commons-logging, and add an explicit dependency from your wrapper module to
the version of commons-logging that all of them can share.

If there is no version of commons-logging that works with all of those
libraries, see if you can isolate individual libraries so they use the
version they want as described above, until you have something that works.

It ain't pretty.

-Tim

On Thu, Oct 31, 2019 at 11:46 AM Matteo Di Giovinazzo 
wrote:

> Any thoughts about this question of mine?
>
> I read lately some old thread about converting the contrib plugins to
> Maven:
>
> https://lists.apache.org/thread.html/38228ec0bd9f47b014d9b7cff72665285c6227d39726373be6c7b82b@%3Cdev.netbeans.apache.org%3E
>
>
> Any hint you can give us, Tim Boudreau?
>
> Thanks in advance!
> -Matteo
>
> On Fri, 25 Oct 2019 at 11:56, Matteo Di Giovinazzo 
> wrote:
>
> > Thanks, yes but what about the case we have in our RCP app: we use
> > gitlab4j, batik and awsamazon libraries and they share dependencies on
> > commons-logging with 3 different versions and other shared dependencies?
> > Is creating different NBM modules by hand trying to group as much jars as
> > possible and at the same time minimize the redundancy of including the
> same
> > jars multiple times the only solution at the moment?
> >
> > On Fri, 25 Oct 2019 at 09:19, Eric Barboni  wrote:
> >
> >> Hi,
> >>
> >> You may group more than on artifacts in one wrapper.  And you don't have
> >> to do  wrapper for every artefacts
> >> If you wrap batik, it's about 10 maven artefacts, but you may have just
> >> one wrapper for all of them.
> >> It depends usage
> >>
> >> Regards
> >> Eric
> >>
> >> -Message d'origine-
> >> De : Matteo Di Giovinazzo 
> >> Envoyé : vendredi 25 octobre 2019 16:22
> >> À : dev@netbeans.apache.org
> >> Objet : Re: NetBeans app with Maven with 3rd party libs
> >>
> >> Thanks Timon for the suggestion!
> >> I am used to follow that way using the Ant-based NetBeans
> >> module/suite/application projects, but I was hoping with Maven that
> could
> >> be avoided given that Maven takes care of dependencies itself. I guess
> the
> >> problem is that Maven dependencies are transitive whereas NetBeans ones
> are
> >> not. I was in fact reading this
> >> https://bits.netbeans.org/mavenutilities/nbm-maven-plugin/  hoping
> >> something clever was going to happen.
> >>
> >> Our current problem is that we have 50+ libraries to ship with our RCP
> >> application and some of them have very log chain of dependencies and
> >> handling all the dependency graph by hand is a nightmare...
> >>
> >> Any other suggestions?
> >> Thanks!
> >>
> >>
> >>
> >>
> >> On Fri, 25 Oct 2019 at 02:31, Timon Veenstra  wrote:
> >>
> >> > Hi Matteo,
> >> >
> >> > The way to share dependencies between netbeans platform modules is to
> >> > create library wrapper modules.
> >> > - Create a new netbeans platform module
> >> > - add the dependency
> >> > - declare public packages
> >> >
> >> > A little more elaborate description can be found here:
> >> >
> >> >
> https://ljelonek.wordpress.com/2011/04/19/netbeans-maven-library-wrapp
> >> > er-modules/
> >> >
> >> > Cheers,
> >> > Timon
> >> >
> >> > On Thu, Oct 24, 2019 at 7:29 PM Matteo Di Giovinazzo
> >> > 
> >> > wrote:
> >> >
> >> > > I'm trying to mavenize our NB RCP app, but I do not understand how
> >> > > to add 3rd party libraries.
> >> > > I have an app (nbappmaven) with two modules (module1 and module2)
> >> > > and
> >> > both
> >> > > need the same library, say gitlab4j (wit

Re: Clarify how to use locally built platform with maven

[Tim Boudreau]

If you mean, have a multi-module parent pom, and some way to run a module
and have all its dependencies be found and included... as far as I know,
there is simply no good way to do that with the nbm-maven-plugin - it is a
glaring feature gap.

The (painful) workaround is to create an nbm-application project, that
depends on everything you need, and build and run that (which means
rebuilding the entire application structure every time you want to run,
which can take several minutes).  Here's an example of that (see the pom
and the shell scripts in this dir):

https://github.com/timboudreau/ANTLR4-Plugins-for-NetBeans/tree/master/antlr-suite

I've thought about writing a patch for the nbm plugin to do the right thing
- build the application structure in the project's target/ dir, find all
dependencies that can be resolved as projects in the reactor and only
update those that have changed - but I've only got about 2000 other things
I need to get done in front of that :-/

-Tim

Re: NetBeans Design

[Tim Boudreau]

Indeed.  I've found it handy to create a shell alias for searching java
sources - dirt simple, but handy in your .bashrc:

alias jfind='find . -name "*.java" | xargs grep -i '

will find any java source containing whatever string you pass to it.

-Tim

Re: NetBeans Design

[Tim Boudreau]

That is most impressive, and yet terrifying at the same time. It raises
> even more questions for me. How does anyone know where anything is?


You learn. Learn the basics of how things In NetBeans are put together -
Lookup, the system filesystem, MimeLookup, what DataObjects are - and you
can look at unfamiliar parts of the system do and think “I bet there’s a
things that provides X and it’s probably found here.” And look and see if
it is. Learn the difference between API and SPI and expect them to be
separate things.

After that, you just pick the functionality you want to implement, look up
what APIs might be helpful for that (google, the Javadoc, and grepping the
sources are your friends), and start coding. In this way, you incrementally
learn your way around - it’s not necessary to know everything to be
productive.

Probably not for discussion here but, what use is software engineering,
> design methodologies etc., is software development just an enormous
> hackathon?


Most “methodologies” are frauds designed to inflate consultants’ billable
hours, or guarantee a product broken enough that they have a long term
revenue strram. Usually both.

Don’t mistake size for lack of discipline. There are modules I wrote
fifteen or more years ago and use daily, unmodified.

Welcome to the wonderful world of non-trivial software :-)

-Tim


>
> Food for thought.
>
> Many thanks to everyone who replied to my original post.
>
> Jeremy
>
>
> On 07/11/2019 03:29, Tim Boudreau wrote:
> > A few people asked for a visual representation. I pulled this together a
> > few years ago. Mostly it just illustrates why those kinds of
> > representations are useless at scale.
> >
> > Package dependencies:
> >
> > https://timboudreau.com/files/nb-packagegraph/
> >
> > Classes (IIRC trimmed down a LOT):
> >
> > https://timboudreau.com/files/netbeans-classes/
> >
> > On Wed, Nov 6, 2019 at 7:57 PM Eric Bresie  wrote:
> >
> >> Is this a reason to push for the UML plugin ;-)
> >
> >
> > There are no reasons to push for uml, ever :-)
> >
> > -Tim
> >
> >
> >
> >>
> >> Eric Bresie
> >> ebre...@gmail.com
> >>> On November 6, 2019 at 9:02:49 AM CST, Eric Barboni 
> >> wrote:
> >>> Hi,
> >>> Not sure that is what you want.
> >>>
> >>> ((A small help can be
> >>> If you get the sources, do a first build:
> >>> ant
> >>> you can then do
> >>> ant index-layer-paths
> >>>
> >>> this will create in nbbuild/build/generated layers.txt and services.txt
> >>> where given a " UI element" " mimetype" "project type" you can find
> >> which module provide it (this is a bit too textual).
> >>> ))
> >>>
> >>> Maybe you want a more complex visualization, with rectangle and edge
> but
> >> I guess should be some layout and "dynamic page" to filter ( or 8K
> monitors
> >> :p). Modules are legion.
> >>>
> >>> Best Regards
> >>> Eric
> >>> -Message d'origine-
> >>> De : Christian Lenz 
> >>> Envoyé : mercredi 6 novembre 2019 15:43
> >>> À : dev@netbeans.apache.org
> >>> Objet : AW: NetBeans Design
> >>>
> >>> ➢ And this IMHO continues to be the best book on the NetBeans Platform:
> >>>
> >>> ➢ https://leanpub.com/nbp4beginners
> >>>
> >>> ➢ Gj
> >>>
> >>> Hey Geertjan,
> >>>
> >>> how does that fit in the reworked/categorized structure. Is the book
> >> still up to date? Just asking.
> >>>
> >>>
> >>> Cheers
> >>>
> >>> Chris
> >>>
> >>>
> >>> Von: Geertjan Wielenga
> >>> Gesendet: Mittwoch, 6. November 2019 15:34
> >>> An: dev
> >>> Betreff: Re: NetBeans Design
> >>>
> >>> On Wed, Nov 6, 2019 at 3:09 PM Christoph Theis  wrote:
> >>>
> >>>> I have the same problem:
> >>>> E.g., NB doesn't accept a current javahl. So, where would I find the
> >>>> module where the check happened (I grep'ed for the error message and
> >>>> found it). Are there dependencies? If I want to improve the error
> >>>> message (right now it is hidden in the log files), how to do it?
> >>>>
> >>>> So, summarizing, an eagles view of what NB is composed of, would be a
> >>>> start. Sthg., that would help newcom

Re: Help [WANTED] by skilled JavaScript gurus

[Tim Boudreau]

You should be using websockets.

The link was too small to read on a phone, so: if Some basic building block
requires the connection to be synchronous, get some new blocks - you're
using the wrong ones.

Having spent years developing a server framework in which NOTHING is
synchronous, I'm pretty sure there are other choices.

If you mean you don't want a single queue of messages, open a bunch of
connections and round-robin them (and have fun sorting them on the other
end).

-Tim

On Sun, Nov 10, 2019 at 11:53 AM Jaroslav Tulach 
wrote:

> Open letter to Christian Lenz and other skilled HTML and JavaScript guys
> willing to help HTML/Java API to be better.
>
> The donation of new presenters by DukeHoff has been integrated into
> HTML/Java API version 1.7 - [the javadoc](
> https://bits.netbeans.org/html+java/1.7/) has been kindly generated by
> Eric.
>
> One of the new presenters is [browser presenter](
>
> https://bits.netbeans.org/html+java/1.7/org/netbeans/html/presenters/browser/package-summary.html
> ).
> I have found it quite flexible - it starts an HTTP server on a local port
> and let's a browser connect to it. Then it handles all the message passing
> to make sure Java is executed on the server and JavaScript in the browser.
> It has great potential, but...
>
> The code is a bit unreliable. Take a look at
>
> https://github.com/apache/netbeans-html4j/blob/master/browser/src/main/java/org/netbeans/html/presenters/browser/Browser.java#L418
> that one seems to open a long polling XHR connection waiting for commands
> from the Java side to be executed in the JavaScript VM. Whenever the
> JavaScript wants to call into Java, it uses another XHR:
>
> https://github.com/apache/netbeans-html4j/blob/master/browser/src/main/java/org/netbeans/html/presenters/browser/Browser.java#L636
> - it seems to work most of the time, but not always (for example I have not
> got it working on Windows8 IE, only Firefox).
>
> Work to change the browser<->server connection to be more reliable
> welcomed! Help with identifying/fixing what is wrong welcomed too. Thanks
> in advance for your help, I am not that good in server/browser
> technologies. I don't even know how to properly debug what is happening in
> there - maybe the server accepts too many parallel connections? Maybe each
> client should only have one and share it? How? Etc...
> -jt
>
> PS: I was thinking of using WebSocket, but alas, the [basic building
> block](
>
> https://bits.netbeans.org/html+java/dev/net/java/html/js/package-summary.html
> )
> requires the connection from JavaScript to Java to be synchronous and I
> have no idea how to simulate that...
>
> PPS: ... synchronous XHR is indeed bad, but this one is local call - e.g.
> fast and it works fine on all other supported platforms. Moreover there is
> too much code using `@JavaScriptBody(javacall=true)` which relies on its
> synchronicity. E.g. this direction of thoughts isn't really useful.
>
-- 
http://timboudreau.com

Re: RE: NetBeans Design

[Tim Boudreau]

A few people asked for a visual representation. I pulled this together a
few years ago. Mostly it just illustrates why those kinds of
representations are useless at scale.

Package dependencies:

https://timboudreau.com/files/nb-packagegraph/

Classes (IIRC trimmed down a LOT):

https://timboudreau.com/files/netbeans-classes/

On Wed, Nov 6, 2019 at 7:57 PM Eric Bresie  wrote:

> Is this a reason to push for the UML plugin ;-)


There are no reasons to push for uml, ever :-)

-Tim



>
> Eric Bresie
> ebre...@gmail.com
> > On November 6, 2019 at 9:02:49 AM CST, Eric Barboni 
> wrote:
> > Hi,
> > Not sure that is what you want.
> >
> > ((A small help can be
> > If you get the sources, do a first build:
> > ant
> > you can then do
> > ant index-layer-paths
> >
> > this will create in nbbuild/build/generated layers.txt and services.txt
> > where given a " UI element" " mimetype" "project type" you can find
> which module provide it (this is a bit too textual).
> > ))
> >
> > Maybe you want a more complex visualization, with rectangle and edge but
> I guess should be some layout and "dynamic page" to filter ( or 8K monitors
> :p). Modules are legion.
> >
> > Best Regards
> > Eric
> > -Message d'origine-
> > De : Christian Lenz 
> > Envoyé : mercredi 6 novembre 2019 15:43
> > À : dev@netbeans.apache.org
> > Objet : AW: NetBeans Design
> >
> > ➢ And this IMHO continues to be the best book on the NetBeans Platform:
> >
> > ➢ https://leanpub.com/nbp4beginners
> >
> > ➢ Gj
> >
> > Hey Geertjan,
> >
> > how does that fit in the reworked/categorized structure. Is the book
> still up to date? Just asking.
> >
> >
> > Cheers
> >
> > Chris
> >
> >
> > Von: Geertjan Wielenga
> > Gesendet: Mittwoch, 6. November 2019 15:34
> > An: dev
> > Betreff: Re: NetBeans Design
> >
> > On Wed, Nov 6, 2019 at 3:09 PM Christoph Theis  wrote:
> >
> > > I have the same problem:
> > > E.g., NB doesn't accept a current javahl. So, where would I find the
> > > module where the check happened (I grep'ed for the error message and
> > > found it). Are there dependencies? If I want to improve the error
> > > message (right now it is hidden in the log files), how to do it?
> > >
> > > So, summarizing, an eagles view of what NB is composed of, would be a
> > > start. Sthg., that would help newcomers to understand the code of NB.
> > >
> >
> >
> > In many ways, the current GitHub structure provides the eagle's view you
> > seek:
> >
> > https://github.com/apache/netbeans
> >
> > Rather than it being a long list of modules, the above categorizes them
> into their clusters, reflecting what you see in your NetBeans installation
> directory.
> >
> > Indeed, grepping is a good approach to find the code you need to work
> with.
> >
> > You can also search directly in the GitHub repo on-line in the web
> interface.
> >
> > The dependencies of any modules are always listed in the project.xml
> file of a module.
> >
> > And this IMHO continues to be the best book on the NetBeans Platform:
> >
> > https://leanpub.com/nbp4beginners
> >
> > Gj
> >
> >
> >
> >
> >
> > >
> > > @Jeremy: I hope I got your point.
> > >
> > >
> > > Best regards
> > >
> > > Christoph
> > >
> > > On 06.11.2019 14:24, Geertjan Wielenga wrote:
> > > > What specific things are you looking for?
> > > >
> > > > Gj
> > > >
> > > > On Wed, 6 Nov 2019 at 14:05, Jeremy Cavanagh
> > > > 
> > > > wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > I was just wondering if there was a design document for NetBeans
> > > > > which shows how all the pieces fit together? I ask this because
> > > > > whenever I look at incubator-netbeans I have no idea of what I'm
> > > > > looking at, or where to find things.
> > > > >
> > > > > I really hope there is, particularly if it includes structure
> > > > > diagrams
> > > etc.
> > > > >
> > > > > Regards
> > > > >
> > > > > Jeremy
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > > For additional commands, e-mail: dev-h...@netbeans.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.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
>
-- 
http://timboudreau.com

Re: Future of old NetBeans bug tracker

[Tim Boudreau]

If Apache can host Bugzilla, why not kick Jira to the curb, dump old
Bugzilla into new Bugzilla and carry on with Bugzilla?

-Tim

On Fri, Oct 18, 2019 at 12:56 PM Geertjan Wielenga 
wrote:

> Hi all,
>
> As we know, we're on JIRA now, i.e., all issues are reported here:
>
> https://issues.apache.org/jira/projects/NETBEANS
>
> The old location from the pre-Apache days are here:
>
> https://netbeans.org/bugzilla
>
> The question is what to do with the above, sure it is read-only, no one
> should be able to create new issues there and at the top of the page
> there's messaging about using the new Apache NetBeans JIRA.
>
> However, since we want to move away from Oracle infrastructure, what do we
> want to do with the NetBeans Bugzilla, ultimately? Simply take it out of
> the air, get and backup the database dump files, or host them somehow?
>
> We have the NetBeans Bugzilla database dump files available at this stage,
> i.e., they're available to use inside Oracle, but the question is what to
> do with them next, where to put them, if anywhere, whether they should be
> hosted, and where.
>
> Any ideas are welcome.
>
> Gj
>
-- 
http://timboudreau.com

Re: Syntax highlighting question

[Tim Boudreau]

It's two separate but related things: modules to let you write a plugin for
any language with an antlr grammar with very little code, and then on top
of that, support for editing Antlr grammars.

The modules supporting various language editing features, like code folding
or navigator panels or highlighting are separate so that if you're not
using those features, you don't need to include them.

So, sort of like schliemann or gsf but not monolithic and more flexible and
extensible.

-Tim

On Mon, Oct 21, 2019 at 12:56 PM Peter Cheung  wrote:

> I have read some of your code, your project seems a very large project,
> many modules in there.
>
>
> Thanks
> From Peter
> 
> From: Peter Cheung 
> Sent: Tuesday, October 22, 2019 12:30 AM
> To: dev@netbeans.apache.org 
> Subject: Re: Syntax highlighting question
>
> Dear Tim
> Thank you for your sincerity. The reason i develop my own antlr plugin
> for netbeans is to support my assembler development.
> https://www.youtube.com/watch?v=rDFkhrHxHMw
>
> So I believe in my netbeans-antlr project, i have developed some
> useful thing dedicated for assembler development, but not useful for others.
>
>
> Thanks
> From Peter
> 
> From: Tim Boudreau 
> Sent: Thursday, October 17, 2019 4:06 AM
> To: dev@netbeans.apache.org 
> Subject: Re: Syntax highlighting question
>
> Hi, Peter,
>
> I would strongly suggest we collaborate on that here:
> https://github.com/timboudreau/ANTLR4-Plugins-for-NetBeans - since that
> way, not only would it be implementable for Antlr, but for *any* language
> using an Antlr grammar (it is two layers of modules - one for writing
> language modules with most features generated for you from *any *Antlr
> grammar, and then modules for Antlr grammar language built on top of that -
> here are some docs on general-language support -
>
> https://github.com/timboudreau/ANTLR4-Plugins-for-NetBeans/blob/master/api.md
> - and I hope to have a continuous build w/ javadocs up soon).
>
> NetBeans lexer and parser APIs have straightforward support for this - see
> LanguagePath and the method on Parser.Result that takes an integer and
> gives you a Parser.Result for an embedded language.
>
> Done right, supporting an embedded language would be as simple as
>
> @EmbeddedLanguage("text/x-java")
> public static final RegionsKey THE_KEY = ...
>
> (the generic language support API revolves around defining typed keys, and
> then extracting what you're actually going to use from the parse tree as
> character ranges with any data you need tied to those ranges, and then you
> can retrieve the actual results from a parser result when a file is
> parsed).
>
> That's been on my todo list too - the original antlr plugin author had
> included a crude Antlr grammar for Java to do that, which isn't a terribly
> sensible way to do it when you have a really good Java parser available for
> use.
>
> -Tim
>
>
> On Tue, Oct 15, 2019 at 6:16 AM Peter Cheung 
> wrote:
>
> > Dear All
> >I have developed a module (
> https://gitlab.com/mcheung63/netbeans-antlr)
> > for antlr, it provides antlr grammar syntax highlight, but it is not
> > perfect. I want to enhance it but problem is : antlr supports "embed
> > action", which is in Java, so two languages in same file.
> >
> >To provide the best syntax highlight, i need to send those embed
> > actions to "java lexer", this point has no problem to me. But Is there
> > anyway merge those tokens (java-lexer) back to the one (antlr-lexer)
> which
> > used by netbeans to provide syntax highlight?
> >
> > Is there any way to provide syntax highlight but not using lexer? Let
> > say i want to hight the second line from character 2-4 in red. Whatever
> the
> > text is, i just want to highlight those positions, is it possible?
> >
> > Thanks
> > From Peter
> >
> >
> >
>
> --
> http://timboudreau.com
>
-- 
http://timboudreau.com

List of dark and light theme names

[Tim Boudreau]

I've got a weird query:  I need to compile a list of all the popular light
and dark editor themes for NetBeans - but, very specifically, the name of
the folder in Editors/FontsColors in the system filesystem, not the
localized display name.

If you run a custom editor theme that's installed by a module, could you
take a look (say, in the NetBeans Runtime Explorer module, or in your
userdir if you've modified some settings of the theme so there's actually
something there) and let me know?

Here's the problem I want to solve:  With the
create-a-full-language-plugin-from-an-Antlr-grammar-and-a-few-annotations
modules I've been working on, you define editor colorings in an
annotation.  Typically, you want one set of colors for bright backgrounds
and another for dark backgrounds, so it lets you define an array of
colorings tied to editor theme folder names, like this:

@HighlighterKeyRegistration(mimeType = ANTLR_MIME_TYPE, order = 2000,
positionInZOrder = 2900,
colors = @ColoringCategory(name = "alternatives",
colors = {
@Coloration(
themes = {"NetBeans", "NetBeans55",
"NetbeansEarth", "Tan", "NetBeans_Solarized_Light" },
bg = {255, 255, 200},
bold = true,
italic = true
),
@Coloration(
themes = {"NetBeans_Solarized_Dark",
"BlueTheme", "Darcula", "CityLights"},
bg = {80, 40, 40},
bold = true,
italic = true
)}))
public static final NamedRegionKey NAMED_ALTERNATIVES =
NamedRegionKey.create("alternatives", RuleTypes.class);

(this is an annotation to provide semantic highlighting, but you do the
same thing for specific  token categories).  You can see above the ones
I've already got.

Thanks,

Tim

--
http://timboudreau.com

Re: Syntax highlighting question

[Tim Boudreau]

Hi, Peter,

I would strongly suggest we collaborate on that here:
https://github.com/timboudreau/ANTLR4-Plugins-for-NetBeans - since that
way, not only would it be implementable for Antlr, but for *any* language
using an Antlr grammar (it is two layers of modules - one for writing
language modules with most features generated for you from *any *Antlr
grammar, and then modules for Antlr grammar language built on top of that -
here are some docs on general-language support -
https://github.com/timboudreau/ANTLR4-Plugins-for-NetBeans/blob/master/api.md
- and I hope to have a continuous build w/ javadocs up soon).

NetBeans lexer and parser APIs have straightforward support for this - see
LanguagePath and the method on Parser.Result that takes an integer and
gives you a Parser.Result for an embedded language.

Done right, supporting an embedded language would be as simple as

@EmbeddedLanguage("text/x-java")
public static final RegionsKey THE_KEY = ...

(the generic language support API revolves around defining typed keys, and
then extracting what you're actually going to use from the parse tree as
character ranges with any data you need tied to those ranges, and then you
can retrieve the actual results from a parser result when a file is parsed).

That's been on my todo list too - the original antlr plugin author had
included a crude Antlr grammar for Java to do that, which isn't a terribly
sensible way to do it when you have a really good Java parser available for
use.

-Tim


On Tue, Oct 15, 2019 at 6:16 AM Peter Cheung  wrote:

> Dear All
>I have developed a module (https://gitlab.com/mcheung63/netbeans-antlr)
> for antlr, it provides antlr grammar syntax highlight, but it is not
> perfect. I want to enhance it but problem is : antlr supports "embed
> action", which is in Java, so two languages in same file.
>
>To provide the best syntax highlight, i need to send those embed
> actions to "java lexer", this point has no problem to me. But Is there
> anyway merge those tokens (java-lexer) back to the one (antlr-lexer) which
> used by netbeans to provide syntax highlight?
>
> Is there any way to provide syntax highlight but not using lexer? Let
> say i want to hight the second line from character 2-4 in red. Whatever the
> text is, i just want to highlight those positions, is it possible?
>
> Thanks
> From Peter
>
>
>

-- 
http://timboudreau.com

Re: energy consumption

[Tim Boudreau]

SSD or "spinning rust" disk?  That could make a big difference, though the
GPU issue likely has something to do with it.

-Tim

On Sun, Oct 13, 2019 at 6:06 PM Peter Cheung  wrote:

> Hi All
> Netbeans 11.1 eat up the notebook battery so fast. My macbook pro 15
> can only stand for 1.5 hour max. Does the group has any plan to optimize it?
> Thanks
> From Peter
>


-- 
http://timboudreau.com

Re: Create+install+use Maven artefacts in local maven repo

[Tim Boudreau]

Here you go:

https://github.com/timboudreau/netbeans-local-maven-repo-populator

-Tim

On Mon, Oct 14, 2019 at 2:16 PM Dmitry Avtonomov <
dmitriy.avtono...@gmail.com> wrote:

> Hi all,
> I've seen that you just voted to release new archetypes for Maven. Is there
> an easy way to do the same locally? I.e. build the platform, package it
> properly and install into local maven repo.
>
> Thank you,
> Dmitry
>


-- 
http://timboudreau.com

Re: nbm, from ant to maven, still hand

[Tim Boudreau]

Add logging and enable it so you know the last time it did something. Get a
thread dump when it hangs and see what's going on.

And chance it's trying to call maven from the AWT event thread? That would
make bad things happen.

-Tim

On Thu, Oct 10, 2019 at 2:47 PM Peter Cheung  wrote:

> sorry, typo in subject, i mean hang, not hand
> 
> From: Peter Cheung 
> Sent: Friday, October 11, 2019 2:46 AM
> To: dev@netbeans.apache.org 
> Subject: nbm, from ant to maven, still hand
>
> Hi
>I have rewrite my MavenRunner plugin from ant to maven, then i install
> it to my local netbeans, after a while (a few times i use netbenas),
> netbeans hang. This problem has been confused for a long time. Any hint? I
> check out the netbeans log, i don't see any wried thing.
>
> https://gitlab.com/mcheung63/MavenRunner
>
> Thanks
> From Peter
>
-- 
http://timboudreau.com

Re: Can anyone give me a help about developing antlr formatter

[Tim Boudreau]

Okay.  If you'd like to try some stuff, I could hook you up with some
modules.  Antlr support - syntax highlighting, navigator panels, syntax
tree views, has been working for a while;  formatting is pretty solid now.
I've spent the last week stabilizing the "live preview" functionality,
which actually generates NetBeans language support with syntax highlighting
for *the grammar you are currently editing* - so you can have a syntax
highlighted preview, and associate a file extension with that grammar and
open those files and interact with them with full IDE support that is
updated whenever you edit the grammar.

Basically the PITA with developing Antlr grammars is when you break some
rule that worked, change a whole bunch of other stuff before you know you
broke it, and then have to figure out which thing you did caused the
problem.  So being able to visually, and instantly, see if something is
broken seems like a basic thing that's needed to make grammar development
much less painful.

Here's a screen shot:
https://timboudreau.com/files/screen/10-09-2019_01-39-44.png

All that gets a bit complex:

 - User edits the grammar file
 - Listener on the grammar file notices and tells highlighters of documents
in the language of that grammar to request a reparse
 - They ask for a new parse from a parser which
- Is actually going to run code in an isolated classloader that loads
from an in-memory filesystem where the grammar and generated analyzer code
was compiled
- Notices that the grammar file - whose document is mapped into that
in-memory filesystem - has changed
- Initiates a new run of Antlr generating parser and lexer
- Compiles them into that memory filesystem
- Generates the source for a thing that will call that parser with
document contents, and retrieve the tokens, parse tree, etc. copied into
proxy objects so the classloader does not leak types
- Creates a new isolated classloader over the class output for all that
- Replaces that classloader in the proxy parser
- Passes the document text into that parser, extracts the proxied parse
tree and wraps that in a NetBeans Parser.Result

The good news is all that can happen in < 100ms.  It works, but I've been
chasing bugs in the choreography of that process to ensure the new parse
runs against the right version of the grammar - each layer of that will use
the previous result if nothing has changed but the input text, and it works
out to being a big chain of lists of weakly referenced susbscribers to
things that subscribe to other things (i.e. the parser subscribes to
replacement of the classloader environment; the highlighters subscribe to
changes on the parser).

It requires a few hacks that will probably get turned into patches -
there's no way via API to get the cache for Source objects for the
in-language document to invalidate its cached parser results because *some
other document* changed, so that has to be done via reflection;  and
similarly, there is no direct way to force a Language instance to be
discarded by its LanguageHierarchy, but if you don't, it will keep a cache
of token ids that will be completely wrong (particularly if the grammar is
unparseable and you get a lexer with a dummy set of token ids with one
token, flip back to a valid language, and back again, which is the normal
state of life in an IDE).

But for basic doing-stuff-with-Antlr it's in decent shape, and it's all
factored into many separate modules, so perhaps I could get some out there.

-Tim












On Wed, Oct 2, 2019 at 2:08 AM Peter Cheung  wrote:

> Dear Tim
>Sorry i am doing my own antlr plugin
> https://gitlab.com/mcheung63/netbeans-antlr to support my compiler
> development which using antlr. If you plugin can well format antlr, then i
> can focus my compiler rather than antlr in netbeans.
> thanks
> Peter
>
>

-- 
http://timboudreau.com

Re: Aligning implementation and specification versions?

[Tim Boudreau]

+1 - I recently found that to have a preview for a formatter requires a
friend dependency, which is ridiculous given that the API has not changed
in many years.

-Tim

On Wed, Sep 25, 2019 at 7:29 AM Neil C Smith  wrote:

> On Sun, 25 Aug 2019 at 19:06, Jesse Glick  wrote:
> > A long time ago I wrote up
> > http://wiki.netbeans.org/NbmPackageStability to discuss problems with
> > the versioning scheme in NB and propose a different system. At this
> > point I would say that the proposed change is unnecessarily complex,
> > and that better development practices would avoid most problems:
>
> Missed this reply at the time - just found it looking for this thread.
> I like the proposal you wrote, and argued for considering it when
> there was a vote a while back on what to do with friend dependencies.
> Not that that vote really led to much conclusive.  I personally
> probably agree with your assessment on the complexity, and the
> suggestions seem good - in particular
>
> > · Use simple specification version dependencies, and mark all packages
> > public which you would expect any other modules to refer to.
>
> ... yes, please let's just do this for NB 11.3 in preparation for next
> LTS!  The active PRs to add friend access for third-party plugins are
> just wrong on so many levels.  Let's keep friends only for the
> minority of legitimate cases where a module has optional extensions
> that need to be separate.
>
> Best wishes,
>
> Neil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
> --
http://timboudreau.com

Re: Can anyone give me a help about developing antlr formatter

[Tim Boudreau]

FYI - due to your question, I decided to prioritize Antlr formatting, and
it is working - along with a generic API for writing formatters for any
file format based on Antlr grammars.  I should have something up on my
update center in the next week or two.

-Tim


On Tue, Oct 1, 2019 at 12:02 PM Peter Cheung  wrote:

> I finally found an example
> https://github.com/iconmaster5326/SourceNetbeansPlugin/blob/cb739ae7d1017e4db88fe2e517bf3e8d816ca4e3/src/com/iconmaster/srcplugin/editor/SourceReformatFactory.java
>
>
> Thanks
> From Peter
> 
> From: Peter Cheung 
> Sent: Tuesday, September 24, 2019 8:07 PM
> To: dev@netbeans.apache.org 
> Subject: Re: Can anyone give me a help about developing antlr formatter
>
> Thank you Tim
> ____
> From: Tim Boudreau 
> Sent: Monday, September 23, 2019 9:05 PM
> To: dev@netbeans.apache.org 
> Subject: Re: Can anyone give me a help about developing antlr formatter
>
> The work in progress is on the "mavenize" branch here -
> https://github.com/timboudreau/ANTLR4-Plugins-for-NetBeans - It is 44
> modules (comprising generic support for generating most of a plugin for any
> Antlr grammar from annotations, and then in antlr-editing-plugins, a suite
> of modules for Antlr itself) :-)
>
> There *was* an Antlr formatter, but this project started with working on an
> exiting Antlr plugin I forked, evolved into generic Antlr support, and I'm
> now in the process of reassembling the original Antlr-editing-only module
> to eat my own dogfood, as a set of modules with all the features of the
> original, plus lots more (like live-syntax highlighting of files in the
> language of the grammar you're editing, which get updated when you edit the
> grammar, visual syntax trees and more - one of the biggest PITA's of Antlr
> development is writing a rule that overrides another rule and not knowing
> it until long after you broke it and then trying to figure out *what* broke
> it, so instant feedback as you edit a grammar is a necessity).
>
> I haven't add formatting back in yet, though.  But I'll keep you posted.
>
> -Tim
>
> On Fri, Sep 20, 2019 at 1:17 AM Peter Cheung 
> wrote:
>
> > Dear Tim
> >Yes, i want to format antlr lang.
> > Thanks
> > From Peter
> > 
> > From: Tim Boudreau 
> > Sent: Monday, September 16, 2019 7:48 AM
> > To: dev@netbeans.apache.org 
> > Subject: Re: Can anyone give me a help about developing antlr formatter
> >
> > I have some stuff under development that might be useful for that. You
> want
> > to format a language that has an Antlr grammar, right?
> >
> > -Tim
> >
> > On Sun, Sep 15, 2019 at 11:43 AM Peter Cheung 
> > wrote:
> >
> > > Hi All
> > >  Can anyone give me a help about developing antlr formatter? Where
> i
> > > can get an example to develop a custom formatter?
> > > Thanks
> > > From Peter
> > >
> > M
> > --
> > http://timboudreau.com
> >
>
>
> --
> http://timboudreau.com
>


-- 
http://timboudreau.com

Re: Why no RELEASE111 of ValidationAPI?

[Tim Boudreau]

I believe ValidationAPI is part of the javacard cluster - or at least it
was developed there - so, that means without the javacard modules, there is
probably nothing that depends on it.

It is just a wrapper for this -
https://github.com/timboudreau/simplevalidation - originally on java.net, I
moved it to github since that.

And just a reminder:  "nobody maintaining" something that works is a
non-problem - software *can* actually be finished, if you carve problems
into small enough and well-defined enough chunks (and you and everyone
should).  Lack of maintenance might mean neglect, but it also might mean it
simply works.  But in this case it has probably not reached a state of
perfection yet, and it *is* maintained (if I had it to write again, a bunch
of it could be done much more cleanly taking advantage of lambdas).

-Tim

On Thu, Sep 19, 2019 at 5:33 AM Andreas Sewe  wrote:

> Eric Barboni wrote:
> > Using  org.netbeans.external: ValidationAPI :RELEASE90 should be enough.
> It is just a jar.
>
> Thanks for digging into this, Eric.
>
> Turns out that ValidationAPI RELEASE82 is byte-for-byte identical to
> RELEASE90, RELEASE100, and RELEASE110. So it doesn't really matter which
> version I pick.
>
> It's a bit worrying, though, that apparently no-one maintains that API
> anymore. But unless it suddenly becomes incompatible with Java Umpteen
> (not impossible, given the speed with which Java is changing nowadays),
> I can live with this.
>
> Best wishes,
>
> Andreas
>
> --
> Dr. Andreas Sewe | s...@cqse.eu | +49 152 56342856
> CQSE GmbH | Centa-Hafenbraedl-Strasse 59 | 81249 Muenchen | www.cqse.eu
> Amtsgericht Muenchen | HRB 177678 | GF: F. Deissenboeck, M. Feilkas
>
>

-- 
http://timboudreau.com

Re: Can anyone give me a help about developing antlr formatter

[Tim Boudreau]

The work in progress is on the "mavenize" branch here -
https://github.com/timboudreau/ANTLR4-Plugins-for-NetBeans - It is 44
modules (comprising generic support for generating most of a plugin for any
Antlr grammar from annotations, and then in antlr-editing-plugins, a suite
of modules for Antlr itself) :-)

There *was* an Antlr formatter, but this project started with working on an
exiting Antlr plugin I forked, evolved into generic Antlr support, and I'm
now in the process of reassembling the original Antlr-editing-only module
to eat my own dogfood, as a set of modules with all the features of the
original, plus lots more (like live-syntax highlighting of files in the
language of the grammar you're editing, which get updated when you edit the
grammar, visual syntax trees and more - one of the biggest PITA's of Antlr
development is writing a rule that overrides another rule and not knowing
it until long after you broke it and then trying to figure out *what* broke
it, so instant feedback as you edit a grammar is a necessity).

I haven't add formatting back in yet, though.  But I'll keep you posted.

-Tim

On Fri, Sep 20, 2019 at 1:17 AM Peter Cheung  wrote:

> Dear Tim
>Yes, i want to format antlr lang.
> Thanks
> From Peter
> ____
> From: Tim Boudreau 
> Sent: Monday, September 16, 2019 7:48 AM
> To: dev@netbeans.apache.org 
> Subject: Re: Can anyone give me a help about developing antlr formatter
>
> I have some stuff under development that might be useful for that. You want
> to format a language that has an Antlr grammar, right?
>
> -Tim
>
> On Sun, Sep 15, 2019 at 11:43 AM Peter Cheung 
> wrote:
>
> > Hi All
> >  Can anyone give me a help about developing antlr formatter? Where i
> > can get an example to develop a custom formatter?
> > Thanks
> > From Peter
> >
> M
> --
> http://timboudreau.com
>


-- 
http://timboudreau.com

Re: Can anyone give me a help about developing antlr formatter

[Tim Boudreau]

I have some stuff under development that might be useful for that. You want
to format a language that has an Antlr grammar, right?

-Tim

On Sun, Sep 15, 2019 at 11:43 AM Peter Cheung  wrote:

> Hi All
>  Can anyone give me a help about developing antlr formatter? Where i
> can get an example to develop a custom formatter?
> Thanks
> From Peter
>
M
-- 
http://timboudreau.com