JavaFX maven archetypes used in NetBeans

[Ernie Rael]

Hi all,

4 years ago I created the jfx archetyes repository, 
https://github.com/errael/javafx-maven-archetypes-netbeans, so that jfx 
projects would work "out of the box" with debugging, profiling, jlink... 
on NetBeans. It's artifact is on maven and used from 
javafx/javafx2.kit/src/org/netbeans/modules/javafx2/kit/JavaFXWizardIterator.java. 
It was based on, not forked from, 
https://github.com/openjfx/javafx-maven-archetypes.


It was incorporated into NetBeans with

   [NETBEANS-3730] Use NewProject JavaFX archetypes tailored for NetBeans
   https://github.com/apache/netbeans/pull/1983

amid controversy. A last resort solution.

Some dev group discussion from February 2020

   https://lists.apache.org/thread/snojp5v3z059m113knwr1zzw7jzmsyby

The hope was that at some point NB could start using the official 
version. There was some discussion of coming up with some standard 
actions, Neil suggested



Could this be a possibility for cross-IDE collaboration with some linking
with Maven team? AFAIK there's not a standard way for a Maven project or
archetype to expose what to execute for common IDE actions like run, debug,
etc.? Surely a vendor neutral option for that would be useful?


AFAIK, there was no such work.

For reference, from openjfx there's

   Add debug execution to the created archetypes
   https://github.com/openjfx/javafx-maven-archetypes/pull/10
   (Opened March 2020, Merged April 2021)

   add nbactions #7
   https://github.com/openjfx/javafx-maven-archetypes/issues/7
   (Opened November 2019)

Anyway, saw https://gluonhq.com/products/javafx/ today and the minimum 
jdk for javax has recently changed (Is Netbeans going to jdk-17 soon?) 
and was reminded of this repo. Vaguely recall some discussion of a NB 
repo for things like this.


Is there a NB repo where this can go?

-ernie

Re: Jackpot convert log4j to System.logger

[Ernie Rael]

Thanks Michael,

Yeah. I can do something like

   => $logger.log(System.Logger.Level.WARNING, $args$)

and the code ends up with

   logger.log(Logger.Level.WARNING, getColu...

Just putting the word "WARNING" ends up with compilation error since no 
import is added.


So I'll just write it to get the single word "WARNING", and then 
manually add "import static Level.*;" to the files.


I vaguely recall having problems in the past with static imports.

-ernie

On 24/02/14 10:20 PM, Michael Bien wrote:

Hi Ernie,

the imports block on top of the hints file is for the hints file 
itself. It is not added to the refactored sources or anything like that.


Imports are added automatically when the hint is applied if new 
imports are needed, there is no way to control this mechanism.


-mbien

On 15.02.24 07:09, Ernie Rael wrote:
Using the follow does most of the conversion work, requires some 
manual fixup for certain log4j arguments. But *import static 
java.lang.System.Logger.Level.*;* doesn't get added. Any suggestions 
for a way to add that as part of the refactoring?


-ernie

   

        org.apache.logging.log4j.Logger
   =>  java.lang.System.Logger
   ;;

   "error":
        $logger.error($args$)
   ::  $logger instanceof org.apache.logging.log4j.Logger
   =>  $logger.log(ERROR, $args$)
   ;;

   ...





-
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

Jackpot convert log4j to System.logger

[Ernie Rael]

Using the follow does most of the conversion work, requires some manual 
fixup for certain log4j arguments. But *import static 
java.lang.System.Logger.Level.*;* doesn't get added. Any suggestions for 
a way to add that as part of the refactoring?


-ernie

   

    org.apache.logging.log4j.Logger
   =>  java.lang.System.Logger
   ;;

   "error":
    $logger.error($args$)
   ::  $logger instanceof org.apache.logging.log4j.Logger
   =>  $logger.log(ERROR, $args$)
   ;;

   ...

Re: NB 21-RC2 doesn't have Gradle-8.5

[Ernie Rael]

On 24/02/05 9:03 AM, Ernie Rael wrote:

On 24/02/05 7:02 AM, Neil C Smith wrote:

Hi,

On Sun, 4 Feb 2024 at 23:33, Ernie Rael  wrote:

If there's going to be an RC-3, I'll wait for that. (was it skipped last
week?)

If possible could you test the dev build at

DONE

This PR build
is prior to merging that to see if the fallback path that should have
been kicking in is working properly now.


$ ./gradlew --version

Welcome to Gradle 8.6!

Cool,
-ernie


BTW, did

> gradleproject1 > properties

Then looked through each categories-screen in "Project Properties - 
gradleproject1" window. Saw nothing about a gradle version. Same for 
"Project Properties - gradleproject1:lib".


I don't get the earlier comment about which gradle version the IDE 
thinks it's using


-ernie


Thanks,

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

Re: NB 21-RC2 doesn't have Gradle-8.5

[Ernie Rael]

On 24/02/05 7:02 AM, Neil C Smith wrote:

Hi,

On Sun, 4 Feb 2024 at 23:33, Ernie Rael  wrote:

If there's going to be an RC-3, I'll wait for that. (was it skipped last
week?)

If possible could you test the dev build at

DONE

This PR build
is prior to merging that to see if the fallback path that should have
been kicking in is working properly now.


   $ ./gradlew --version

   Welcome to Gradle 8.6!

Cool,
-ernie



Thanks,

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

Re: NB 21-RC2 doesn't have Gradle-8.5

[Ernie Rael]

On 24/02/04 3:20 PM, Neil C Smith wrote:

On Sun, 4 Feb 2024, 22:12 Ernie Rael,  wrote:


On 24/02/04 7:11 AM, Neil C Smith wrote:

On Thu, 25 Jan 2024 at 20:21, Ernie Rael  wrote:

With NB-21-RC2, running on JDK-21,
doing: NewProject > JavaWithGradle > JavaClassLibrary
And there is the "resolve problems" icon.

$ ./gradlew --version
Gradle 8.4

I presume you're running that from the IDE?


The wrapper task in the wizards is run using gradle-version latest.
So even if the IDE uses 8.4 of the Tooling API, you should be seeing Gradle
8.5 (or possibly now 8.6) in the project.

For me the projects are set up with 8.5 (in gradle.properties), but the IDE
thinks it's still 8.4.

There's a bug in the order of tasks in the wizard which might be at fault
here too.


If there's going to be an RC-3, I'll wait for that. (was it skipped last 
week?)


-ernie



We are going to look at upgrading the Tooling API for NB21, but without it
you still shouldn't be seeing the issue you are.

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

Re: NB 21-RC2 doesn't have Gradle-8.5

[Ernie Rael]

On 24/02/04 7:11 AM, Neil C Smith wrote:

On Thu, 25 Jan 2024 at 20:21, Ernie Rael  wrote:

With NB-21-RC2, running on JDK-21,
doing: NewProject > JavaWithGradle > JavaClassLibrary
And there is the "resolve problems" icon.

$ ./gradlew --version
Gradle 8.4

I presume you're running that from the IDE?

Using that wizard checking the project files and using the CLI call to
./gradlew --version show Gradle 8.5 for me.  But the IDE is using
8.4?!  Until reopening / restarting the IDE anyway.


I don't understand what you're asking/saying; that mail is from over a 
week ago. (I ran "./gradlew --version" from a linux command line)


And there's

   Update Gradle Tooling API wrapper to 8.5 #7022

Which is from a few days ago, but according to the comments, it's closed 
in favor of


   Update Gradle Tooling API to 8.6 #6926

which is still open.

BTW, in the 1st PR's discussion there's mention of a bug, 
https://github.com/apache/netbeans/pull/7022#issuecomment-1923512378, 
identified in early December. Is this something that can/should be 
addressed?


-ernie



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

NB 21-RC2 doesn't have Gradle-8.5

[Ernie Rael]

With NB-21-RC2, running on JDK-21,
doing: NewProject > JavaWithGradle > JavaClassLibrary
And there is the "resolve problems" icon.

$ ./gradlew --version
Gradle 8.4

I thought this would be Gradle-8.5, especially since there was talk with 
NB-20

of waiting for Gradle-8.5.

Unlike with NB-20, with NB-21-RC2, manually upgrading to Gradle-8.5 the
"resolve problems" goes away, so that's a good thing.

There was some discussion of gradle problems with NB-20,
In the thread: "Java version: 21 ... not supported by Gradle 8.5"
https://lists.apache.org/thread/m4vppqn8ks3b2gqtc1llctm19vwqwwx9

One comment in particular

> It seems the bootclasspath is set to the runtime
> classpath, that means the Java 21 syntax elements would be available in
> the editor, but the new API won't.

Since manually upgrading to G-8.5 works better with NB 21-RC2, I'm guessing
this issue is fixed, but since I don't know any details about it, just 
checking.


-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

Re: Windows 11 Issues - Copy/Paste Failure

[Ernie Rael]

I too used windows for several years (linux now, it's wonderful and no 
more cygwin), I don't recall having seen this issue. But I use jVi which 
has it's own cut/paste handling that behaves like vim's (there's even a 
flavor so blockmode copy/paste works between vim/jVi). Otherwise 
clipboard interfacing is as simple as can be.


My experience would support legacy/ancient code being involved.

-ernie


On 23/08/29 6:57 AM, Scott Palmer wrote:

The last time I looked into it, there seemed to be some workarounds in
NetBeans for ancient Swing clipboard issues that probably don't apply
anymore.  I think NB is doing something weird with the clipboard.

I'm primarily developing on Linux now, so I'm spared from this issue.  But
when I worked on Windows it happened all the time.  It was a weekly
annoyance.

Scott


On Tue, Aug 29, 2023 at 6:03 AM Neil C Smith  wrote:


On Tue, 29 Aug 2023 at 01:14, Michael Bien  wrote:

On 29.08.23 00:50, Kenneth Fogel wrote:

I have mentioned this before, but the situation is getting worse. More

often than not, I must cut the text, paste the text

this issue is tracked here:

https://github.com/apache/netbeans/issues/3962

I do have a question. How many people actively working on NetBeans do

this in a Windows rather than Linux or MacOS operating system?

I believe most NB maintainers are indeed not using windows as their
primary OS, those who are might not be able to reproduce it given that
it shows some symptoms of a race condition (but it could be something

else).

It's not just about who is working on Windows, either, but whether
they can reproduce the problem.  While my primary development platform
is Ubuntu, I've got development and testing machines on Windows and
macOS.  I've tried multiple times to reproduce this, including using
the automated test in that issue (Ken, please look at that too).  My
system simply never shows the problem.

I think Michael is right to suggest a race condition is in play here.
That enabling fine logging mitigates the issue for many would suggest
timing.  However, the logging also has side effects, which eagerly
acquires the data in the clipboard, which could also be affecting the
outcome.

Also, let's not assume that this is unique to NetBeans or even a bug
in NetBeans itself!  https://youtrack.jetbrains.com/issue/JBR-5980/

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

Re: Plugin Verifikation Plugins Portal (changing rules)

[Ernie Rael]

> The requirement to sign the plugins is questionable in itself

Especially considering that it's in maven central.

-ernie

On 23/08/13 1:10 PM, Matthias Bläsing wrote:

Hi again,

I just noticed, that the LDIF Editor and LDAP Explorer plugins were
rejected for the plugin portal for 19.

Reasoning:

Plugin unsigned. Please sign (self-signed is ok) and re-submit for
verification

This was not a problem in: 11, 12, 16 and 17.


_Nothing_ changed for these plugins and I don't see why I should was
resources in CI/CD systems and on maven central, just to "fix"
something, that was not broken for a long time.

The requirement to sign the plugins is questionable in itself without a
trust anchor or revocation list, but I can live with with requiring
signature for updates (this will become fun, once the signature
expires, but ...), but this is not the case here. For the PlantUML
Plugin I created a signed build, because the package changed and so it
was worth spending the bandwith and space and time.

Would be nice, if you could take back the reject and get this approved.

Thank you

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






-
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

Re: Maven indexing on NB 18

[Ernie Rael]

Using a newish large memory, multi-core laptop. The fan made itself known.
Indexing took ~15 minutes.
Over a weeks worth of logs, only one indexing of central. There's a little
"2nd thought" bouncing that seems to go on immediately after the indexing.

An aside

   While taking a look at this I ran into something messy.
   Not repository, but source indexing relating.
    log filled with huge repeating message (4K each)
   https://github.com/apache/netbeans/issues/6071


WARNING: package com.apple.eio not in java.desktop
---
>Log Session: Thursday, June 8, 2023 at 2:34:34 PM Pacific Daylight Time
>System Info:
  Product Version = Apache NetBeans IDE 18
  Operating System    = Linux version 6.2.6-76060206-generic 
running on amd64
  Java; VM; Vendor    = 17.0.6; Java HotSpot(TM) 64-Bit Server VM 
17.0.6+9-LTS-190; Oracle Corporation
  Runtime = Java(TM) SE Runtime Environment 
17.0.6+9-LTS-190

...
INFO [org.apache.lucene.search.MultiTermQuery_patched]: patched 
MultiTermQuery.hashCode() initialized. (LUCENE-10431)
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of maven-snapshots took 0.99 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
could not (re-)index maven-snapshots
org.apache.maven.wagon.ResourceDoesNotExistException: resource missing 
at 
https://oss.sonatype.org/content/repositories/snapshots/.index/nexus-maven-repository-index.properties, 
status: 404 Not Found
    at 
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData(AbstractHttpClientWagon.java:1191)

...
[catch] at 
org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl.lambda$spawnIndexLoadedRepo$4(NexusRepositoryIndexerImpl.java:668)

... one exception

... 18 lines of test application logging

[maven-local-indexing] INFO 
org.eclipse.aether.internal.impl.DefaultArtifactResolver - Artifact 
org.sonatype.nexus.buildsupport:nexus-buildsupport-shiro:pom:2.15.1-02 
is present in the local repository, but cached from a remote repository 
ID that is unavailable in current build context, verifying that is 
downloadable from [maven-snapshots 
(https://oss.sonatype.org/content/repositories/snapshots/, default, 
releases+snapshots), central (https://repo.maven.apache.org/maven2/, 
default, releases+snapshots)]


... 231 messages like the one above, sigh

INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of local took 18.73 s.


... 597 lines of seemingly unrelated random stuff

INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 897.69 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.10 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.03 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.03 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.03 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.03 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.03 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.03 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.04 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.03 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.02 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.02 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.03 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.03 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.03 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.03 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.03 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.03 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.03 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.03 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.05 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central took 0.03 s.
INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: 
Indexing of central 

Re: [LAZY CONSENSUS] Managing archetype for javaEE in house

[Ernie Rael]

On 23/05/22 2:29 AM, Eric Barboni wrote:

This is to propose the creation of new repository to manage javaEE archetype
that we use in Apache NetBeans on Apache NetBeans infrastructure.

We already have some archetype for platform and app creation
https://github.com/apache/netbeans-mavenutils-archetype-netbeans-platform-ap
p-archetype
https://github.com/apache/netbeans-mavenutils-archetype-nbm-archetype

This one is no more used
https://github.com/apache/netbeans-mavenutils-archetype-nbm-suite-root

Maybe we could merge all archetype into one repo.


Do you mean only for JavaEE, or for all archetypes used in NetBeans?

+1 for all (don't use JavaEE, won't opine, seems to make sense)

-ernie



This thread will be active for 72h. Please do raise concern on -1

Best Regards
Eric


-
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

Re: Maven Project Archetypes used by NetBeans

[Ernie Rael]

Hi Eric and all,

In 
javafx/javafx2.kit/src/org/netbeans/modules/javafx2/kit/JavaFXWizardIterator.java 
there's  references like


   return definedFXArchetype("com.raelity.jfx",
   "javafx-archetype-fxml-netbeans",
  "0.0.4", Bundle.LBL_Maven_FXML_Archetype());

The maven artifacts are created from

   https://github.com/errael/javafx-maven-archetypes-netbeans

With this a "new > project" has a variety of functionality that works 
out of the the box. Debug, profile, ... (I don't remember what exactly).


Every once and a while there's mention of bringing these scattered 
things under an NB umbrella and I keep hoping it will be done and I can 
get rid of this repository. Is there an issue for that? Somewhere I can 
add pointer to this stuff so it can be found after I'm dead and buried? 
Of course, if I can figure out how to reach out from the grave, I'd aim 
to do that when the time is right; but even if I can do it, I may 
otherwise be engaged.


-ernie

On 23/05/17 5:39 AM, Eric Barboni wrote:

Hi,

Well if you publish it on your own "groupid" we will later need to do IP 
clearance if we want it at Apache NetBeans could be done on a pr on a 
github/apache/netbeans-archetype-javee repo (not yes created)

We already have some

https://github.com/apache/netbeans-mavenutils-archetype-nbm-archetype

Best Regards
Eric

-Message d'origine-
De : Josh Juneau  
Envoyé : mercredi 17 mai 2023 02:01

À :dev@netbeans.apache.org
Cc : Eric Barboni
Objet : Re: Maven Project Archetypes used by NetBeans

+1 for centralizing the archetypes.  Thanks for updating the Jakarta EE 
archetype…looking forward to trying it out!

Josh Juneau


On May 16, 2023, at 6:16 PM, Benjamin Asbach  wrote:

Thanks for your response.

I created a archetype for JakartaEE war projects from scratch. In contrast to 
the current used archetype it:

* does not configure endorsed dir compiler stuff (actually I never saw
it used int the wild, but may there are some people with more
experience). Normally it's the first thing I remove when I create a
new web application
* combines generation of all Jakarta EE versions and variants (full,
web, core) (currently for a version a dedicated archetype is used -
which seems to be harder to maintain) (this might simplify current
NetBeans codebase as well)
* pins maven-surefire-plugin in order to be prepared for JUnit 5 usage
* pins maven-war-plugin in order to be compilable with Java 17 (see
https://github.com/apache/netbeans/issues/4552)

Would be happy to contribute it:
https://github.com/asbachb/jakartaee-war-archetype

Greetings,
Benjamin


On 2023-05-15 18:22, Eric Barboni wrote:
Hi,
This can be done. We already have the one for netbeans platform.
We must have a complete list + having the ok to go from author to
give the source to us. (IP-clearance).
Best Regards
Eric
-Message d'origine-
De : Benjamin Asbach  Envoyé : dimanche 14 mai 2023
20:06 À :dev@netbeans.apache.org  Objet : Maven Project Archetypes
used by NetBeans Hej, I recently had a look into
https://github.com/apache/netbeans/issues/4552
I just wonder if NetBeans project want to rely on third party
archetypes which cannot be adjusted easily.
Would it a good idea to maintain and distribute NetBeans within the
NetBeans git repository so that the NetBeans team have full control
over these essential parts of the system?
Greetings,
Benjamin
-
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

-
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

Re: [NetBeans PluginPortal] Check your plugin with the new Apache NetBeans 18!

[Ernie Rael]

Just got this, good to be reminded. (and it's not even for an RC)

Couple problems

The link has a double '//' which breaks it with firefox.

On the plugin "version management" page "NB 18" is listed,
but there is no "Request verification" button for that release.

-ernie


On 23/04/21 1:41 PM, NetBeans webmaster wrote:


Hey errael,

have you heard of the new Apache NetBeans version on the horizon? Yes, 
the NetBeans community is going to release version 18 soon! In order 
to have your great plugin(s) available on the NetBeans Update Center 
also for users of the new version please consider testing the 
plugin(s) with the latest RC build and possibly submit new 
verification request(s) via the Plugin Portal website.


Your plugins:

  * jVi Update Center JDK-11
  * jLogMan for NetBeans
  * Editor Pin

Direct link to the list of your plugins:
https://plugins.netbeans.apache.org//plugin/list

Apache NetBeans 18 release candidates 



Thanks for your contribution and ongoing support!
Apache NetBeans Plugin Portal Administrator

P.S.: Please contact dev@netbeans.apache.org mailing list for any 
questions.

Re: Lets talk about JDK 8 (new year edition)

[Ernie Rael]

On 23/02/05 11:31 AM, Michael Bien wrote:


NB 16/17 ships nb-javac which is based on JDK 19. Which means the 
minimum bytecode level is 7 already. Once nb-javac updates to 20 that 
number would be 8. (JDK 14 dropped support for 6, 20 dropped support 
for 7, 


The link Neil gave

https://www.oracle.com/java/technologies/java-se-support-roadmap.html

may provide some insight into when JDK drops support (or it could be 
coincidence) for a bytecode level.

That page indicates Extended Support for JDK-7 ended in 2022 and the first 
release of 2023, JDK-20, dropped support for JDK-7.

Once thing curious is that Extended Support for JDK-8 ends in 2030, which 
is/after/  Extended Support ends for both JDK-11 and JDK-17.

-ernie

it is highly unlikely that the compiler will drop support for LTS 
releases like 8)

Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))

[Ernie Rael]

(Apologies if you see this twice. First sent this 3 hours ago. It was 
not delivered to me; anyone?)


As Neil says

The question is whether it is worth it?

And Scott
An informed decision needs to be based on these details.  Holding back 
for
JDK 8 compatibility helps no one if there isn't actually any real 
demand to

do so.
AFAICT, there's no stats on JDK version and NBP projects. Maybe the 
closest is general

JDK  usage, I don't know how well they relate, but it's the best we've got.

Last year, there were reports that JDK-8/JDK-11 were neck and neck at 
somewhat under

50 percent, with JDK-11 and JDK-17 picking up steam.

So where's JDK-8 this year? An estimate might be 33%. If one third of 
users are on
JDK-8, is that a real demand? Definitely JDK-8 usage is going down, how 
steeply?

(Plenty of hand waving, but worth trying to base the discussion on fact.)

One question, what is the point below which there's no real demand and it's
not worth it?

-ernie

On 23/02/12 2:22 PM, Neil C Smith wrote:

On Sun, 12 Feb 2023, 19:11 Matthias Bläsing,
  wrote:


Hi,

Am Freitag, dem 10.02.2023 um 10:12 + schrieb Neil C Smith:

On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing

wrote:

- commit to make NetBeans runnable on JDK LTS -1
- build with JDK LTS -1
- be able to be build with the current JDK

+1 as long as that includes the platform.

That is what I suggested in the other thread (I don't see why we need
multiple threads incidentally!)

An LTS-1 strategy seems closest to how NetBeans used to function -
major-1, in a time when it also had more development resources?

Let's also be clear, though, that adopting an LTS-1 strategy means
dropping JDK 11 support either in our first release after JDK 21, or
the first after JDK 22 - so latest May 2024.

why would we do that? I said _runnable_ and _buildable_. As long as the
current JDK support the target release I did not exclude that.


In which case I don't understand what you mean by committing to make
NetBeans buildable and runnable on LTS-1? That to me means dropping the
commitment to JDK 11 when it becomes LTS-2.




- keep as many modules as feasible compatible with release 8

-1 : A number of things have come up recently about preparing for JDK
21+ that would involve increasing the bytecode level and APIs in some
core parts of the NetBeans runtime container.

Could you elaborate what that is? Not using Thread#stop and dropping
finalizers is it not. That can be done (with some pain) with support
for 8. So what is the problem?


Yes, those and I think some others. My paragraph after the one you quoted
was acknowledging we can do this for 8 with some pain (headache). The
question is whether it is worth it?

Best wishes,

Neil

Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))

[Ernie Rael]

As Neil says

The question is whether it is worth it?

And Scott

An informed decision needs to be based on these details.  Holding back for
JDK 8 compatibility helps no one if there isn't actually any real demand to
do so.
AFAICT, there's no stats on JDK version and NBP projects. Maybe the 
closest is general

JDK  usage, I don't know how well they relate, but it's the best we've got.

Last year, there were reports that JDK-8/JDK-11 were neck and neck at 
somewhat under

50 percent, with JDK-11 and JDK-17 picking up steam.

So where's JDK-8 this year? An estimate might be 33%. If one third of 
users are on
JDK-8, is that a real demand? Definitely JDK-8 usage is going down, how 
steeply?

(Plenty of hand waving, but worth trying to base the discussion on fact.)

One question, what is the point below which there's no real demand and it's
not worth it?

-ernie

On 23/02/12 2:22 PM, Neil C Smith wrote:

On Sun, 12 Feb 2023, 19:11 Matthias Bläsing,
 wrote:


Hi,

Am Freitag, dem 10.02.2023 um 10:12 + schrieb Neil C Smith:

On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing 


wrote:

- commit to make NetBeans runnable on JDK LTS -1
- build with JDK LTS -1
- be able to be build with the current JDK

+1 as long as that includes the platform.

That is what I suggested in the other thread (I don't see why we need
multiple threads incidentally!)

An LTS-1 strategy seems closest to how NetBeans used to function -
major-1, in a time when it also had more development resources?

Let's also be clear, though, that adopting an LTS-1 strategy means
dropping JDK 11 support either in our first release after JDK 21, or
the first after JDK 22 - so latest May 2024.

why would we do that? I said _runnable_ and _buildable_. As long as the
current JDK support the target release I did not exclude that.


In which case I don't understand what you mean by committing to make
NetBeans buildable and runnable on LTS-1? That to me means dropping the
commitment to JDK 11 when it becomes LTS-2.




- keep as many modules as feasible compatible with release 8

-1 : A number of things have come up recently about preparing for JDK
21+ that would involve increasing the bytecode level and APIs in some
core parts of the NetBeans runtime container.

Could you elaborate what that is? Not using Thread#stop and dropping
finalizers is it not. That can be done (with some pain) with support
for 8. So what is the problem?


Yes, those and I think some others. My paragraph after the one you quoted
was acknowledging we can do this for 8 with some pain (headache). The
question is whether it is worth it?

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

Extract Interface...

[Ernie Rael]

I'm starting to work with some unfamiliar code. For example I've got

   class DerivedTableModel extends AbstractTableModel
   class DerivedJTable extends JTable

I want a list of all methods in DerivedTableModel that are not in 
AbstractTableModel. I tried "Refactor > ExtractInterface" but the list 
includes all methods defined in DerivedTableModel and if you click the 
"check all action" at the bottom it gets all methods; not what I'm 
looking for.


One thought is to have "exclude" option checkboxes

   Implemented Interface methods
   Extended Class methods
   Unknown Methods

To get the current default none of these checked, so all methods are 
included. One think I'm looking for, I'd check both interface/class 
options, so only methods that do not override something is in the list 
of methods to chose from.


My task is to provide a plug in compatible alternate implementation. 
Knowing what needs to be implmented, and isn't part of 
AbtractTableModel, is a place to start. It could be argued that such an 
interface should have been made when DerivedTableModel was first built.


Another list, with "Unknown Methods" checked, is also useful to look at 
especially when it comes to considering how super class/interface are 
tweaked.


Any convenient way to get these? I haven't done a deep dive into how 
useful these would actually be. I'd consider adding the "exclude" 
checkboxes if it seems useful and someone is willing to answer questions 
about "Extract Interface" and review PR. I don't think I've ever looked 
at any refactor code; might be a steep curve; but since it's filters on 
an existing list, might not be too bad.


-ernie

Re: Rust, anyone?

[Ernie Rael]

On 23/02/11 5:26 PM, Arafat BOUCHAFRA wrote:

Hi,

I'm here to help, just create a GitHub repository, and a discord server
channel, and share them with me


In a later message:

https://github.com/vieiro/netbeans-cnd/tree/rust




Regards

Le sam. 11 févr. 2023 à 15:54, Antonio  a
écrit :


Hi all,

Is there interest in adding Rust support to NetBeans?

I have a minimal cluster with Rust support, but I'm not sure I'll be
able to maintain it. Maybe a plugin is a better idea?

Thanks,
Antonio

-
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

Re: NetBeans is a framework was: Lets talk about JDK 8 (new year edition)

[Ernie Rael]

It's too bad there are no NetBeans specific statistics, both IDE and 
platform.
It sure would be nice if there were some reference to stats on jdk 
version usage

in these  deliberations.

What I've seen in reports, the most recent I've found from mid 2022,


even though Java 11 had been available for more than a year. Since
then, the balance has shifted between these two LTS release versions.
More than 48% of applications are now using Java 11 in production (up
from 11.11% in 2020) with Java 8 a close second, capturing 46.45% of
applications using the version in production.

Java 17 has not climbed the charts, but in the handful of months since
its release, it has already surpassed the Java 6, Java 10, and Java 16
releases. [3]


Most reports show 8/11 neck and neck, with expectations that 11/17 continue
to increase share. [2], [3], [4]. Are there more recent reports around?

Something that seems to be missing from the conversation is an /Apache/
/NetBeans Mission Statement/ (or I just haven't seen it). That would include
who are the target users and with what priorities? Professionals, 
Hobbyists,

Educators? A more detailed breakdown might be appropriate. And of course
IDE vs Platform considerations.

-ernie

[1] 
https://www.stackchief.com/blog/Which%20Version%20of%20Java%20Should%20You%20Use%3F
[2] 
https://sdtimes.com/java/report-percentage-of-oracle-jdk-distributions-in-java-ecosystem-drops-significantly/

[3] https://newrelic.com/resources/report/2022-state-of-java-ecosystem
[4] 
https://www.infoworld.com/article/3652408/java-8-still-dominates-but-java-17-wave-is-coming-survey.html


On 23/02/08 8:38 PM, Jaroslav Tulach wrote:

NetBeans isn't just an IDE, but it is a framework!

When designing frameworks and libraries that shall be widely adopted it is
important to increase portability as much as possible. If an API can be used
on different systems, different configurations, the amount of users including
such API in their applications grows.

The best way to hurt portability is to depend on a 3rd party API that isn't
portable. Depending on Win32 API is one such example. Of course, writing in
Java (a language designed to write once and run everywhere) greatly increases
portability. However there is another axis hurting portability - the supported
JDK version. Of course, should a library be widely used, it has to support as
oldest JDK as possible. These days it is JDK8 - the primary reason being that
Android supports JDK8 - as such, should a library be aspire to be used on
Android (as well as regular Java), it needs to stick to version eight. Btw.
not that many years ago, Android only supported JDK6 and many libraries had to
stay with JDK6 APIs and language.


Supporting the ancient JDK gives the application writers using such library or
framework a freedom to choose their JDK. The application writers can then run
on oldest or newest JDK. That's the kind of freedom they want. However there's
transitivity of non-portability - the portability of the final application
cannot be bigger than portability of the least portable library used. This
applies also to 3rd party dependencies a framework or library has: again their
non-portability may negatively affect portability of such framework or library.

I was my NetBeans libraries to be as portable as possible and also run on
Android. I want to use `Lookup` & co.
-jt




-
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

Re: PRs and squashing

[Ernie Rael]

On 23/02/07 3:29 AM, Neil C Smith wrote:

On Mon, 6 Feb 2023 at 17:28, Ernie Rael  wrote:


Here's my understanding: squashing and force pushing to a PR branch, in
particular one that I opened, does not run into issues.

Yes, you're all good.

Note that by default, every committer has write access to your PR branch too.
Yeah, I discovered that a while ago in a different project; quite a 
surprise, disconcerting.

I leave the default, like a trust building exercise ;-)

-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

Re: Lets talk about JDK 8 (new year edition)

[Ernie Rael]

On 23/02/05 7:52 AM, Neil C Smith wrote:

On Wed, 11 Jan 2023 at 11:03, Neil C Smith  wrote:

Yes, the sooner we can update what was agreed for NB13, the better.
But that requires notice (so not NB17, and possibly not NB18), a new
lazy consensus proposal, and no vetoes!

Let's talk some more about JDK 8 ... and JDK 11 for that matter! :-)


Maybe somewhat off topic, but

Is there any data on the distribution of NetBeans versions in use?
In particular I'm wondering about how to set minimum supported
NetBeans version for plugin

-ernie



While the immediate NB17 issue was resolved, but given comments in
other threads more recently, it would be good not to let the
discussion on when and how to drop the rest of our JDK 8 support.  In
particular with JDK 21 (the next LTS) already on the horizon later
this year.

In the past I believe NetBeans supported current and previous Java
releases?  Now might be the time to consider what our long term plan
with the new JDK release schedule should be too.  Previously we've
discussed LTS-1, LTS and current as perhaps the limit of our capacity,
for both maintaining and testing infrastructure?

Firstly, do we look to move to JDK 11 as the baseline release for
compilation, and running of all modules from NetBeans 19 (Aug 2023)?
That allows us to advertise the NetBeans 18 platform as the last
release that will support JDK 8, as well as give us time to look at
remaining problems with tests?

Secondly, should we at the same time advertise a plan for future JDK
support so that IDE and platform users have something concrete to work
with?  This could be based on LTS-1, LTS and current.  We could take
the release of JDK 22, when JDK 21 stops being "current", as the point
where we drop support for JDK 11.  That would have NetBeans 22 (May
2024) requiring JDK 17 for build and run.

We have required JDK 11 for build some time before dropping JDK 8
support.  Do we go back to min JDK for build and run being the same
again, moving build and run min JDK 17 at the same time, or staggered?

Thoughts?  Concerns?  Alternatives?

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

Re: Issue management issues (meta-issues?!)

[Ernie Rael]

On 23/02/06 12:34 PM, Neil C Smith wrote:

On Sat, 4 Feb 2023 at 00:51, Michael Bien  wrote:

yeah it seems like nobody is using the triage label the way it was
originally intended.

We could probably just remove that label (or don't let gh set it by
default at the very least). If something is missing labels it is
probably not triaged.

I'd prefer to keep a label.  Possibly even more likely to accumulate
unanswered issues without?

One of the original intentions was to allow us to use GH actions for
some automation.  We could remove the label automatically if a
committer replies?


I think "NeedsTriage" has a meaning beyond that someone has made a comment.
How about "NeedsTriage" can only be taken away when either "Bug" or
"FeatureRequest" or ??? is added.

-ernie


   Could even email a report of older issues without
a response on a regular basis?


and probably more. Should we prefix all issue specific labels with
'issue:'? So that they are easier to find in the search? Mentioning
'issue' in the label description would have a similar effect.

Possibly would help.  Need to check whether they're used, and make
sure we don't rename any with special meaning though.

Incidentally, also need to handle the fact that GH changed the forms
so that required dropdowns are being populated - I think that's why
we've had more offers of PRs! :-)

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

PRs and squashing

[Ernie Rael]

Looking for clarification on some issues that arose in a side discussion 
in a PR.It comes down to this statement:


   So if I get this right, a pattern is to push several commits to a
   PR, then after approval, can squash locally (using mercurial in my
   case) and force push to the PR.

There were some comments about squash/merge and how github/git commands 
have issues going directly to main. I got confused because I missed the 
"to main" versus "to PR branch" distinction.


Here's my understanding: squashing and force pushing to a PR branch, in 
particular one that I opened, does not run into issues.


And from my perspective, as someone who never pushes to master, I can 
ignore issues relating to peculiarities around local squash and merge 
pushed directly to master.


An open question. If there's a PR with multiple commits and it's 
approved, and I then locally squashand force push to the PR branch. Does 
the "Compare" button associated with the forced push still show up and 
have a diff with no changes (assuming, of course, that there were no 
changes)?


Of course, depending on the situation, there are times when multiple 
commits in a single PR are desirable (fix+refactoring is given as an 
example).


-ernie

Re: building netbeans w/ different compiler

[Ernie Rael]

About using build.properties and nbjdk.home

There's a thread from last year, 
https://lists.apache.org/thread/4qvk880rkn4norzk7t9tt92ppmnf48kp, where 
it was not sufficient to set nbjdk.home, JAVA_HOME also had to be set.


I was using nbbuild/user.build.properties, not ~/.nbbuild.properties; 
don't know if that makes a difference.


-ernie

On 23/02/04 2:43 PM, Matthias Bläsing wrote:

Hi Brad,

Am Samstag, dem 04.02.2023 um 16:27 -0600 schrieb Brad Walker:

I can't figure out what options to use so that doing a build with Ant
compiles with a different compiler. I've looked all over the web page and
can't seem to find it there.

So 2 questions:

1 - Does compiling Netbeans out of the box continue to Java 8 as the
compiler?

You'll need JDK 11. Most modules still build for 8, but they use the
javac release flag to do that. I don't remember when that change was
made, but it was some time ago.


2 - What option would I pass to Ant in order for it to use a different
compiler?

Creating a file ".nbbuild.properties" in your home directory with the
contents:

nbjdk.home=

should do it.

Or you ensure, that that file das not exists/the property is not set
and put your target JDK as first element onto $PATH and set $JAVA_HOME
accordingly.

HTH

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






-
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

Re: Jackpot

[Ernie Rael]

On 23/01/26 10:25 AM, Scott Palmer wrote:

Well, yeah of course.. but is there a documented public API?
The maven plugin doesn't actually do refactoring, right?  It just
identifies hints?


At: https://netbeans.apache.org/jackpot/

To apply the changes produced by the declarative hints, run 
jackpot30:apply:

$ mvn -q jackpot30:apply && git diff


Haven't tried it, but sure looks like it does the refactoring.

-ernie


I was just wondering if there are notes somewhere that go a bit deeper than
showing how to use it from the command line or NetBeans.

I did find a README in the cmdline folder.  So at least that's a start for
getting something to build.

Thanks,

Scott

On Thu, Jan 26, 2023 at 11:22 AM Michael Bien  wrote:


you check how the maven plugin is implemented and adopt it for gradle?

-mbien

On 26.01.23 17:13, Scott Palmer wrote:

I don't use Maven if I can help it.

But you misunderstand, I want to call Jackpot from my code to get it to
perform some refactoring from control of my program. Getting a list of
possible hints may happen later.
Or perhaps a more general use... What would I do if I wanted to write a
Gradle plugin to do the same as the Maven plugin? Assuming I know the
Gradle side, how do I call the Jackpot methods?

Regards,

Scott


On Thu, Jan 26, 2023 at 10:50 AM Michael Bien  wrote:


On 26.01.23 16:01, Scott Palmer wrote:

I wanted to experiment with Jackpot for a project I'm working on.  How
dependent on the NetBeans Platform is the Jackpot code at
https://github.com/apache/netbeans-jackpot30 ?
Is there such a thing as a jackpot library jar that does not depend on
NetBeans classes?
If I wanted to make a standalone tool to do certain transformations on a
Java code base where would I start?

Thanks for any help you can provide,

Scott


you should be able to use it from maven in your build:

  
org.apache.netbeans.modules.jackpot30
jackpot30-maven-plugin
  13.0
  
jackpot-settings.xml
true
  
  
  
  jackpot
  compile
  
  analyze
  
  
  
  


I use it mostly from within NetBeans itself for refactoring or
inspection tasks with the help of the ".hint" files.

I sometimes upload the inspections which I think are reusable or more
generic here:

https://github.com/mbien/jackpot-inspections

readme explains how to use hint files.

-mbien





-
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

Re: Jackpot

[Ernie Rael]

On 23/01/26 7:01 AM, Scott Palmer wrote:

I wanted to experiment with Jackpot for a project I'm working on.  How
dependent on the NetBeans Platform is the Jackpot code at
https://github.com/apache/netbeans-jackpot30 ?
Is there such a thing as a jackpot library jar that does not depend on
NetBeans classes?


Did you check out https://netbeans.apache.org/jackpot/

I vaguely recall a command line tool (could be hallucinating), but maybe 
the maven

plugin replaces that.

-ernie


If I wanted to make a standalone tool to do certain transformations on a
Java code base where would I start?

Thanks for any help you can provide,

Scott




-
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

Re: verification of plugin with update center

[Ernie Rael]

At plugins.netbeans.apache.org I didn't find "Contact us" or any way to 
appeal a "Verification Failed". In this case verification failed due to 
what I believe is a NetBeans bug.


I'm broadening "To:", including users@, hoping to catch someone who 
can/will handle/respond.


-ernie

On 23/01/20 9:28 AM, Ernie Rael wrote:

Just received:

Plugin: jVi Update Center JDK-11
NetBeans version: 17
Verification status: NOGO
Comments: On uninstall of the downloaded plugin 
(nbupdatecenter-jdk11-1.0.nbm), update center is not removed.


"update center not removed" has been a problem for over 10 years. My 
understanding has been that it's a NetBeans bug. Maybe I'm wrong. In 
May of 2011 I filed


   https://bz.apache.org/netbeans/show_bug.cgi?id=198359
   removed UC can not be added (re-added) by installing a module

I thought I filed a follow on issue specifically about the update 
center not getting removed when uninstalled, but don't find it.


There's some indication in the report that there's no API for cleaning 
NetBeans state to remove an update center. And I believe that there's 
an issue that the module can be uninstalled without getting 
notification. But I don't remember the details. I remember trying a 
variety of things, never got it to work.


If someone could provide some hints and/or API pointers, I'll take a 
look at fixing it.


In the meantime, is it possible to get the plugin approved while the 
problem is being addressed?


-ernie

PS. plugin verification before release, woohoo!




-
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

verification of plugin with update center

[Ernie Rael]

Just received:

Plugin: jVi Update Center JDK-11
NetBeans version: 17
Verification status: NOGO
Comments: On uninstall of the downloaded plugin (nbupdatecenter-jdk11-1.0.nbm), 
update center is not removed.

"update center not removed" has been a problem for over 10 years. My 
understanding has been that it's a NetBeans bug. Maybe I'm wrong. In May of 2011 I filed

   https://bz.apache.org/netbeans/show_bug.cgi?id=198359
   removed UC can not be added (re-added) by installing a module

I thought I filed a follow on issue specifically about the update center not 
getting removed when uninstalled, but don't find it.

There's some indication in the report that there's no API for cleaning NetBeans 
state to remove an update center. And I believe that there's an issue that the 
module can be uninstalled without getting notification. But I don't remember 
the details. I remember trying a variety of things, never got it to work.

If someone could provide some hints and/or API pointers, I'll take a look at 
fixing it.

In the meantime, is it possible to get the plugin approved while the problem is 
being addressed?

-ernie

PS. plugin verification before release, woohoo!

Re: About: Apache NetBeans 17 feature freeze

[Ernie Rael]

On 23/01/18 11:18 AM, Neil C Smith wrote:

On Wed, 18 Jan 2023, 18:42 Ernie Rael,  wrote:

Changed it to just a comment. I'm not sure how many people really use the
affected code without the window system.


And I commented, quoted warning from Frame.getFrames() javadoc.



If rebased on delivery and review completed it's a possible bug fix
for rc2,

Let see what happens... Rebasing is no problem, that's a convenience about
making changes in an area that's rarely touched.


Should just be changing the base in the PR UI as it was already open at
freeze.


Yep, particularly easy in this case.

If some reviewer says "go ahead for RC2", I'll rebase.

-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

Re: About: Apache NetBeans 17 feature freeze

[Ernie Rael]

On 23/01/18 9:59 AM, Neil C Smith wrote:

Looking at https://github.com/apache/netbeans/pull/5280 it had
approval from one of the four people requested to review.


This is somewhat of a grey area to me. I often see PRs merged where
some reviewers don't weigh in. In any event, the PR should have been
opened earlier in the cycle.


Looks like
some of the conversation still ongoing?

There's conversation about a different long outstanding issue that isn't
about this PR; it has to do with dialog placement. After the recent
discussion, I might know where the problem is (I can't reproduce it) but
need some input from someone who sees the problem. Something for
nb-18.

   I've only just looked at it,
but might have a request for change.

Cool. That livens things up and makes it more interesting.
Good thing nobody merged it.


If rebased on delivery and review completed it's a possible bug fix
for rc2,

Let see what happens... Rebasing is no problem, that's a convenience about
making changes in an area that's rarely touched.

but I'm not making that call.


(as a commenter/reviewer, seems you're putting on a different hat ;-) )

-ernie



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

Re: About: Apache NetBeans 17 feature freeze

[Ernie Rael]

On 23/01/18 8:40 AM, Neil C Smith wrote:

Any particular PR in mind?  Is it a candidate for RC2?


https://github.com/apache/netbeans/pull/5280

It hardly seems a candidate. Been around, easy workaround...

-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

Re: About: Apache NetBeans 17 feature freeze

[Ernie Rael]

you need
to bug people.

That's what I meant by politics

the activities associated with the governance of a country or other 
area, especially the debate or conflict among individuals or parties 
having or hoping to achieve [merge]


-ernie

On 23/01/18 8:40 AM, Neil C Smith wrote:

On Wed, 18 Jan 2023 at 16:28, Michael Bien  wrote:

no they won't get merged automatically.

quote from Neil's notice mail:
  > All open pull requests for NB17 will be pushed to NB18.

milestones are just a way to roughly organize PRs around deadlines.

Yes, this, no politics involved.  Quite the opposite!  I just used the
bulk edit tool to select all the open NB17 PRs and retarget them.  We
do this each time.  If we don't we end up having discussions that can
delay freeze for days or weeks, and causes knock on problems and
delays.

If it's not in master by freeze date, it's not in, unless a case is
made to merge to delivery for a later RC.  If you have concerns about
a particular PR not being merged and freeze is getting close, you need
to bug people.

Any particular PR in mind?  Is it a candidate for RC2?

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

Re: About: Apache NetBeans 17 feature freeze

[Ernie Rael]

On 23/01/18 8:23 AM, Michael Bien wrote:

no they won't get merged automatically.

quote from Neil's notice mail:
> All open pull requests for NB17 will be pushed to NB18.


I've read that, and I read it again before sending the message.
Guess I read it as

   "All unapproved pull requests..."

And I'm usually so literal...

The universe conspires so I'll run a custom version of NB.

-ernie



milestones are just a way to roughly organize PRs around deadlines.

-mbien


On 18.01.23 16:47, Ernie Rael wrote:
I would have thought that any approved PR with NB-17 milestone gets 
merged. Guess not.


I didn't realize there was more politics after that.

-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






-
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

About: Apache NetBeans 17 feature freeze

[Ernie Rael]

I would have thought that any approved PR with NB-17 milestone gets 
merged. Guess not.


I didn't realize there was more politics after that.

-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

Re: nb16 source verification

[Ernie Rael]

On 23/01/11 2:05 AM, Neil C Smith wrote:

Unless we've ended up in mid-2025 without me noticing, could you try
importing a recent KEYS file and check again?


Was getting expired, imported KEYS, got rid of expired.

-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

Re: nb16 source verification

[Ernie Rael]

On 23/01/10 11:26 PM, Svata Dedic wrote:

Hi,

downloaded right now - SHA512 seems correct


Thanks for checking.


(did you checked by sha512, not sha1 :) ?)


Even better than that (probably 'cause I couldn't find sha1), on the 
main download page I did right context on netbeans-16-source.zip "Save 
Link As..." and then after my first attempt to verify failed, /*instead 
of examining*//*the downloaded "zip" file*/ I tried the other 
verification technique which also failed.


-ernie

, and even the GPG signature is OK - but Neil's signing key expired 
just today (signed on 21. Nov 2022)


Maybe the release should be signed next time by a key which is at 
least 6 months before expiration or something like that, so it 
survives to the next release.


-S.

On 11. 01. 23 3:37, Ernie Rael wrote:

Just downloaded source from https://netbeans.apache.org/download/nb16/

I'm getting verification failures with both sha and gpg.

I have to figure it out every time, could be cockpit error; but this 
seems like a real failure.


-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






-
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

nb16 source verification

[Ernie Rael]

Just downloaded source from https://netbeans.apache.org/download/nb16/

I'm getting verification failures with both sha and gpg.

I have to figure it out every time, could be cockpit error; but this 
seems like a real failure.


-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

Re: Lets talk about JDK 8 (new year edition)

[Ernie Rael]

On 23/01/10 6:16 AM, Michael Bien wrote:



Given that NB doesn't really support running on JDK 11 since a while I 
would simply opt for 2) and merge.




Typo? JDK-11 --> JDK-8

-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

updating to 16-u1

[Ernie Rael]

Just updated to the final bits; and wondering about a /backwards seeming 
dependency/. I started with the first check release of 16-u1, so this 
normally wouldn't be seen.


Using plugin manager, uninstall everything with "gradle".  Still had

   org.netbeans.modules.gradle/2 [2.29.1
   Netbeans/netbeans-TLP/netbeans/release160-14-on-20221215]

when starting NetBeans. Uninstalled Groovy and finally 
"...modules.gradle" was uninstalled. *This seems wrong.* Does Groovy 
depend on Gradle?


-ernie

PS. to be complete

Then activated Gradle/Groovy stuff (none of the patch 16-u1 update 
centers were enabled). Guess gradle.java has that last minute fix 
(1223). (More stuff was installed than actually needed since I kept 
trying to uninstall modules.gradle)


Now a boot gives. The curious numbering has been previously addressed.

    org.netbeans.modules.gradle/2 [2.29.1 
Netbeans/netbeans-TLP/netbeans/release160-14-on-20221215]
    org.netbeans.modules.gradle.java [1.20.1.1 
Netbeans/netbeans-TLP/netbeans/release160-16-on-20221223]
    org.netbeans.modules.gradle.test [1.14 
Netbeans/netbeans-TLP/netbeans/release160-11-on-20221119]
    org.netbeans.modules.gradle.spring [1.14 
Netbeans/netbeans-TLP/netbeans/release160-11-on-20221119]
    org.netbeans.modules.gradle.persistence [1.14 
Netbeans/netbeans-TLP/netbeans/release160-11-on-20221119]
    org.netbeans.modules.gradle.editor [1.0 
Netbeans/netbeans-TLP/netbeans/release160-11-on-20221119]
    org.netbeans.modules.gradle.dists [1.6 
Netbeans/netbeans-TLP/netbeans/release160-11-on-20221119]
    org.netbeans.modules.gradle.java.coverage [1.11 
Netbeans/netbeans-TLP/netbeans/release160-11-on-20221119]
    org.netbeans.modules.gradle.kit [1.14 
16-321935444b183aea1c4ff255d8d2ab8d50c60606]
    org.netbeans.modules.gradle.groovy [1.7 
Netbeans/netbeans-TLP/netbeans/release160-11-on-20221119]

Re: bits.netbeans.org doc search problem

[Ernie Rael]

Under javadoc for ActionRegistration annotation, in the verbose doc for 
lazy, the Presenter.* links work.


-ernie

On 23/01/05 2:29 PM, Ernie Rael wrote:

Came across another unexpected "Oracle Transition".

1. Goto PopupAction
2. Click on something under "Nested Class Summary".

Can't find Presenter either. Not sure how widespread this nested class 
issue is.


-ernie

On 23/01/04 5:25 PM, Ernie Rael wrote:
Clicking on "ContextAwareAction", through following steps ends up at 
https://netbeans.apache.org/about/oracle-transition.html


1. bits.netbeans.org - click on "Apache NetBeans dev"
2. search for actionreg - click on "ActionRegistration"
3. just above the "since 7.26" - click on "context aware action"
   it goes to method returning ContextAwareAction
4. Click on "ContextAwareAction"
   is:
https://bits.netbeans.org/dev/javadoc/org-openide-util/org/openide/util/ContextAwareAction.html?is-external=true 


   sb:
https://bits.netbeans.org/dev/javadoc/org-openide-util-ui/org/openide/util/ContextAwareAction.html 



Observe: end up at transition page.

Looks like: "org-openide-util" should be "org-openide-util-ui

I took a look at Actions.java, but IDK...

-ernie

I replied, rather than a new message, because the original message 
was about the same interface and I can be easily amused.



On 22/09/28 5:35 AM, Eric Barboni wrote:

Nice finding
Seems that regexp is not parsing the interface 
linehttps://github.com/apache/netbeans/blob/b7cabc0cf7417fd494cf3f84cd6169bc4eadb75f/nbbuild/antsrc/org/netbeans/nbbuild/JavadocIndex.java#L115


A typical interface line looks like:
title="interface in org.openide">class="interfaceName">ErrorManager.Annotation


I try to edit the regexp but I did not succed to swallow the span 
element.


Start thinking using jsoup to do the job  (but that's because I'm 
not goot at regexp)


Regards
Eric

-Message d'origine-
De : Ernie Rael  Envoyé : samedi 24 septembre 
2022 19:05

À :dev@netbeans.apache.org
Objet : bits.netbeans.org doc search problem

I wanted to take a look at ContextAwareAction. But entering this in 
the search box has no results. Found it in the source, searched for 
imageutil from the same package, clicked AllClasses, found it there.


I think this has been an issue for a long time. Might have to do 
with "Interface".


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





-
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

Re: bits.netbeans.org doc search problem

[Ernie Rael]

Came across another unexpected "Oracle Transition".

1. Goto PopupAction
2. Click on something under "Nested Class Summary".

Can't find Presenter either. Not sure how widespread this nested class 
issue is.


-ernie

On 23/01/04 5:25 PM, Ernie Rael wrote:
Clicking on "ContextAwareAction", through following steps ends up at 
https://netbeans.apache.org/about/oracle-transition.html


1. bits.netbeans.org - click on "Apache NetBeans dev"
2. search for actionreg - click on "ActionRegistration"
3. just above the "since 7.26" - click on "context aware action"
   it goes to method returning ContextAwareAction
4. Click on "ContextAwareAction"
   is:
https://bits.netbeans.org/dev/javadoc/org-openide-util/org/openide/util/ContextAwareAction.html?is-external=true
   sb:
https://bits.netbeans.org/dev/javadoc/org-openide-util-ui/org/openide/util/ContextAwareAction.html

Observe: end up at transition page.

Looks like: "org-openide-util" should be "org-openide-util-ui

I took a look at Actions.java, but IDK...

-ernie

I replied, rather than a new message, because the original message was 
about the same interface and I can be easily amused.



On 22/09/28 5:35 AM, Eric Barboni wrote:

Nice finding
Seems that regexp is not parsing the interface 
linehttps://github.com/apache/netbeans/blob/b7cabc0cf7417fd494cf3f84cd6169bc4eadb75f/nbbuild/antsrc/org/netbeans/nbbuild/JavadocIndex.java#L115


A typical interface line looks like:
title="interface in org.openide">class="interfaceName">ErrorManager.Annotation


I try to edit the regexp but I did not succed to swallow the span 
element.


Start thinking using jsoup to do the job  (but that's  because I'm 
not goot at regexp)


Regards
Eric

-Message d'origine-
De : Ernie Rael  Envoyé : samedi 24 septembre 
2022 19:05

À :dev@netbeans.apache.org
Objet : bits.netbeans.org doc search problem

I wanted to take a look at ContextAwareAction. But entering this in 
the search box has no results. Found it in the source, searched for 
imageutil from the same package, clicked AllClasses, found it there.


I think this has been an issue for a long time. Might have to do with 
"Interface".


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





-
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

Re: bits.netbeans.org doc search problem

[Ernie Rael]

Clicking on "ContextAwareAction", through following steps ends up at 
https://netbeans.apache.org/about/oracle-transition.html


1. bits.netbeans.org - click on "Apache NetBeans dev"
2. search for actionreg - click on "ActionRegistration"
3. just above the "since 7.26" - click on "context aware action"
   it goes to method returning ContextAwareAction
4. Click on "ContextAwareAction"
   is:
   
https://bits.netbeans.org/dev/javadoc/org-openide-util/org/openide/util/ContextAwareAction.html?is-external=true
   sb:
   
https://bits.netbeans.org/dev/javadoc/org-openide-util-ui/org/openide/util/ContextAwareAction.html

Observe: end up at transition page.

Looks like: "org-openide-util" should be "org-openide-util-ui

I took a look at Actions.java, but IDK...

-ernie

I replied, rather than a new message, because the original message was 
about the same interface and I can be easily amused.



On 22/09/28 5:35 AM, Eric Barboni wrote:

Nice finding
Seems that regexp is not parsing the interface 
linehttps://github.com/apache/netbeans/blob/b7cabc0cf7417fd494cf3f84cd6169bc4eadb75f/nbbuild/antsrc/org/netbeans/nbbuild/JavadocIndex.java#L115

A typical interface line looks like:
ErrorManager.Annotation

I try to edit the regexp but I did not succed to swallow the span element.

Start thinking using jsoup to do the job  (but that's  because I'm not goot at 
regexp)

Regards
Eric

-Message d'origine-
De : Ernie Rael  
Envoyé : samedi 24 septembre 2022 19:05

À :dev@netbeans.apache.org
Objet : bits.netbeans.org doc search problem

I wanted to take a look at ContextAwareAction. But entering this in the search 
box has no results. Found it in the source, searched for imageutil from the 
same package, clicked AllClasses, found it there.

I think this has been an issue for a long time. Might have to do with 
"Interface".

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





-
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

Re: JUnit 5 Generated Tests Warning/Error

[Ernie Rael]

I ran into this, and didn't find a simple solution.

   https://lists.apache.org/thread/lto47nxlhj2r6fbk16l93qs3vy9g2rtg
   https://lists.apache.org/thread/tk263h5xco04kwpcfrt55p0lnlmokb0m

I think you need to hookup a new test runner. I didn't pursue it because 
ant is a dead end.


My solution, considering that ant is essentially deprecated in NetBeans, 
was to convert projects to Maven or Gradle.


-ernie

On 22/12/31 8:08 AM, Eric Bresie wrote:

1.
   While trying to work on janitor issue in Netbeans (an "ant project"),
   I create new file (Unit Test) for the Janitor class (by default
it appears
   to generate JUnit 5 based) but noticed when doing so and
attempting to run
   the test it fails to run with the below warnings/errors (see end
of email).
2. I think this is related to an issue previously identified in JIRA
3. NETBEANS-5371The
generated JUnit 5 code from the Ant project cannot be run]


If I read it correctly, from the thread it seemed to imply possible
workaround of either (1) using JUnit 4, or (2) using gradle/maven to deal
with the dependencies issues.  Given netbeans is still ant based (any plans
to migrate Netbeans from Ant to Maven or Gradle in the future?), not sure
if migrating to gradle/maven is fully an option.

The "JUnit5" was added under the "Unit Test Libraries" in the process, so
maybe there is something going on in that context.

I find some related unit tests (1), (2) issues but nothing beyond that.
Has anyone else seen similar problems and knows of an existing issues or
should I migrate the original NETBEANS-5371 JIRA ticket into the GitHub
issue?

I am using Netbeans 16 with Java 11 on Windows 11.

Eric Bresie
ebre...@gmail.com

References

1.https://github.com/apache/netbeans/issues/4576  Create/Update Tests
constantly introduces incorrect JUnit dependency version
2.https://github.com/apache/netbeans/issues/4904  Many tests fail on JDK
11


Log Exert:

projectized-common.do-unit-test-build:
Compiling 1 source file to
C:\git\netbeans\platform\janitor\build\test\unit\classes
Ignoring source, target and bootclasspath as release has been set
C:\git\netbeans\nbbuild\netbeans\platform\modules\ext\junit-jupiter-api-5.6.0.jar(/org/junit/jupiter/api/AfterEach.class):
warning: Cannot find annotation method 'status()' in type 'API': class file
for org.apiguardian.api.API not found
warning: unknown enum constant Status.STABLE
   reason: class file for org.apiguardian.api.API$Status not found
C:\git\netbeans\nbbuild\netbeans\platform\modules\ext\junit-jupiter-api-5.6.0.jar(/org/junit/jupiter/api/AfterEach.class):
warning: Cannot find annotation method 'since()' in type 'API'
C:\git\netbeans\nbbuild\netbeans\platform\modules\ext\junit-jupiter-api-5.6.0.jar(/org/junit/jupiter/api/AfterAll.class):
warning: Cannot find annotation method 'status()' in type 'API'
warning: unknown enum constant Status.STABLE
C:\git\netbeans\nbbuild\netbeans\platform\modules\ext\junit-jupiter-api-5.6.0.jar(/org/junit/jupiter/api/AfterAll.class):
warning: Cannot find annotation method 'since()' in type 'API'
C:\git\netbeans\nbbuild\netbeans\platform\modules\ext\junit-jupiter-api-5.6.0.jar(/org/junit/jupiter/api/BeforeEach.class):
warning: Cannot find annotation method 'status()' in type 'API'
warning: unknown enum constant Status.STABLE
C:\git\netbeans\nbbuild\netbeans\platform\modules\ext\junit-jupiter-api-5.6.0.jar(/org/junit/jupiter/api/BeforeEach.class):
warning: Cannot find annotation method 'since()' in type 'API'
C:\git\netbeans\nbbuild\netbeans\platform\modules\ext\junit-jupiter-api-5.6.0.jar(/org/junit/jupiter/api/BeforeAll.class):
warning: Cannot find annotation method 'status()' in type 'API'
warning: unknown enum constant Status.STABLE
C:\git\netbeans\nbbuild\netbeans\platform\modules\ext\junit-jupiter-api-5.6.0.jar(/org/junit/jupiter/api/BeforeAll.class):
warning: Cannot find annotation method 'since()' in type 'API'
C:\git\netbeans\nbbuild\netbeans\platform\modules\ext\junit-jupiter-api-5.6.0.jar(/org/junit/jupiter/api/Test.class):
warning: Cannot find annotation method 'status()' in type 'API'
warning: unknown enum constant Status.STABLE
C:\git\netbeans\nbbuild\netbeans\platform\modules\ext\junit-jupiter-api-5.6.0.jar(/org/junit/jupiter/api/Test.class):
warning: Cannot find annotation method 'since()' in type 'API'
C:\git\netbeans\nbbuild\netbeans\platform\modules\ext\junit-jupiter-api-5.6.0.jar(/org/junit/jupiter/api/Assertions.class):
warning: Cannot find annotation method 'status()' in type 'API'
warning: unknown enum constant Status.STABLE
C:\git\netbeans\nbbuild\netbeans\platform\modules\ext\junit-jupiter-api-5.6.0.jar(/org/junit/jupiter/api/Assertions.class):
warning: Cannot find annotation method 'since()' in type 'API'
C:\git\netbeans\nbbuild\netbeans\platform\modules\ext\junit-jupiter-api-5.6.0.jar(/org/junit/jupiter/api/Assertions.class):
warning: Cannot find annotation method 

"Navigate > GoToDeclaration" fails if target is in gradle project

[Ernie Rael]

I've just opened this issue

   https://github.com/apache/netbeans/issues/5120

It has lots of info gathered at the point of failure. But I suspect the 
problem comes from things done at project open.


I could compare some things between maven project open and gradle 
project open if that makes sense.


Any pointers to where those things are in the source code?

-ernie

Re: [External] : RE: [DISCUSSION] Gradle Patch Release for NetBeans 16

[Ernie Rael]

On 22/12/15 9:34 AM, László Kishalmi wrote:

Thanks for your understanding!

Went ahead and merged the delivery to the release160 branch. The update can
be tested by adding the following update center URL:

https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/release160/14/artifact/dist/netbeans/nbms/updates.xml.gz


Still running NetBeans on JDK-11
Inalled update with plugin manager
    Once it is installed, there doesn't seem to be a way to tell from 
the plugin

    manager that I'm using the new stuff, but
    org.netbeans.modules.gradle/2 [2.29.1 
Netbeans/netbeans-TLP/netbeans/release160-14-on-20221215]
    org.netbeans.modules.gradle.java [1.20.1.1 
Netbeans/netbeans-TLP/netbeans/release160-14-on-20221215]


Opened gradle 6.1.1 project, built it
Opened gradle 6.8.3 project, built it

Tried the compose project,
    [#4865] Register JDPA and Java Compiler Output on Project level #4984
No change, still stuck waiting for debugger, manual attach OK.

Restarted NetBeans on JDK-17
Repeated everything and then some. Work the same.

Looks like I can now run NetBeans on JDK-17 and run gradle projects
that require JDK-8 or JDK-11. (and probably many combinations).

Thanks a lot.
-ernie

BTW, it would be nice if the gradle version of the project was display
somewhere in the project's properties.



On 12/13/22 07:37, Martin Balin wrote:

Hello,
Most of the fixes there are related to VSNetBeans, although related to
Gradle or projects infrastructure. I understand your intention was
about Gradle update itself to the latest version. If listed PRs are
too much then these can wait and I will do VSNetBeans 16.0.301 in
January. Not making 16u1 too big, no problem.

Martin


On 12. 12. 2022, at 23:42, Laszlo Kishalmi 
 wrote:

Dear all,

It seems my request went a bit too well, for my like. There are a few
enhancements marked, which I think would be better to leave for NB17.
(https://github.com/apache/netbeans/pulls?q=is%3Apr+is%3Aclosed+label%3A16u1

)

I've planned NB16u1 just to iron out the wrinkles in the Gradle
support, release it quick and distribute that an an NBM. I hope you
understand and don't mind, I'd not include those enhancements for now.
It's my fault not communicating this clear enough, so I give some time
and hear your voice in that. I'm sorry.

Otherwise the delivery branch is almost ready (the version bump is missing).
https://github.com/apache/netbeans/pulls?q=is%3Apr+milestone%3ANB16u1+is%3Aclosed




On 12/5/22 19:53, Laszlo Kishalmi wrote:

Well,

I'd like to do this ASAP, if my time allows, I'd kick off the vote
later this week.

We are probably ready wit the PR-s on master. I'd reuse the delivery
branch to collect the addendum to NB16, then will merge at once in
release160.

Since the milestone is NB16u1, let's mark your the wished PR-s with
"16u1" label.

I'm going to create cherry-picked PRs from those, and remove the label
when the PR is ready for NB16u1 milestone.

On 12/1/22 10:53, Martin Balin wrote:

Hi,
Any date in mind for this release? Lazslo, release before Christmas
break or after?
I propose to label PRs and Issues going to this 16.0.1patch release
with “16p1” label?
Martin



On 1. 12. 2022, at 17:21, Eric Barboni 
 wrote:

It will keep jenkins busy and trigger a build per commit and do all
release stack.
Only if a release date for release160 is set in the json, jenkins will
do apidoc only.


Using delivery may be more Jenkins friendly but I don't think it's a human :p.

Eric


-Message d'origine-
De : Neil C Smith  
Envoyé : jeudi 1 décembre 2022 14:52
À : dev@netbeans.apache.org
Objet : Re: [DISCUSSION] Gradle Patch Release for NetBeans 16

On Mon, 28 Nov 2022 at 15:55, Neil C Smith 
 wrote:

On Mon, 28 Nov 2022 at 15:43, László Kishalmi
  wrote:

release161 branch has been removed, PR-s have been re-targeted to
release160.

Great, thanks!  I'm just waiting on votes for rest of additional
binaries to start and I'll close the main vote.  Want to make sure
everything is OK before we merge anything else into the branch.

OK, everything done that needs to be done, so release160 can be
considered open again for merging.

However, I wonder whether we should have a transient branch like
delivery (now deleted) for merging into?  Merges into release***
branches trigger a lot of things.  Eric?

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,

Re: [DISCUSSION] Gradle Patch Release for NetBeans 16

[Ernie Rael]

I'm salivating at the thought of running NetBeans on a recent jdk and 
work on old gradle version projects.


For testing, is it possible and simple to have a nb16u1 update center, 
which I can manually add locally?


-ernie

On 22/11/27 3:25 PM, Laszlo Kishalmi wrote:

Dear all,

This is a kind of notice / discussion.

Frequent visitors of GitHub might notice, that I've created a new 
Milestone NB16u1. There are a handful of important fixes in our Gradle 
Support that would improve the Gradle/JDK compatibility. I think those 
are important, as some of them are fixing regressions.


It's a bit unfortunate that these fixes have arrived late of our NB16 
release phase. They could be annoying, but I would not stop the 
release train on them. So I've decided to step up and create an 
unusual patch release for NB16. I would like it to keep this update 
release low profile, so we could deliver it ASAP.


Some things to know:

 * Created a branch for this named: release161
 * The milestone is NB16u1
 * I'm going to create PR-s against the new branch, by cherry-picking
   PR-s landed on master.
 * Once done, there would be (hopefully) one vote round on the whole
   source release zip.
 * NB16u1 will be delivered trough our Update Center. (Of course, the
   zip source distribution would be available, but the convenience
   binary would be just the nbm package)
 * I would steer this small update release as an RM, if there would be
   no objection.

Current PR candidates to be included in NB16u1:

 * https://github.com/apache/netbeans/pull/5014
 * https://github.com/apache/netbeans/pull/4995
 * https://github.com/apache/netbeans/pull/4984
 * https://github.com/apache/netbeans/pull/4985

Also I hope that there would be a fix for this as well:

https://github.com/apache/netbeans/issues/5015


As usual feedback is welcome!


--

Laszlo Kishalmi




-
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

Re: [PLUGINS][RELEASES] Preparation for NetBeans 16 plugins

[Ernie Rael]

On 22/11/20 2:30 AM, Neil C Smith wrote:

On Fri, 28 Oct 2022 at 10:04, Neil C Smith  wrote:

I totally agree with the points raised there.  We haven't had a
vaguely useful plugin catalog since NetBeans 13.  The plugin catalog
for 16 is currently empty, so we're missing possibilities for testing.

IMO an empty plugin catalog is a reason to delay the release of
NetBeans 16 until it's ready.

So, we made a decision to hold fire on the release vote on this.  The
plugin catalog does now have some plugins in it, and at least enough
to test setup.


What is preventing previously verified plugins, with no known problems, 
from being put into a verified state for the NB16 catalog?


Admittedly, I'd be uncomfortable if there wasn't an agreement to remove 
verification if problems are confirmed.


-ernie



I triggered a release build yesterday which is complete.  I can
proceed with signing and uploading for voting in the next few days
unless anyone thinks we should wait longer?  I don't think there are
any other issues holding us up now?  Hopefully we can still see some
more plugins verified in the week or so before we're ready to
announce.

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

Re: Sending NB16 notice to plugin authors (was: Re: [PLUGINS][RELEASES] Preparation for NetBeans 16 plugins)

[Ernie Rael]

Yeah, all true.

A release note on how easy it is to access the NB13 catalog might be 
useful. I'd guess almost all the plugins still work. But maybe best to 
just ignore it until there's a better story.


There were several tweaks to the current portal that have been mentioned 
over several months, which seemed like they might offer a workable 
solution without an entire replacement.


One thing I've long wondered is how the plugin portal relates to Apache 
NetBeans. I don't recall ever having seen a VOTE relating to the portal. 
(But I could easily have missed it; especially if it was long ago). Of 
course there has to be something to vote on, not to mention the manpower 
that puts the voting candidate together.


-ernie

On 22/11/16 9:26 AM, Neil C Smith wrote:

On Wed, 16 Nov 2022 at 16:35, Ernie Rael  wrote:

Is there an obstacle/problem preventing NB13's catalog being used for NB16?

Technically, no, and I put that in place temporarily for the NB 14
release candidates.  The problem is, the plugin centre was never ready
during NB14's lifetime, and that temporary change is still there!
https://github.com/apache/netbeans-website/blob/master/netbeans.apache.org/src/content/.htaccess#L31

It just opens up a whole bunch of other issues, including going back
on what was previously agreed upon, making shipping plugin updates a
problem, and generally not being transparent to users about what
they're receiving.  All of which causes additional work for us too -
eg. out of date plugins leading to bug reports.

>From a release perspective, we have certain fixed dates where we need
things in place in the plugin portal.  If the current portal and
process cannot meet those requirements, then we need to replace it.
But realistically that's not going to happen until NB17 at the
earliest.

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

Re: Sending NB16 notice to plugin authors (was: Re: [PLUGINS][RELEASES] Preparation for NetBeans 16 plugins)

[Ernie Rael]

On 22/11/16 2:48 AM, Neil C Smith wrote:

On Wed, 16 Nov 2022 at 01:25, Ernie Rael  wrote:

Guess automatic re-verification for existing plugins didn't make it for
NB-16.

Guess not! :-\  Although as there's only 3 plugins verified in NB15
still, that might not have led to much.
I was optimistically supposing that the inaugural re-verification would 
include NB13's catalog


Lack of a plugins catalog ready for 16 is currently the only thing
holding up the release vote, so hopefully we'll see some verifications
soon.


Is there an obstacle/problem preventing NB13's catalog being used for NB16?

-ernie



*If* we're keeping the existing plugin portal for NB17, we need to
make sure verification is ready to go from feature freeze.  Ideally,
IMO, we'd be pointing daily builds at a catalog for 17 already.

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

Re: Sending NB16 notice to plugin authors (was: Re: [PLUGINS][RELEASES] Preparation for NetBeans 16 plugins)

[Ernie Rael]

On 22/11/15 4:56 PM, Junichi Yamamoto wrote:

Hi,

I haven't received it yet...

I haven't seen it either.

Did go to the portal and saw NB-16, so I requested verification.

Guess automatic re-verification for existing plugins didn't make it for 
NB-16.


-ernie

PS. apologies if anyone sees this twice (shaking out a new email server)


I've also checked a spam folder but there is no message for it.

Thanks,
Junichi

On Wed, Nov 16, 2022 at 3:38 AM Matthias Bläsing
 wrote:

Hi,

I'll send the message to the plugin portal authors now.

Greetings

Matthias

Am Dienstag, dem 01.11.2022 um 10:19 +0100 schrieb Jiří Kovalský:

Hi Matthias,

I agree that it's not a good idea to separate these notification e-
mails depending on primary/secondary authors. We certainly want to
inform all authors. As for the text it could be something like the
following:
___
Subject: Check your plugin with the new Apache NetBeans version!

Hey %1$s,

have you heard of the new Apache NetBeans version on the horizon?
Yes, the NetBeans community is going to release version %4$s soon! In
order to have your great plugin(s) available on the NetBeans Update
Center also for users of the new version please consider testing the
plugin(s) with the latest RC build and possibly submit new
verification request(s) via the Plugin Portal website.
Your plugins:
%3$s
Direct link to the list of your plugins:
%2$s/plugin/list
Thanks for your contribution and ongoing support!
Apache NetBeans Plugin Portal Administrator
P.S.: Please contact dev@netbeans.apache.org mailing list for any
questions.
___

I hope it makes sense. Please note I have introduced a new %4$s
variable which would contain the latest NetBeans version - perhaps
identified by the greatest ID. Also please consider expanding the
value of %2$s variable to point to the My Plugins page instead of the
homepage.

-Jirka

Dne út 1. 11. 2022 8:10 uživatel Matthias Bläsing
 napsal:

[Resend directly, as I'm not sure you monitor
dev@netbeans.apache.org]

Hi again,

I merged the update and put it into production. A preview message
was
correctly delivered to my mailbox.

@Jiří: when you tested you already seemed to have some message in
mind.
Would you mind sending it? I suggest to not limit the recipients
and
send it to all authors. The numbers are not that high, that we
really
need the distinction.

Thank you

Matthias


Am Freitag, dem 21.10.2022 um 23:21 +0200 schrieb Matthias Bläsing:

Hi,

I implemented an e-mail sending option for the plugin portal.

This

should allow us to inform current authors of the plugin portal

about

new NetBeans versions being available for verification.

@Jiří: You are still listed as verifier in my test portal, so you

could

have a look at a working implementation:

https://doppel-helix.eu/pp3/

The PR for this with a Screenshot can be found here:

https://github.com/apache/netbeans-tools/pull/53

I'd like to get an opinion on this.

Greetings

Matthias



Am Mittwoch, dem 19.10.2022 um 13:15 +0100 schrieb Neil C Smith:

Hi,

Just setting up the infrastructure for NetBeans 16 in advance

of

16-rc1.  Please can we have an endpoint for NetBeans 16 plugins

as

soon as possible?

Can we, perhaps, start with automatically verifying everything

from

NB15 this time too?  It would be much better for testing

release

candidates.

Thanks,

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





---
--
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






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

For further information 

Re: Sending NB16 notice to plugin authors (was: Re: [PLUGINS][RELEASES] Preparation for NetBeans 16 plugins)

[Ernie Rael]

On 22/11/15 4:56 PM, Junichi Yamamoto wrote:

Hi,

I haven't received it yet...


I haven't seen it either.

Did go to the portal and saw NB-16, so I requested verification.

Guess automatic re-verification for existing plugins didn't make it for 
NB-16.


-ernie


I've also checked a spam folder but there is no message for it.

Thanks,
Junichi

On Wed, Nov 16, 2022 at 3:38 AM Matthias Bläsing
 wrote:

Hi,

I'll send the message to the plugin portal authors now.

Greetings

Matthias

Am Dienstag, dem 01.11.2022 um 10:19 +0100 schrieb Jiří Kovalský:

Hi Matthias,

I agree that it's not a good idea to separate these notification e-
mails depending on primary/secondary authors. We certainly want to
inform all authors. As for the text it could be something like the
following:
___
Subject: Check your plugin with the new Apache NetBeans version!

Hey %1$s,

have you heard of the new Apache NetBeans version on the horizon?
Yes, the NetBeans community is going to release version %4$s soon! In
order to have your great plugin(s) available on the NetBeans Update
Center also for users of the new version please consider testing the
plugin(s) with the latest RC build and possibly submit new
verification request(s) via the Plugin Portal website.
Your plugins:
%3$s
Direct link to the list of your plugins:
%2$s/plugin/list
Thanks for your contribution and ongoing support!
Apache NetBeans Plugin Portal Administrator
P.S.: Please contact dev@netbeans.apache.org mailing list for any
questions.
___

I hope it makes sense. Please note I have introduced a new %4$s
variable which would contain the latest NetBeans version - perhaps
identified by the greatest ID. Also please consider expanding the
value of %2$s variable to point to the My Plugins page instead of the
homepage.

-Jirka

Dne út 1. 11. 2022 8:10 uživatel Matthias Bläsing
 napsal:

[Resend directly, as I'm not sure you monitor
dev@netbeans.apache.org]

Hi again,

I merged the update and put it into production. A preview message
was
correctly delivered to my mailbox.

@Jiří: when you tested you already seemed to have some message in
mind.
Would you mind sending it? I suggest to not limit the recipients
and
send it to all authors. The numbers are not that high, that we
really
need the distinction.

Thank you

Matthias


Am Freitag, dem 21.10.2022 um 23:21 +0200 schrieb Matthias Bläsing:

Hi,

I implemented an e-mail sending option for the plugin portal.

This

should allow us to inform current authors of the plugin portal

about

new NetBeans versions being available for verification.

@Jiří: You are still listed as verifier in my test portal, so you

could

have a look at a working implementation:

https://doppel-helix.eu/pp3/

The PR for this with a Screenshot can be found here:

https://github.com/apache/netbeans-tools/pull/53

I'd like to get an opinion on this.

Greetings

Matthias



Am Mittwoch, dem 19.10.2022 um 13:15 +0100 schrieb Neil C Smith:

Hi,

Just setting up the infrastructure for NetBeans 16 in advance

of

16-rc1.  Please can we have an endpoint for NetBeans 16 plugins

as

soon as possible?

Can we, perhaps, start with automatically verifying everything

from

NB15 this time too?  It would be much better for testing

release

candidates.

Thanks,

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





---
--
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






-
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:

Re: NB RC-3 Gradle Issues

[Ernie Rael]

On 22/11/05 9:09 PM, Scott Palmer wrote:

Somewhat related to the issue described already…

My project wants to use JDK 19 features.
Gradle 7.5.1 wants to run on something older, e.g. JDK 17.


I had a similar issue, the IDE used the wrong source version. The 
problem was fixed, in my case, by explicitly setting the --source or 
--release in compiler args and a PR that uses compiler args to override. See


   https://github.com/apache/netbeans/issues/4704

and the associated patch. Perhaps there's a solution for you in there.

-ernie


I use a java toolchain specification in the Gradle script so Gradle will 
happily build with JDK 19 while it runs the Gradle daemon on JDK 17.

However, for NetBeans to allow JDK 19 features in the editor, I need to tell it 
in the project settings…

In Project Properties, the “Sources” section has a Source/Binary format field that 
is read-only.  I have to change under Build->Compile the JDK.

It then tries to set JAVA_HOME to JDK19 when invoking Gradle builds and Gradle 
7.5.1 is not happy.

Is it possible for the Gradle plugin to figure out the Java toolchain version 
that Gradle will use in order to set the source compatibility level of the 
editor?


Scott



On Nov 5, 2022, at 6:12 AM, Svata Dedic  wrote:

It would greatly help to also supply a minimal build.gradle that triggers the 
failure: I've tried to load several of my gradle samples using JDK19 seemingly 
without any issues.

The printed type/method seems as my changes to gradle loading are the culprit: 
based on the sample I'll be probably able to wrap the internal API calls into 
better guards.

Please run the IDE with the following on the commandline:

-J-Dorg.netbeans.modules.gradle.loaders.LegacyProjectLoader.level=400

that should print (a ton of !) additional gradle-nb communication to the log, 
possibly including the real exception thrown in the daemon.

-Svata

On 05. 11. 22 8:26, Laszlo Kishalmi wrote:

Reverting back to Java 17 or 18 as IDE runtime would be a solution. Though it 
seems this time we reached too deep into the Gradle internals an got burned. 
That means you've found a real bug. Would you report it on github? We might be 
able to do an RC4 for NB-16. Though it is possible that it would be NB-17.

[...]

On 11/4/22 21:04, Scott Palmer wrote:

When I edited netbeans.conf to force NB to run with JDK 17, my project that 
uses Gradle 7.6-rc-1 via the Gradle wrapper and JDK 19 (via Gradle Java 
Toolchain support) still claimed that it would not load.  The only error 
message shown is:

'boolean 
org.gradle.api.internal.provider.ValueSupplier$ExecutionTimeVaue.isFixedValue()’

I had the Gradle settings in NB set to use that fixed path for Gradle and 
ignore my wrapper settings.  It is the path to my Gradle 7.6-RC-1 install, 
though I don’t need it to be 7.6 to run the Gradle script..



-
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

dialogs with null parents and other misplaced dialogs

[Ernie Rael]

In NB-16-rc, there's a PR: "Dialog parent should not be null" 
https://github.com/apache/netbeans/pull/4739


Any test/feedback of changed dialogs' behavior, and observations for 
dialogs that are misplaced, appreciated.


Before this change, these dialogs would show up in the center of Java's 
default screen, with this change they typically show up over the 
activated button (mouse click). null should never be used as a dialog 
parent in NetBeans because in a multi-screen environment it often goes 
to the wrong spot. This PR cleans up a subset of the problems, 
specifically with JOptionPane/JFileChooser. Find some of the dialogs at


- Tools > Templates > Add
- Profile > InsertProfilingPoint > Next > Browse
- Options > Editor > Spellchecker > Add > Browse
- get to a file that has attachSources button, click it > AddZip/Folder
  for example, navigate to a library, click on a class file

I still occasionally see dialogs that show up on the default screen. 
They should either be on/around NetBeans' main window or some active 
window. Often times can't replicate the problem.


I've opened a discussion, Dialog placement and misplaced dialog observations
https://github.com/apache/netbeans/discussions/4887, to collect 
information on dialogs that are misplaced or aren't placed very well. 
I'm hoping to address some of them for NB-17. If you come across any 
problems/issues with dialog placement, you're welcome to add a comment 
to this discussion;.


-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

Re: plugin built with 16-RC2 won't install on 15

[Ernie Rael]

On 22/10/28 3:52 PM, Michael Bien wrote:

On 29.10.22 00:27, Ernie Rael wrote:

On 22/10/28 3:08 PM, Michael Bien wrote:

 Search for "ByteBuffer NoSuchMethodError" for a taste.


Looks familiar, think I ran into that. Wasn't that considered a bug 
in the JDK release?


no, it was projects linking against the wrong JDK, e.g by not using 
the -release flag. I explained that in the other mail how the release 
flag works.


I left a comment in the code where I ran into the problem; it references

   https://github.com/apache/felix/pull/114

which led me to believe it was a JDK incompatibility; could just be that 
issue's author's point of view. I vaguely remember reading other stuff 
about it but it's not important now.



...
if you want to support a feature which is only available in a newer NB 
version while also be able to run on older NB versions, you could put 
that into a separate module and treat it as a service - it may or may 
not be available.


Wasn't using nb-javac to compile NetBeans supposed to make it easier to 
put that kind of thing together?


-ernie




in general: supporting a wide range of versions with the same binary 
usually comes at a cost



-mbien




-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






-
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

Re: plugin built with 16-RC2 won't install on 15

[Ernie Rael]

On 22/10/28 3:08 PM, Michael Bien wrote:





and I wish I could count on the fact that there's been no bug report; 
but that's another story.


Given that sigtest failed, I'm surprised that there's so much 
surprise that there's an issue.


nobody is surprised. If you would have read the PR you would have seen 
that the signature change was discussed before integration and rightly 
considered harmless. 


I read the PR yesterday.

I wasn't clear. I was surprised that people were surprised that I think 
the PR broke something.


sigtest failed, and it was fixed by modifying sigtest. I won't say it 
was the wrong decision, but I don't like that it's a lot more work to 
have one binary that both adds plugin features and makes use of new 
NetBeans features and still runs on older releases.


I also left the small refactoring in a separate commit, without 
squashing the PR so that in the event someone of us overlooked 
something it would be trivial to revert.


Tired me yesterday actually kept reading that an existing plugin 
failed to run on 16rc1, that is why I said i was wondering why a JVM 
would not find that method anymore - which doesn't make any sense in 
retrospect.




I'm actually amazed that

   "don't think this actually breaks compatibility in a bad away"

seems to be a prevailing direction.


well yes, because compatibility is maintained. Existing code will keep 
running. New code can enjoy type safety since runtime CCEs are now 
compiler errors. Its unlikely here, but generics can sometimes reveal 
bugs.


And since the type is now known it is also better usable in streams, 
which is how I noticed that the generics were missing in the first place.



false alarm :)


Not for me

-ernie



-mbien


-
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

Re: plugin built with 16-RC2 won't install on 15

[Ernie Rael]

On 22/10/28 3:08 PM, Michael Bien wrote:

 Search for "ByteBuffer NoSuchMethodError" for a taste.


Looks familiar, think I ran into that. Wasn't that considered a bug in 
the JDK release?


-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

Re: plugin built with 16-RC2 won't install on 15

[Ernie Rael]

On 22/10/28 9:47 AM, Neil C Smith wrote:

On Fri, 28 Oct 2022 at 17:14, Ernie Rael  wrote:

So does the workaround I suggested work for you? 


Seems to.

I'm checking out the 16 build on 15 now that I can run it.

-ernie


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

Re: plugin built with 16-RC2 won't install on 15

[Ernie Rael]

On 22/10/28 2:27 AM, Neil C Smith wrote:

On Thu, 27 Oct 2022 at 21:35, Matthias Bläsing
  wrote:

Am Donnerstag, dem 27.10.2022 um 20:51 +0100 schrieb Neil C Smith:

I'm not sure that's correct from the JVM perspective.  The Object
method should still be generated as a bridge?

It should be backwards compatible but it's not forwards compatible?
Anything compiled against 15 should run on 16, but anything compiled
against 16 won't run on 15?

I still think it's probably a good idea to revert in this particular
case though.

you are right and my reasoning was wrong. I looked at the generated
code with javap and there I see:

Thanks for confirming!  It was my thought in reviewing the original
PR, but there are so many question marks in the paragraph above
because generics never cease to confuse me! :-)

This got me thinking whether there's a workaround for Ernie to force
the bridge method to be called.

Maybe using raw references? - (at least doing this with String and
testing with javap seems to work) -

Comparable specVersion = mi.getSpecificationVersion();
Comparable reqVersion = new SpecificationVersion("9.26");
if (specVersion.compareTo(reqVersion)) >= 0) { // etc etc

It's still a bad idea to compile against a later platform and expect
it to work on an earlier one, but that might just work in this case.


This practice (what you call a bad idea) has been working for 20 years 
with this plugin, and it's not a small plugin. To avoid 
misunderstanding, I'm not saying that the current plugin runs on a NB 
6.x. I do use module versioning as needed. The current bits run on 12.0 
to current. Well, It's been over a year since I tested on 12, and I wish 
I could count on the fact that there's been no bug report; but that's 
another story.


Given that sigtest failed, I'm surprised that there's so much surprise 
that there's an issue. I'm actually amazed that


   "don't think this actually breaks compatibility in a bad away"

seems to be a prevailing direction.

I've mentioned before that the plugin bits that ran on NB-8.x ran on 
versions going back to NB-7.x. And there was extensive use of 
"specVer.compareTo(reqVer)", speak of the devil, so that the plugin 
would interoperate well with newer features. And note that with 
awareness of new features, the plugin **must** be compiled on a new 
release (or use reflection a lot more than the amount the plugin does).


I do not want to have a different source and different binary for each 
release. And I certainly don't trust the plugin portal to manage versions.


-ernie



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

Re: plugin built with 16-RC2 won't install on 15

[Ernie Rael]

On 22/10/27 4:26 PM, Michael Bien wrote:

On 27.10.22 22:51, Ernie Rael wrote:


I'm still confused. I always thought generics were syntactic sugar, 


nah they do influence method signatures, add bridge methods you never 
wrote etc. Its more than just compile time checks.


Matthias showed the javap results for this particular case in the 
other mail.



Don't think that mail made it to the list. I did find the excerpt that's 
quoted



In the implementation the "before" promise is broken as the first
instruction is a checked cast

intriguing.

-ernie



-mbien


and they became Object at runtime. I can kind of rationalize why it's 
failing, but it's more than just generics.


Anyway, I'll build delivery and try it, if (I hope when) the revert 
gets merged.


-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






-
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

Re: plugin built with 16-RC2 won't install on 15

[Ernie Rael]

On 22/10/27 12:52 PM, Michael Bien wrote:

On 27.10.22 21:46, Ernie Rael wrote:

On 22/10/27 12:33 PM, Michael Bien wrote:

On 27.10.22 21:14, Matthias Bläsing wrote:

Hi,

Am Donnerstag, dem 27.10.2022 um 20:32 +0200 schrieb Michael Bien:

On 27.10.22 20:17, Neil C Smith wrote:

On Thu, 27 Oct 2022, 19:03 Ernie Rael,  wrote:

This is very strange. If I build the plugin on 15 it runs on 15. 
If I
build it with 16-RC2 it will not install on 15. I noticed this a 
few

days ago, but wanted to wait for RC2 before mentioning it.

I'll try to narrow it down, wondering if anyone has some ideas 
about this.



It'll be caused by https://github.com/apache/netbeans/pull/4678

Downside of adding generics. Still time to review, although I 
assume the

reverse situation isn't affected?
i kept it in the second commit and didn't squash just in case we 
have a

situation like this.

https://github.com/apache/netbeans/pull/4678/commits/50086abd421200ce33bd4508580a80518f350f63 



I am still a bit surprised that this causes issues. Since the 
class is
final which removes an entire can of worms of potential override 
issues.

I would have expected the JVM to find the right method in unambiguous
cases like this.
from the JVMs perspective, you removed a method that takes an 
arbitrary

object and added a method that takes a SpecificationVersion. The
message to the outside is:

- before I was prepare to take any object and will do sane things with
   it

- after I will only care about SpecificiationVersion instances

In the implementation the "before" promise is broken as the first
instruction is a checked cast, but it is the developer of the method
breaking other peoples assumptions, not the JVM.


I do get that, its just that it should only break if someone is 
calling the method with something which isn't of type 
SpecificationVersion. This would have failed at runtime before the 
change. It would fail at compiletime after the change - improve the 
situation.


SpecificationVersion does not extend anything and is final. So 
someone would have to store it as Object somewhere and then call the 
Comparable methods. I thought that would be unlikely.


The code is like:

   if (mi.getSpecificationVersion().compareTo(
        new SpecificationVersion("9.26")) >= 0) // >= NB-16


see, I don't understand why this wouldn't work. There is nothing 
ambiguous here. The call site should be still compatible for this kind 
of usage.


anyway... revert is pending. Learned something new.


Wondering what you've learned. I'm still confused. I always thought 
generics were syntactic sugar, and they became Object at runtime. I can 
kind of rationalize why it's failing, but it's more than just generics.


Anyway, I'll build delivery and try it, if (I hope when) the revert gets 
merged.


-ernie



-mbien



-ernie




-mbien



TL;DR: This is an API incompatible change and this was caught by
sigtest as the signature file was modified.

I suggest to revert that change as the underlying assumption about
compatible changes was wrong.

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






-
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






-
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

Re: plugin built with 16-RC2 won't install on 15

[Ernie Rael]

On 22/10/27 12:51 PM, Neil C Smith wrote:

On Thu, 27 Oct 2022 at 20:14, Matthias Bläsing
 wrote:

Am Donnerstag, dem 27.10.2022 um 20:32 +0200 schrieb Michael Bien:

I am still a bit surprised that this causes issues. Since the class is
final which removes an entire can of worms of potential override issues.
I would have expected the JVM to find the right method in unambiguous
cases like this.

from the JVMs perspective, you removed a method that takes an arbitrary
object and added a method that takes a SpecificationVersion. The
message to the outside is:

- before I was prepare to take any object and will do sane things with
   it

- after I will only care about SpecificiationVersion instances

I'm not sure that's correct from the JVM perspective.  The Object
method should still be generated as a bridge?

It should be backwards compatible but it's not forwards compatible?
Anything compiled against 15 should run on 16, but anything compiled
against 16 won't run on 15?


Compiled with JDK-11 if that matters.

-ernie



I still think it's probably a good idea to revert in this particular
case though.

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

Re: plugin built with 16-RC2 won't install on 15

[Ernie Rael]

On 22/10/27 12:33 PM, Michael Bien wrote:

On 27.10.22 21:14, Matthias Bläsing wrote:

Hi,

Am Donnerstag, dem 27.10.2022 um 20:32 +0200 schrieb Michael Bien:

On 27.10.22 20:17, Neil C Smith wrote:

On Thu, 27 Oct 2022, 19:03 Ernie Rael,  wrote:


This is very strange. If I build the plugin on 15 it runs on 15. If I
build it with 16-RC2 it will not install on 15. I noticed this a few
days ago, but wanted to wait for RC2 before mentioning it.

I'll try to narrow it down, wondering if anyone has some ideas 
about this.



It'll be caused by https://github.com/apache/netbeans/pull/4678

Downside of adding generics. Still time to review, although I 
assume the

reverse situation isn't affected?

i kept it in the second commit and didn't squash just in case we have a
situation like this.

https://github.com/apache/netbeans/pull/4678/commits/50086abd421200ce33bd4508580a80518f350f63 



I am still a bit surprised that this causes issues. Since the class is
final which removes an entire can of worms of potential override 
issues.

I would have expected the JVM to find the right method in unambiguous
cases like this.

from the JVMs perspective, you removed a method that takes an arbitrary
object and added a method that takes a SpecificationVersion. The
message to the outside is:

- before I was prepare to take any object and will do sane things with
   it

- after I will only care about SpecificiationVersion instances

In the implementation the "before" promise is broken as the first
instruction is a checked cast, but it is the developer of the method
breaking other peoples assumptions, not the JVM.


I do get that, its just that it should only break if someone is 
calling the method with something which isn't of type 
SpecificationVersion. This would have failed at runtime before the 
change. It would fail at compiletime after the change - improve the 
situation.


SpecificationVersion does not extend anything and is final. So someone 
would have to store it as Object somewhere and then call the 
Comparable methods. I thought that would be unlikely.


The code is like:

   if (mi.getSpecificationVersion().compareTo(
    new SpecificationVersion("9.26")) >= 0) // >= NB-16

-ernie




-mbien



TL;DR: This is an API incompatible change and this was caught by
sigtest as the signature file was modified.

I suggest to revert that change as the underlying assumption about
compatible changes was wrong.

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






-
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

Re: plugin built with 16-RC2 won't install on 15

[Ernie Rael]

On 22/10/27 11:17 AM, Neil C Smith wrote:

On Thu, 27 Oct 2022, 19:03 Ernie Rael,  wrote:


This is very strange. If I build the plugin on 15 it runs on 15. If I
build it with 16-RC2 it will not install on 15. I noticed this a few
days ago, but wanted to wait for RC2 before mentioning it.

I'll try to narrow it down, wondering if anyone has some ideas about this.


It'll be caused byhttps://github.com/apache/netbeans/pull/4678

Downside of adding generics. Still time to review, although I assume the
reverse situation isn't affected?


Building on 15 can install on 16.

BUT, I need to build on 16. I've got this code which references a new 16 
method, that I expect to run on NB back to 12.0


    @Override
    public Component findDialogParent()
    {
    //return super.findDialogParent();
    return ViManager.getHackFlag(Module.HACK_FIND_DIALOG_PARENT)
   ? Utilities.findDialogParent()
   : super.findDialogParent();
    }

I don't particularly enjoy juggling JDKs. And I sure don't want to have 
to not only maintain two source releases but also have different 
NetBeans versions. Not to mention having two binaries so I'd have to set 
up another update center for NB-16.


-ernie



Best wishes,

Neil

plugin built with 16-RC2 won't install on 15

[Ernie Rael]

This is very strange. If I build the plugin on 15 it runs on 15. If I 
build it with 16-RC2 it will not install on 15. I noticed this a few 
days ago, but wanted to wait for RC2 before mentioning it.


I'll try to narrow it down, wondering if anyone has some ideas about this.

-ernie

SEVERE [org.netbeans.core.modules]
java.lang.NoSuchMethodError: 
org.openide.modules.SpecificationVersion.compareTo(Lorg/openide/modules/SpecificationVersion;)I

    at org.netbeans.modules.jvi.Module.restored(Module.java:227)
    at org.netbeans.core.startup.NbInstaller.loadCode(NbInstaller.java:447)
[catch] at 
org.netbeans.core.startup.NbInstaller.loadImpl(NbInstaller.java:370)

    ...
INFO [org.netbeans.core.startup.NbEvents]: Turning on modules:



-
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

Re: Wondering where the reference to 8.2 is coming from

[Ernie Rael]

On 22/10/27 9:43 AM, Michael Bien wrote:
this has something to do with update centers as far as i know. I think 
they used to be able to patch NetBeans. You might have the NB 8 update 
center activated?


Thanks. Can't reproduce with a clean userdir, even enabling all the 
update centers. Nothing to pursue.


The situation arises when using an old userdir (which has a variety of 
update centers). In this case, if I disable the NB8 update center, I 
still see an "update available", but the 8.2... is gone.


-ernie



-mbien

On 27.10.22 18:42, Ernie Rael wrote:

In help > about, I see

   Product Version: Apache NetBeans IDE 16-rc2
   Updates: Updates available to version NetBeans 8.2 Patch 2
   Java: 11.0.2; OpenJDK 64-Bit Server VM 11.0.2+9

Is the reference to NB-8.2 something weird about my userdir? Or ...?

-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






-
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

Wondering where the reference to 8.2 is coming from

[Ernie Rael]

In help > about, I see

   Product Version: Apache NetBeans IDE 16-rc2
   Updates: Updates available to version NetBeans 8.2 Patch 2
   Java: 11.0.2; OpenJDK 64-Bit Server VM 11.0.2+9

Is the reference to NB-8.2 something weird about my userdir? Or ...?

-ernie

Re: nb-javac for building NetBeans itself

[Ernie Rael]

On 22/10/27 2:59 AM, Neil C Smith wrote:

On Wed, 26 Oct 2022 at 21:12, Ernie Rael  wrote:

  NetBeans found
refuge in the powerful walled city state of Apache; where residents are
only allowed commerce with those within its walls or with some who it
explicitly approves.

Your text amused me,
At least I got something right. I was half expecting exile or a trip to 
the gallows; although those outcomes aren't precluded by your amusement.

but this statement I find ironic.  Apache is a
lot more open than the powerful walled city state that is OpenJDK,
which is actually where a bunch of our issues stem.


(Yeah, I can see that.)

... that is OpenJDK, still controlled by the wealth of the old Kingdom 
and not truly independent.




If you really wanted to put the cat amongst the pigeons, you could
question whether Semeru is an ASL compatible JDK?! ;-)


Civil war in the ensuing chaos?

(I don't look much at the java ecosystem, hadn't heard of Semeru. I 
blanked on ASL, was finally obvious. Didn't think it was AgeSexLocation)


-ernie



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

Re: Java Help student project started

[Ernie Rael]

On 22/10/17 12:54 AM, Oliver Rettig wrote:

Hi all,

since years we miss a modern (on- and offline) help-viewer for your netbeans
platform applications. Now, we have just started a student project at the
Cooperative State University Karlsruhe (Germany) to fill this gap. It will run
the next six months.

Of course we have our specific needs and wishes but it will be great, if we can
implement something, which is interesting for many:-)

My personal main point is, that I want to add documentation into netbeans-
platform modules. If I collect some modules to a platform app I want to have a
tool which collects the documentation parts from all the included modules
automatically. I also want to integrate a help-viewer as on offline viewer into
the rcp-app by invoking a browser but I also want to push to a online-
available documentation maybe into a docuwiki page.

So, if you are interested please give us feedback what functionality you like
to see in a new Java-Help Viewer and if you know projects we have to look in,
or give us other hints about java-help.


I've heard that NetBeans help was lost because of Apache licensing 
restrictions; I don't know if that's true. If it is true, I've wondered 
if a plugin could be built out of the java help infrastructure that 
hooked into the existing NetBeans help. I never thought the help was 
great, but I sure miss it. I don't suggest this in place of the 
functionality you mention, but it might be a useful step that could be 
quickly put in place.


I very much like the ideas you mention of different ways to browse 
through, and extend, NetBeans help and documentation.


Best wishes for success,
-ernie



Here is a list what I have found just now and looks interesting for us:

https://git.rwth-aachen.de/netbeans/nb-help
https://github.com/AleksandraMisic762/help-in-browser-dev
https://git.rwth-aachen.de/j.hofschroeer/nb-help
https://github.com/hubersn/SwingHelpViewer
http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-javahelp/org/netbeans/api/javahelp/doc-files/help-guide.html
https://netbeans.apache.org/wiki/DevFaqHelpGuidelines.asciidoc
https://stackoverflow.com/questions/16262631/implementing-javahelp-search-with-the-netbeans-ide
https://dzone.com/articles/nb-how-create-javahelp-mavenized
https://stackoverflow.com/questions/9994373/using-javahelp-for-end-user-documentation-on-netbeans-based-application-tools-o
https://stackoverflow.com/questions/7804838/embedding-avi-in-javahelp
https://sourceforge.net/projects/jhelpdev/
https://www.netbeans-forum.de/viewtopic.php?t=6095
https://github.com/DmitriPopov/HelpinatorReadTheDocs/blob/master/javahelp.rst


best regards
Oliver




-
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

Re: nb-javac for building NetBeans itself

[Ernie Rael]

On 22/10/24 9:42 AM, Neil C Smith wrote:

OTOH, I don't think this is all suited to technical discussion on
individual code changes either, as there are also questions of broad
direction of travel raised here that need to be reconciled.

In the before time, in the Kingdom of Java, NetBeans was in thrall to 
Java but held the prominent position of easily allowing the first use of 
new features in Java. After the Java Kingdom was broken apart, NetBeans 
lost much and without the support of the powerful Java overlords 
NetBeans was diminished and scattered to the four winds. NetBeans found 
refuge in the powerful walled city state of Apache; where residents are 
only allowed commerce with those within its walls or with some who it 
explicitly approves. NetBeans has a loyal following, some who are 
aligned with Apache, and some who would remain in thrall to Java, and 
some who find solace in NetBeans' culture; they are a varied lot and 
their determination keeps NetBeans alive and growing. But NetBeans 
struggles to work with those outside of Apache's allies or even to 
accept contributions from those external to it through the magical 
portal. In the new order, NetBeans endeavors to compete and grow, to 
find its niche and regain its prominence; but it lacks distinction, and 
a clear path, and goals, and direction.


-
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

Re: nb-javac for building NetBeans itself

[Ernie Rael]

On 22/10/24 9:42 AM, Neil C Smith wrote:

On Mon, 24 Oct 2022 at 17:02, Michael Bien  wrote:

On 24.10.22 17:27, Ernie Rael wrote:

The link to apache's guidelines for voting was clarifying for me. I'd
like to see a more technical discussion.

for me too, I withdrew the -1 vote the moment I realized that this could
qualify as veto since this discussion would fall into the code-change
category.

Luckily withdrawing vetos is legal, which is useful since I didn't even
intend to veto anything :)

I would also point out that the link I shared strongly suggests using
whole numbers in the code-change category, as the position expressed
is boolean.

It's why I said above I'm lending you a -0.01! :-)  I don't think it's
helpful to muddy the waters here.  You're vetoing in all but name.  I,
for one, would like to see you and others moving to a neutral, if not
positive, stance before I'd review my own.

OTOH, I don't think this is all suited to technical discussion on
individual code changes either, as there are also questions of broad
direction of travel raised here that need to be reconciled.



I certainly agree with that. It's be great to see these issues of 
"direction", along with technical issues, clearly enumerated and agreed 
upon before the discussion begins in earnest.


-ernie



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

Re: nb-javac for building NetBeans itself

[Ernie Rael]

On 22/10/24 8:58 AM, Michael Bien wrote:

On 24.10.22 17:27, Ernie Rael wrote:
The link to apache's guidelines for voting was clarifying for me. I'd 
like to see a more technical discussion.


for me too, I withdrew the -1 vote the moment I realized that this 
could qualify as veto since this discussion would fall into the 
code-change category.


Luckily withdrawing vetos is legal, which is useful since I didn't 
even intend to veto anything :)



And I have to mention one thing that really bugged me: a lot of the 
discussion seemed to have the assumption that it's easy for users to 
use the latest JDK; I think that's just not accurate (but again don't 
have hard data). For me, I have to use Gradle 6.8.x so I can not use 
the latest JDK. If it's true in general that many/most users can not 
use the latest JDK, that seems like an extremely important data point.


Yes I heard about this issue. We should take a look if this can be 
somehow solved. Its certainly not optimal to be required to change the 
runtime JDK of the IDE when switching between projects which use 
different gradle versions.


lets try to solve this without nb-gradle if possible.
I only brought that up as an example of a situation where can't use the 
latest JDK. I wouldn't be surprised if most users have restrictions on 
which JDK can be used and/or targeted.


best regards,

michael




-ernie




Maybe a straight vote on this is the way forward, and we live with the
consequences either way?!

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






-
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

Re: nb-javac for building NetBeans itself

[Ernie Rael]

On 22/10/24 4:50 AM, Neil C Smith wrote:

On Mon, 24 Oct 2022 at 12:31, Geertjan Wielenga
 wrote:

On Mon, Oct 24, 2022 at 1:25 PM Neil C Smith  wrote:

Multiple people have expressed massive reservations on this already.
Michael expressed a -0.99 already.  Given code changes are really +1
or -1 anyway, I'll lend the -0.01 until his and other reservations are
adequately considered at least.

I thought the objections were to frgraal, not to nb-javac.

To both - see also
https://lists.apache.org/thread/z0fx3b2vrjx2rqlf07mfr493tqnmc51b

Some of the reservations brought up about frgaal apply to both too
(non-standard build).

I share some of the reservations, but also see some of the benefits.
I'm mostly concerned about the distinct lack of consensus on this as a
way forward.


My recollections of the previous discussion include a lot of opinion; 
when the smoke was clearing Neil said in the thread "[DISCUSS] Shall 
NetBeans improve Java/JDK? With Frgaal?":



Well, any -1 to a code change is a veto -
https://www.apache.org/foundation/voting.html#votes-on-code-modification

So ...

Also please keep in mind that the context of this discussion is ... a PR.
Any discussion really needs to address the reasons for veto by either
providing alternatives to the original proposal or otherwise addressing the
technical concerns raised. And probably the concerns raised in previous
Frgaal related PRs too.


The link to apache's guidelines for voting was clarifying for me. I'd 
like to see a more technical discussion.


And I don't remember much discussion on what best serves the NetBeans 
community (might be difficult to get good data here).


And I have to mention one thing that really bugged me: a lot of the 
discussion seemed to have the assumption that it's easy for users to use 
the latest JDK; I think that's just not accurate (but again don't have 
hard data). For me, I have to use Gradle 6.8.x so I can not use the 
latest JDK. If it's true in general that many/most users can not use the 
latest JDK, that seems like an extremely important data point.


-ernie




Maybe a straight vote on this is the way forward, and we live with the
consequences either way?!

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

Re: [PLUGINS][RELEASES] Preparation for NetBeans 16 plugins

[Ernie Rael]

On 22/10/22 5:09 AM, Michael Bien wrote:

On 21.10.22 14:24, Neil C Smith wrote:

On Fri, 21 Oct 2022 at 12:43, Michael Bien  wrote:

well, this was my first suggestion but it met resistance :)

I know.  I agree with you.  My issue with the resistance, and some
points are definitely valid, is that it's based on a somewhat false
idea of what we've been doing for the last few years of releases.


I would just leave everything verified. The community could filter
problematic plugins out which are not updated.

We can't leave verified as far as I understand.  We would need to bulk
verify everything, unless we go back to a shared catalog.  And if we
go back to shared catalogs, we can't filter by release.


well, this somehow doesn't sound like a showstopper to me. Something 
could just add that flag in some automated fashion, no?



Another idea: what if there would be two catalogs: one for verified 
plugins and one for unverified. Unverified would be disabled by 
default but would contain everything which didn't make verification yet.


This would:

 - make it a user choice

 - somewhat solve availability at release issues

 - improve testability during RC (everything is there if you enable 
the catalog)



An alternate approach to handling unverified plugins is to allow 
download from the plugin page, and the user manually installs it. I was 
(and still am) surprised that a plugin can not be fetched via the plugin 
portal, a lost feature from the pre-apache days. A plugin could have 
status like, for example:


1. Verified
2. pending verification
3. unverified
4. failed verification
5. blocked

I suppose there's a matrix of NB-version vs Plugin-version vs status 
(displayed simply in a understandable fashion). I guess only "Verified" 
would show up in the plugin update center in running NetBeans. Allow 
manual download/install from the portal for 2, 3, maybe even 4? Maybe 
there's something between 3,4 like user reported failures, but that 
seems a slippery slope?






There is also an argument to be made that a maintainer should probably 
be able to upload a new version of a plugin without re-verification if 
it was verified before to fast track updates. '



Verification delays is the reason I publish a plugin portal. If there's 
a bug, I want to make the fix available as soon as possible. I'd like to 
have the implicit versioning that's provided by a catalog per NB version 
(the new scheme we're struggling to get to), but plugin reliability is 
more important. So the plugin jumps through hoops so the same bits can 
run on multiple NB versions (not sure I'd stop doing that, there are 
advantages to having one plugin version for many releases)



One of the 5 available (and verified) plugins continues to cause 
issues. Not only that, it causes them in areas you wouldn't expect. 
E.g empty debugger views or files which can't be opened anymore.


As I understand this - there is a new version available which fixes 
some (all?) of that - but it is not available from the plugin manager 
since it has not been verified yet.


Verification doesn't seem to be a big barrier to break IDEs, we 
probably should mention that somewhere so that this isn't seen as 
"stamp of approval".



somewhat related I added a 'caused-by-plugin' label, so we can use 
that to mark comparable issues it in future.


And some process that too many "caused-by-plugin" has an effect on the 
plugin's status at the plugin portal.





https://github.com/apache/netbeans/issues?q=label%3Acaused-by-plugin+is%3Aclosed 




A process to efficiently un-verify plugins is probably at least as 
important as having them in the plugin manager in the first place.


(Matthias'es mail admin UI looks great btw! eagerly waiting for the 
mail so I can press verify ;))


best regards,

michael



Of course, we could have one catalog and unverify anything that
doesn't work in the current or next release as an alternative?  Leaves
anyone sticking with older versions in an awkward position though.


I still wish we'd gone down the route of managing plugins via a git
repository!  It would have simplified and opened up this process to
all committers.

interesting idea! It would have had the benefit that all imaginable
tooling would be already there and maintainers know how to use it.

The "downside" (which I still consider the upside given licensing,
etc.) was that it involved external plugin hosting (via GitHub
releases, Maven, etc.) and metadata files in folders containing all
info including file link and hash.  Validation would be by PR with CI
verifying and building a static catalog file.

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

Getting in approved pull requests

[Ernie Rael]

There are two PRs that have been approved. I'd like to use them from a 
plugin if/when they are merged.


   Keyboard focus can activate top component
   https://github.com/apache/netbeans/pull/4603

and

   After file external change fire reloaded event
   https://github.com/apache/netbeans/pull/4249

The next one hasn't been approved, it's new, but as a NetBeans user (who 
finally this year got multi-screen setup) I'd sure like it in the platform.


   Dialog parent should not be null
   https://github.com/apache/netbeans/pull/4739

As freeze approaches,
-ernie

Re: [DISCUSS] Shall NetBeans improve Java/JDK? Without Frgaal this time...

[Ernie Rael]

Let me confess that I'm not sure what is proposed, in my simplistic view 
it's letting NB users have target less than source. I don't entirely 
understand all the stuff this msg is addressing.


But considering these points

- How useful is frgaal for NB/java user community? Makes NB more 
attractive?

- What are the risks? (remember nb-javac hell)
- What are the problems? (language vs API)

It does seem from the msg and the following statement in particular:

> make maintenance harder for no real benefit

"target < source" is not of any real use to the NetBeans/java community. 
The added NetBeans complexity is a giant risk.


I don't understand all the stuff related to "Why would a project like NB 
want to compile to Java 8 ...". Is that suggested?


-ernie

On 10/9/22 2:46 PM, Michael Bien wrote:

On 09.10.22 19:21, Jaroslav Tulach wrote:
However let's return back to the topic of the talk. Kotlin has some 
benefits

and Ernie nicely summarized them as:


- language specification independent of the JDK
- compiler version specified as part of project build script
- language quickly evolves
- still can be used to generate JDK8 code
I believe that Java ecosystem would be better, if we adopted some of 
these

benefits as well.

Let's only focus on the first two now. Let's make the compiler part 
of the
project build script first. That will detach the compiler/language 
from the

JDK.


I would advice against this. NetBeans has to deal with many compiler 
and JDK versions in various stages already. There is the JDK it runs 
on, nb-javac, the javac of the project platform. There are tests which 
use nb-javac, some use the javac of the test JVM, others use a 
different JDK in addition to the test JVM's JDK. I don't feel adding 
another layer and splitting the build into JDK and javac version is 
helping the situation. I would try to go the opposite route and remove 
layers.


To give a positive example: the simple fact that NB is allowed to ship 
nb-javac now, enabled us to remove a lot of reflection code and even 
some bytebuddy hacks (this resolved many bugs). Now imagine for a 
moment if NB could ship the rest of the JDK too. We could remove 
nb-javac, and we would have 1 axis in the test matrix of the java 
cluster. And 1-2 axis everywhere else. So simple that you can explain 
the build and runtime setup of NB to someone in a minute.


This is a very academic goal in my opinion. Why would a project like 
NB want to compile to Java 8 bytecode when there is JDK 37? NB 
couldn't even use third party libraries which have record APIs since 
they would be on the wrong bytecode level! Not to mention the APIs of 
JDK 37.


Language and API do go hand in hand - that is a feature, not a bug. If 
this would have to change, it would have to be within the OpenJDK 
project.


The java ecosystem is moving forward. It has to. Spring, Jakarta EE, 
jetty, jenkins, lucene... all bump their JDK requirements (Spring 6 
jumps directly to JDK 17 for example). The current version of lucene 
requires JDK 11. What are we supposed to do now? Lucene 8.x which is 
used in the maven modules, already has a custom, at runtime loaded 
patch which is backporting a bugfix to keep things going. Should NB 
fork lucene 9? nb-lucene? The JDK downloader module is also using JDK 
11 APIs and depends on libraries on the same bytecode level. Dealing 
with those issues would be all unnecessary extra steps which make 
maintenance harder for no real benefit.


The JDK requirement sets the baseline contract between libraries. The 
ecosystem has to bump the JDK version otherwise it can't interface on 
a higher baseline.


Please, lets not add another layer of complexity just to have arrows 
in switch. Sticking to 8 while everything is moving on is not 
realistic IMO. I would argue that remaining on 8 is counter productive 
for the ecosystem. Lets go with the flow and bump versions at a 
reasonable pace, while giving everyone the opportunity to upgrade. 
There are always multiple LTSes available at any given point in time 
which allows adoption "at your own pace". JDK 8 was the last big Java 
release. Upgrades after that are much smaller steps. LTSes are now 
shorter but are also released at a higher rate.


Not too long ago NB couldn't even build on JDK 11 or 17. NB still 
can't test all clusters on 11. The nbm maven templates have to learn 
the java module system somehow, since it is not obvious which 
add-opens flags an application has to set etc. So much to do to 
improve the OpenJDK experience while also moving forward.


There are also still quite some java 1.5 rawtype warnings left before 
having to worry about arrows in switch of frgaal-lang ;)


-0,99f from me

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:

Where to put findDialogParent? a static method

[Ernie Rael]

For the following (important in a multi screen setup, should read "don't 
use null")


   Dialog parent main window instead of null
   https://github.com/apache/netbeans/pull/4739

I want to move a method, private FileChooserBuilder.findDialogParent(), 
to a public spot. My first thought was DialogDisplayer, and there's also 
UI Utilites, 
https://bits.netbeans.org/dev/javadoc/org-openide-awt/overview-summary.html, 
which looked

promising, in it there's

   Package org.openide.awt
   A set of utility classes pertaining to the visual appearance of
   NetBeans.

but no place seems to fit.

Putting it in DialogDisplayer might make it easier to find (important). 
Curiously though, findDialogParent is used to roll your own dialog, like 
using JOptionPane rather than DialogDisplayer.notify/createDialog.


BTW, JOptionPane.show*(findDialogParent(), ...) works pretty good. In 
the tests I ran, the dialog shows up covering the button I clicked, hard 
to miss.


-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

Re: [DISCUSS] Shall NetBeans improve Java/JDK? With Frgaal?

[Ernie Rael]

On 10/7/22 3:41 PM, Ernie Rael wrote:


BTW, for command line use, I have an alias, use it like javac
frgaal is aliased to 
`mvn-repo/org/frgaal/compiler/19.0.0/compiler-19.0.0.jar'


Uhh, that would be

aliased to `java -jar 
mvn-repo/org/frgaal/compiler/19.0.0/compiler-19.0.0.jar'




-
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

Re: [DISCUSS] Shall NetBeans improve Java/JDK? With Frgaal?

[Ernie Rael]

This is about "target < source"; talk about changing the JDK version 
obfuscates the point. Changing JDK version is not available to many 
(most?) (just guessing).


The only technical points against (that have registered with me, and not 
saying that I fully agree with them, and there may be more) are

- hard/confusing to separate language/API
- difficult to support (nb-javac hell is an example)

Why "target < source" is important is discussed in the message that 
started this thread and uses Kotlin as an example, and mentions some 
important points about frgaal
- Kotlin language quickly evolves and still can be used to generate JDK8 
code is a huge benefit

- frgaal language specification independent of the JDK
- frgaal compiler version specified as part of project build script
- frgaal is a member of the javac family
- easy to drop frgaal after switching to newest JDK

Here are some key issues to consider
- How useful is frgaal for NB/java user community? Makes NB more attractive?
- What are the risks? (remember nb-javac hell)
- What are the problems? (language vs API)

As I've been getting deeper into this issue, I wonder why javac does not 
support this. Maybe marketing decision or test matrix? Since Oracle is 
involved, I'd guess marketing.


BTW, for command line use, I have an alias, use it like javac
frgaal is aliased to 
`mvn-repo/org/frgaal/compiler/19.0.0/compiler-19.0.0.jar'


-ernie

On 10/5/22 10:47 AM, Jaroslav Tulach wrote:

Hi.
Recently I brought [Frgaal retrofit compiler](http://frgaal.org) to your
attention again. There was a [PR-4682](https://github.com/apache/netbeans/
pull/4682) and then a discussion in the thread about (not) supporting ecj in
NetBeans: https://lists.apache.org/list.html?dev@netbeans.apache.org - thank
you for your comments.

It all boils down to a simple question: Shall NetBeans try to improve
shortcomings of the JDK?

I have recently given a talk [Forget/Ignore Kotlin, use Java19](https://
www.youtube.com/watch?v=ua-8ySwFgqg). There is a slide describing the benefits
of Kotlin around 5th minute. Clearly the fact that the Kotlin language quickly
evolves and still can be used to generate JDK8 code is a huge benefit.

Frgaal (described around 25 minute) can do the same. It has been modeled to
mimic the Kotlin model:
- language specification independent of the JDK
- compiler version specified as part of project build script

Moreover Frgaal is 100% compatible with future Java language specification -
easy to drop it after switching to newest JDK. Overall it is way easier to
adopt latest Java thru Frgaal than trying to switch to a completely new
language. Why do I have to explain it again and again?

NetBeans can support Frgaal without any problems as it is also (just like nb-
javac) a member of the Javac family. All these compilers generate exactly the
same errors and provide the same WYSIWYG experience. Same errors in the IDE,
same on the command line, same on the CI.

All that is needed is: We have to realize that "innovation happens elsewhere"
and make Java better than the one produced by the JDK team!

Anyone has guts to follow better-than-JDK vision? Then let me integrate Frgaal
into NetBeans and bring the latest Java language features to users of older
JDKs.
-jt




-
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

Where to put findDialogParent? a static method

[Ernie Rael]

For the following (important in a multi screen setup, should read "don't 
use null")


   Dialog parent main window instead of null
https://github.com/apache/netbeans/pull/4739

I want to move a method, private FileChooserBuilder.findDialogParent(), 
to a public spot. My first thought was DialogDisplayer, and there's also 
UI Utilites, 
https://bits.netbeans.org/dev/javadoc/org-openide-awt/overview-summary.html, 
which looked

promising, in it there's

   Package org.openide.awt
   A set of utility classes pertaining to the visual appearance of
   NetBeans.

but no place seems to fit.

Putting it in DialogDisplayer might make it easier to find (important). 
Curiously though, findDialogParent is used to roll your own dialog, like 
using JOptionPane rather than DialogDisplayer.notify/createDialog.


BTW, JOptionPane.show*(findDialogParent(), ...) works pretty good. In 
the tests I ran, the dialog shows up covering the button I clicked, hard 
to miss.


-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

Re: [DISCUSS] Shall NetBeans improve Java/JDK? With Frgaal?

[Ernie Rael]

On 10/6/22 8:16 PM, Michael Bien wrote:

On 06.10.22 19:55, Ernie Rael wrote:

On 10/6/22 10:41 AM, Neil C Smith wrote:

On Thu, 6 Oct 2022 at 18:02, Ernie Rael  wrote:


Is the claim that using older JDK for runtime rarely happens? I don't
have any data, but...; NetBeans is a case in point, and I know of
others; it can be a corporate (ie irrational:-) ) decision.

Well, relying on a global JDK to run NetBeans is possibly irrational
to start with, considering other options bundle a runtime. There are
obviously older JDK use cases, but I'm just not sure NetBeans itself
is the best example.



Oops, right you are. What you run NB on is a personal decision. I was 
thinking of NB/plugin developers who are constrained to source level 
== 11 (unless you're using frgaal)


plugin devs are not really constrained here, only if they want to 
mirror the minimum requirements of NetBeans itself. 


I very much do. I had to ponder keeping it 1.8 compatible. Before 
apache, the plugin was compatible with 7.0-8.2 (lots of hoops in the 
code checking module versions) I'm not sure of the number, but from the 
download stats, there likely over a thousand users of the plugin (it 
would be interesting to know).


I'd require the plugin portal be compatible with the min requirements; 
but that's another topic as it looks the portal is abandoned anyway.


A NetBeans release is tested on 11, 17 and "current at time of 
release". 11 is just the minimum JDK at the moment. I very much 
encourage everyone to use a recent JDK for your NB since why would you 
not use latest optimizations of up2date runtimes for development if 
you have that option?


A plugin which benefits from a newer JDK can simply define that in the 
manifest and it won't install on NB running on older JDKs. It can use 
language features, JDK apis and also third party libs on the same 
language level (beyond 11).


(i have a little xpath plugin which required JDK 11 even before this 
was the minimum requirement for NB, I only forgot to put that into the 
manifest - none of the 5 users noticed ;))


btw there are community installers which bundle latest NB with up to 
date JDKs. Linked from the download page. I think all of them are 
currently maintained by members of the NB PMC.


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

Re: [DISCUSS] Shall NetBeans improve Java/JDK? With Frgaal?

[Ernie Rael]

Thought I'd mention...

I was just testing some stuff in a standalone/plugin project (so has to 
be binary 11) for an in progress NB PR. Made a change in a file I 
haven't been in for a while, saw several hint flags, in this case for 
both instanceof and switch pattern matching, made the changes; cleaner, 
more supportable, so nice. Last week I chased down some places where 
functions were returning arrays stuffed with two or three values (cause 
I didn't want to build a class for just a few local uses), changed 
Object array to record with typed fields; very much more supportable.


Using these newer language features isn't "can't live without it", it's 
incremental improvement in code quality for something that has to run on 
JDK-11. Hints are great.


-ernie

On 10/5/22 10:47 AM, Jaroslav Tulach wrote:

Hi.
Recently I brought [Frgaal retrofit compiler](http://frgaal.org) to your
attention again. There was a [PR-4682](https://github.com/apache/netbeans/
pull/4682) and then a discussion in the thread about (not) supporting ecj in
NetBeans: https://lists.apache.org/list.html?dev@netbeans.apache.org - thank
you for your comments.

It all boils down to a simple question: Shall NetBeans try to improve
shortcomings of the JDK?

I have recently given a talk [Forget/Ignore Kotlin, use Java19](https://
www.youtube.com/watch?v=ua-8ySwFgqg). There is a slide describing the benefits
of Kotlin around 5th minute. Clearly the fact that the Kotlin language quickly
evolves and still can be used to generate JDK8 code is a huge benefit.

Frgaal (described around 25 minute) can do the same. It has been modeled to
mimic the Kotlin model:
- language specification independent of the JDK
- compiler version specified as part of project build script

Moreover Frgaal is 100% compatible with future Java language specification -
easy to drop it after switching to newest JDK. Overall it is way easier to
adopt latest Java thru Frgaal than trying to switch to a completely new
language. Why do I have to explain it again and again?

NetBeans can support Frgaal without any problems as it is also (just like nb-
javac) a member of the Javac family. All these compilers generate exactly the
same errors and provide the same WYSIWYG experience. Same errors in the IDE,
same on the command line, same on the CI.

All that is needed is: We have to realize that "innovation happens elsewhere"
and make Java better than the one produced by the JDK team!

Anyone has guts to follow better-than-JDK vision? Then let me integrate Frgaal
into NetBeans and bring the latest Java language features to users of older
JDKs.
-jt




-
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

Re: [DISCUSS] Shall NetBeans improve Java/JDK? With Frgaal?

[Ernie Rael]

On 10/6/22 10:41 AM, Neil C Smith wrote:

On Thu, 6 Oct 2022 at 18:02, Ernie Rael  wrote:


Is the claim that using older JDK for runtime rarely happens? I don't
have any data, but...; NetBeans is a case in point, and I know of
others; it can be a corporate (ie irrational:-) ) decision.

Well, relying on a global JDK to run NetBeans is possibly irrational
to start with, considering other options bundle a runtime.  There are
obviously older JDK use cases, but I'm just not sure NetBeans itself
is the best example.



Oops, right you are. What you run NB on is a personal decision. I was 
thinking of NB/plugin developers who are constrained to source level == 
11 (unless you're using frgaal)


But yeah, there are plenty of cases where older JDK runtime is dictated.

-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

Re: [DISCUSS] Shall NetBeans improve Java/JDK? With Frgaal?

[Ernie Rael]

-1 to DISCUSSION? Wow. That's pretty draconian.

Could we agree on "what are the issues?" It feels like FUD right now.

> if you are sure you never want to leave the hole you dug

What does that mean? If the java "promise" is true. Then at any time you 
can use a released JDK >= SourceLevel.


> I disagree that frgaal is just like nb-javac

Disagree with what? I didn't see a statement that said it was the same, 
AFAICT. It does seem to be javac with the governor disabled.


> niche use cases

Is the claim that using older JDK for runtime rarely happens? I don't 
have any data, but...; NetBeans is a case in point, and I know of 
others; it can be a corporate (ie irrational:-) ) decision. Seems to be 
an undercurrent of "don't need to support the luddites, let them modernize"


> "no surprises".  seems the antithesis of this.

If (that's if) the default was source == target, what's the surprise? 
User's would have more options.




Here are some possible issues, not sure how unbiased my takes are. But 
what are the issues?


- What features does frgaal offer? It it useful for NB user community? 
Does it make NB more attractive?
There's hasn't been much discussion of this (I haven't looked at JT's 
presentation), seems like this is most important. The NB developers is a 
pretty niche group; how representative are they of the java community?


Academia likes the option. It's difficult to get reliable info about 
what a broad user community wants/needs; what would bring in new users.
There seems to be general agreement that the current process is 
difficult to use, someone mentioned a case where they were not allowed 
to upgrade the jdk for any use.


- What are the risks?
Just came out of nb-javac hell. Is there a concern about bad code 
generation (that's not already in JDK?)


- What are the problems?
Language vs API. It get's loaded from maven central, does that moot the 
"ASF legal process..."?


Once the issues are understood, it's easier to discuss them.

IMO, having this capability actively supported, more than just you can 
make it work, could benefit a larger community and be an attractive feature.


There seems to be a resounding '-1', but I'm not sure for what really. 
There also seems to be some consensus that its difficult going to a 
newer jdk, though it's been considerable improved and there more that 
could be done.


-ernie


On 10/5/22 10:47 AM, Jaroslav Tulach wrote:

Hi.
Recently I brought [Frgaal retrofit compiler](http://frgaal.org) to your
attention again. There was a [PR-4682](https://github.com/apache/netbeans/
pull/4682) and then a discussion in the thread about (not) supporting ecj in
NetBeans: https://lists.apache.org/list.html?dev@netbeans.apache.org - thank
you for your comments.

It all boils down to a simple question: Shall NetBeans try to improve
shortcomings of the JDK?

I have recently given a talk [Forget/Ignore Kotlin, use Java19](https://
www.youtube.com/watch?v=ua-8ySwFgqg). There is a slide describing the benefits
of Kotlin around 5th minute. Clearly the fact that the Kotlin language quickly
evolves and still can be used to generate JDK8 code is a huge benefit.

Frgaal (described around 25 minute) can do the same. It has been modeled to
mimic the Kotlin model:
- language specification independent of the JDK
- compiler version specified as part of project build script

Moreover Frgaal is 100% compatible with future Java language specification -
easy to drop it after switching to newest JDK. Overall it is way easier to
adopt latest Java thru Frgaal than trying to switch to a completely new
language. Why do I have to explain it again and again?

NetBeans can support Frgaal without any problems as it is also (just like nb-
javac) a member of the Javac family. All these compilers generate exactly the
same errors and provide the same WYSIWYG experience. Same errors in the IDE,
same on the command line, same on the CI.

All that is needed is: We have to realize that "innovation happens elsewhere"
and make Java better than the one produced by the JDK team!

Anyone has guts to follow better-than-JDK vision? Then let me integrate Frgaal
into NetBeans and bring the latest Java language features to users of older
JDKs.
-jt




-
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

Re: project group of all NetBeans modules for refactoring

[Ernie Rael]

I wonder what adjustment should be made to the ignore list.

-ernie

On 10/6/22 1:01 AM, Michael Bien wrote:
thanks for sharing Ernie. Already updated my group using the script 
(adjusted the paths first obv.). Worked great!


it lists 840 projects, I remember a similar number from my old nb-all 
group which means it wasn't too much out of date yet :)


-mbien

On 05.10.22 04:41, Ernie Rael wrote:
Inspired by @mbien to setup for doing some jackpot (declarative 
refactoring) across all of NetBeans, I used two scripts to set up a 
project group with all the projects. Here they are in case someone 
might find them useful. They don't find gradle or maven projects 
(AFAIK). Run them like the following, given there's a nb-all group 
and you're in the directory


/config/Preferences/org/netbeans/modules/projectui/groups/

then do

   bash findproj | bash fixgroup nb-all.properties

When done there'll be a nb-all.properties.bak file. You can run the 
commands separately, for example to diff the list to a previous list.


-ernie

=== findproj

nb_parent=/ref/nb/src

set -e

Main() {
    cd $nb_parent
    find netbeans -type d -name nbproject \
    | grep -E -v "$(ignore_these)" \
    | sed -e 's/[^/]*$//' \
    | sort
}

ignore_these() {
    local zap="
    /test/
    /iDeviceNativeBinding/
    /libs.nbi.ant/
    /csl.api/anttask/
    /dlight.nativeexecution/tools/
    /javafx2.samples/
    /installer/
    /sample_src/
    /javafx2.samples/
    /java.examples/
    /copylibstask/
    /nbbuild/
    /nbi/engine/
    /nbi/infra/
    /samples_src/
    /languages.antlr/
    /javawebstart/
    /performance/
    /php.samples/
    /CordovaMapsSample/
    /cordovaprojectupdate/
    /ide/bcutil/
    /ide/libs.tomlj
    /ide/libs.truffleapi/
    /ide/libs.xerces/
    /classfile/closure/
    "
    local result=$(printf "|%s" $zap)
    # strip the leading '|'
    echo "${result:1}"
}

Main

=== fixgroup

group=$1
nb_parent=/ref/nb/src

set -e

mv $group $group.bak
grep -v '^path=' $group.bak > $group

{
    echo -n "path="
    while read proj; do echo -n "file:$nb_parent/$proj "; done
    echo
} >> $group


-
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







-
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

project group of all NetBeans modules for refactoring

[Ernie Rael]

Inspired by @mbien to setup for doing some jackpot (declarative 
refactoring) across all of NetBeans, I used two scripts to set up a 
project group with all the projects. Here they are in case someone might 
find them useful. They don't find gradle or maven projects (AFAIK). Run 
them like the following, given there's a nb-all group and you're in the 
directory


   /config/Preferences/org/netbeans/modules/projectui/groups/

then do

   bash findproj | bash fixgroup nb-all.properties

When done there'll be a nb-all.properties.bak file. You can run the 
commands separately, for example to diff the list to a previous list.


-ernie

=== findproj

nb_parent=/ref/nb/src

set -e

Main() {
    cd $nb_parent
    find netbeans -type d -name nbproject \
    | grep -E -v "$(ignore_these)" \
    | sed -e 's/[^/]*$//' \
    | sort
}

ignore_these() {
    local zap="
    /test/
    /iDeviceNativeBinding/
    /libs.nbi.ant/
    /csl.api/anttask/
    /dlight.nativeexecution/tools/
    /javafx2.samples/
    /installer/
    /sample_src/
    /javafx2.samples/
    /java.examples/
    /copylibstask/
    /nbbuild/
    /nbi/engine/
    /nbi/infra/
    /samples_src/
    /languages.antlr/
    /javawebstart/
    /performance/
    /php.samples/
    /CordovaMapsSample/
    /cordovaprojectupdate/
    /ide/bcutil/
    /ide/libs.tomlj
    /ide/libs.truffleapi/
    /ide/libs.xerces/
    /classfile/closure/
    "
    local result=$(printf "|%s" $zap)
    # strip the leading '|'
    echo "${result:1}"
}

Main

=== fixgroup

group=$1
nb_parent=/ref/nb/src

set -e

mv $group $group.bak
grep -v '^path=' $group.bak > $group

{
    echo -n "path="
    while read proj; do echo -n "file:$nb_parent/$proj "; done
    echo
} >> $group


-
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

Re: Dialogs with no parents

[Ernie Rael]

On 10/1/22 2:12 PM, Michael Bien wrote:

Hi Ernie,

On 01.10.22 21:07, Ernie Rael wrote:


As a an experiment, there's the hint seen below. Is there a way to 
run it on all projects, not just the open projects?


I don't think there is. When I ran repo wide refactorings (e.g #3844) 
I opened all modules in netbeans and ran the hints on them. I have a 
project group for this purpose. But be warned, it takes a while to run 
hints over ~840 projects. Indexing/scanning takes a bit too after you 
opened them. Plan accordingly :P


Project group settings have absolute paths in them, I could give them 
to you but they won't work unfortunately.
Sed/awk/..., its got to be faster than opening them by hand. I had 
thought I could open nbbuild or something, and ask for dependent 
projects, but I guess not.





Similar hint can be put together for other situations, escpecially 
JOptionPane.show*(parent, ...). This would probably necessitate 
adding a lot of dependencies on org.openide.windows.


nice to see more devs using refactoring rules. They can be super useful!
Since jackpot was first available, I thought that was something that 
could really sell NetBeans. same feeling for RCP. Seemed to me that 
Oracle could really have sold RCP; as an application platform to their 
customers.


(not sure if you've noticed. but if you have them in 
.netbeans/15/config/rules, you can simply edit and save them and they 
going to be updated in realtime in the editor, cuts the dev cycle down 
significantly. You used to have to go through x menus to reload them 
or restart NB. You can run them also via the usual run file action)


Now that you mention it, I did notice. Once I thought I didn't restart 
but it seemed to be working. I was a little confused, but I wasn't sure 
exactly what was going or, or what I did; very cool. Thanks, now I can 
consciously use it.


-ernie



best regards,

-mbien




-ernie

"chooser dialog null":
$jfc.showOpenDialog(null) :: $jfc instanceof javax.swing.JFileChooser
=> 
$jfc.showOpenDialog(org.openide.windows.WindowManager.getDefault.getMainWindow)

;;

"chooser dialog null":
$jfc.showSaveDialog(null) :: $jfc instanceof javax.swing.JFileChooser
=> 
$jfc.showSaveDialog(org.openide.windows.WindowManager.getDefault.getMainWindow)

;;


-
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







-
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

Dialogs with no parents

[Ernie Rael]

There are dialogs scattered around NetBeans that do not specify a 
parent. So when they come up they are on the "default screen", which for 
me is typically not the screen with the NetBeans main window. More that 
once I've wondered why NB is hung (maybe I'm a little too focused). 
There's PR "Check for EnvVar/SysProp for preferred screen", 
https://github.com/apache/netbeans/pull/4714 that has some related 
discussion.


As a an experiment, there's the hint seen below. Is there a way to run 
it on all projects, not just the open projects?


Similar hint can be put together for other situations, escpecially 
JOptionPane.show*(parent, ...). This would probably necessitate adding a 
lot of dependencies on org.openide.windows.


-ernie

"chooser dialog null":
$jfc.showOpenDialog(null) :: $jfc instanceof javax.swing.JFileChooser
=> 
$jfc.showOpenDialog(org.openide.windows.WindowManager.getDefault.getMainWindow)

;;

"chooser dialog null":
$jfc.showSaveDialog(null) :: $jfc instanceof javax.swing.JFileChooser
=> 
$jfc.showSaveDialog(org.openide.windows.WindowManager.getDefault.getMainWindow)

;;


-
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

Re: [DISCUSS] Supporting ecj in NetBeans

[Ernie Rael]

> automatically backported nb-javac

I wouldn't say automatically makes it "technically the same"; I don't 
know much about the mechanisms that do javac --> nbjavac, maybe it's not 
that bad. If frgaal was automatically generated from javac, would that 
make them the same and alleviate concerns about "non-standard" java 
compiler?


> frgaal to me is a last resort in situations where you can't upgrade 
the JDK


Like if you want your code to work as a generally available NetBeans 
plugin? And NetBeans isn't the only example where a particular, 
old/not-latest, jdk is required; I think it's pretty common.


> but for whatever reason really want a particular language feature.

At least for me, I want to become conversant with newer jdk features, 
not simply one feature; that's enough reason for me to use frgaal and it 
removes a great frustration. text block is first for my immediate use; 
and there's a project I work with that "where" switch pattern matching 
will be very useful (they're still on 1.8, thinking about moving to 11); 
and using Record as I come across places where it can/should be used to 
improve code quality is sweet.


> adapt to the platform NetBeans is working on

I don't like that as the only choice. I'm forced to use jdk-11 to run 
NetBeans, because I have to use gradle 6.8.x and for some reason this 
forces a jdk requirement on NetBeans.


> I don't think it's fair to call those opinions short-sighted

Perhaps "near-sighted" would be more accurate ;-)

It seems like many on the team have strong opinions on what a proper 
developer should be doing; I appreciate seeing opinions about best 
practices. There seem to be two main issues: Is frgaal safe? Is making 
it trivial to use the latest language features a good/distinguishing IDE 
feature and one that user's would appreciate?


If frgaal is "technically the same" then why not use it? It comes down 
to alerting the user if they set target < source.


At a minimum, seems worth having a "try the newest language features" 
option and/or NewProject category. And it's easy to switch. BTW, I agree 
that the "language-feature without library" is a hassle, but as far as 
I've seen, the compile fails; so not too severe. It would be nice to 
have an error shown while editing (is that about boot path?).


-ernie

On 9/29/22 9:27 AM, Eric Barboni wrote:

Hi,

I'm not very fluent on what is needed in NetBeans to get ecj to work if we 
would like to. So difficult to say yes or no.
Will not be me integrating  but cannot presume for others.

Best Regards
Eric

On the side of frgaal (an off topic)
Personnal side:
testing new jdk feature without messing up jdk settings Nice to have
but no need to retro to jdk 8; retro to current jdk is enough.
Cannot jump to far in jdk version (NetBeans has to be patched for that)

On teaching side could be cool, as most of  our jdk are locked for a year so in 
the second semester a new JDK comes and you cannot play with new apis :D.

Will also be drawback, frgraal setup project perfectly usable in NetBeans then 
opened in another IDE, and some will complains that NetBeans generate code that 
is  outlined red (no matters if it compile).

And maybe more relevant sample than a helloword could also be nice :p



-Message d'origine-
De : Neil C Smith 
Envoyé : jeudi 29 septembre 2022 13:02
À : dev@netbeans.apache.org
Objet : Re: [DISCUSS] Supporting ecj in NetBeans

On Thu, 29 Sept 2022 at 03:51, Laszlo Kishalmi  
wrote:

Michael sums it up well. I agree completely.

Yes, as always, pretty spot on!


frgaal: compiler candy without new API, is just like alcohol-free beer.

:-)  Yes.  Very much seems like a solution looking for a problem to me.

I'm not sure that comment was much in favour of ecj support as against pushing 
frgaal as a good option for anything but very niche cases.
It's rare a PR gets -1, let only multiple, so I don't think it's fair to call 
those opinions short-sighted.  There are some good points raised in the PR 
description, but no mention of frgaal there.  A better discussion would be on 
those points than ecj support.

Personally I think promoting the latest java(c) features is better done by 
ensuring the IDE supports the latest JDK as best we can; as Eric suggested, 
enhancing the templates to take more account of running / target platform (eg. 
choose platform as first step?); and (from a somewhat biased position) 
promoting installers that run NetBeans on a local, latest supported, JDK out of 
the box.

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: 

bits.netbeans.org doc search problem

[Ernie Rael]

I wanted to take a look at ContextAwareAction. But entering this in the 
search box has no results. Found it in the source, searched for 
imageutil from the same package, clicked AllClasses, found it there.


I think this has been an issue for a long time. Might have to do with 
"Interface".


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

Re: netbeans module coding questions

[Ernie Rael]

There are some excellent answers, perhaps you are blocked on your side.

You can view the thread at: 
https://lists.apache.org/list?dev@netbeans.apache.org:2022-9


-ernie

On 9/24/22 8:11 AM, Peter Cheung wrote:

am i being blocked? whatever i ask, no one willing to answer 


Thanks

 From Peter (System Architect, Quantr Limited https://www.quantr.hk , Mobile : 
96554595)


From: Peter Cheung
Sent: Thursday, September 8, 2022 1:46 AM
To: dev@netbeans.apache.org 
Subject: netbeans module coding questions

hi
1. I want to customize the editor's side bar (the one showing the line 
number), I want to add some icon to it. Any example for this?
2. The highlightfactory + highlighter is highlighting the editor by char 
offset. Is it possible to highlight some rows?
thanks
Peter




-
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

Re: Gradle: how to get IDE pickup source from open project

[Ernie Rael]

On 9/23/22 10:16 AM, László Kishalmi wrote:

Well, it seems imported build tasks are handled a bit differently. or the
jvi-cmd:run task is not a JavaExec task.


Running the project directly, not includedBuild, with

   tasks.run { t ->
    println "** ${t.class.name}"

I see

> Configure project :jvi-cmd
   ** org.gradle.api.tasks.JavaExec_Decorated



Then I'd just create a run (JavaExec) task in your build configured the
same way (classpath, main class etc) as it is in jvi-cmd:run
Since I just did something like "id application" and the run task 
magically appeared, this will take some investigation.


BTW go you have this stuff on GitHub or somewhere public, so I can have a
glimpse? Might be able to file a PR for you.


https://sourceforge.net/p/jvi/code

There's a "Download Snapshot" button if you don't want to use mercurial.

The composite build scripts are:

/src/jvi-dev/jvi-ide
$ for i in settings.gradle build.gradle; do echo === $i ===;cat $i;done
=== settings.gradle ===

rootProject.name = 'jvi-ide'

includeBuild '/src/jvi-dev/jvi'
=== build.gradle ===

def jvi_proj = [ ':jvi-core', ':jvi-swing', ':jvi-cmd' ]

void deps(Task t, String proj, List subprojs, String subt) {
    for(sp in subprojs) {
    t.dependsOn gradle.includedBuild(proj).task(sp + subt)
    }
}

tasks.register('clean') { task ->
    deps(task, 'jvi', jvi_proj, ':clean')
}

tasks.register('build') { task ->
    deps(task, 'jvi', jvi_proj, ':build')
}

tasks.register('run') {
    dependsOn gradle.includedBuild('jvi').task(':jvi-cmd:run')
}



On Fri, Sep 23, 2022 at 9:31 AM Ernie Rael  wrote:


On 9/22/22 10:07 PM, Laszlo Kishalmi wrote:

Well, if I see well, you try to bring the jvi-cmd:run task down to the
project level by defining a task that depends on that.

The defined run task would be a DefaultTask, so it is not taking the
--debug-jvm argument.

Here instead of defining a new run task, I'd configure the ide's run
and debug action to use :jvi-cmd:run  or (jvi-cmd:run I'm not sure
that the first : is needed) instead of run.

Haven't been able to get debug action to work

Doing

 ConfiguredAction: debug, Arguments: :jvi:jvi-cmd:run

And clicking debug runs the command, but no debugger. Change it to

 Arguments: :jvi:jvi-cmd:run --debug-jvm

But this hangs. With a different project, with unmodified actions,
clicking debug shows

 cd /src/jvi-dev/jvi/jvi-cmd; ../gradlew --configure-on-demand -x
 check run --debug-jvm

Tried

 Arguments: -x check :jvi:jvi-cmd:run --debug-jvm

which fails with "Task 'check' not found in root project 'jvi-ide'.".
Tried a couple "Hail Mary"s with

 Arguments: -x :jvi:jvi-cmd:check :jvi:jvi-cmd:run --debug-jvm
 Arguments: -x :jvi:check :jvi:jvi-cmd:run --debug-jvm

The first doesn't get an error, but hangs just the same. The second
doesn't find check in jvi.

I thought about running the debugger from the 'buildInclude' project
directly, but I suspect in a more general case the dependencies would be
wrong.

-ernie


On 9/22/22 19:37, Ernie Rael wrote:

On 9/22/22 9:15 AM, László Kishalmi wrote:

You may find reading this one useful:
https://docs.gradle.org/current/userguide/composite_builds.html


Thanks, this looks promising. I started, only for one project, with
settings.gradle

rootProject.name = 'jvi-ide'

includeBuild '/src/jvi-dev/jvi'

Mixed in some build.gradle

def jvi_proj = [ ':jvi-core', ':jvi-swing', ':jvi-cmd' ]

void deps(Task t, String proj, List subprojs, String subt) {
 for(sp in subprojs) {
 t.dependsOn gradle.includedBuild(proj).task(sp + subt)
 }
}

tasks.register('clean') { task ->
 deps(task, 'jvi', jvi_proj, ':clean')
}
...
tasks.register('run') {
 dependsOn gradle.includedBuild('jvi').task(':jvi-cmd:run')
}

I thought it was weird that I had to enumerate the sub-projects, but
some think I'm weird.

Opening this project in ide I can build, clean, Use the GREEN button
to run the project, but the DEBUG button fails. Suggestions? IDE output:

cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run
...

Configure project :jvi:jvi-swing

namedservicesMerge-1: project ':jvi:jvi-swing'
'jVi/init/com.raelity.jvi.ViInitialization'
Configuration on demand is an incubating feature.


Task :jvi:jvi-core:compileJava UP-TO-DATE

...


Task :jvi:jvi-cmd:run

==
cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run --debug-jvm
...

Configure project :jvi:jvi-swing

namedservicesMerge-1: project ':jvi:jvi-swing'
'jVi/init/com.raelity.jvi.ViInitialization'
Configuration on demand is an incubating feature.

FAILURE: Build failed with an exception.

* What went wrong:
Problem configuring task :run from command line.

Unknown command-line option '--debug-jvm'.

Re: Gradle: how to get IDE pickup source from open project

[Ernie Rael]

On 9/22/22 10:07 PM, Laszlo Kishalmi wrote:
Well, if I see well, you try to bring the jvi-cmd:run task down to the 
project level by defining a task that depends on that.


The defined run task would be a DefaultTask, so it is not taking the 
--debug-jvm argument.


Here instead of defining a new run task, I'd configure the ide's run 
and debug action to use :jvi-cmd:run  or (jvi-cmd:run I'm not sure 
that the first : is needed) instead of run.


Haven't been able to get debug action to work

Doing

   ConfiguredAction: debug, Arguments: :jvi:jvi-cmd:run

And clicking debug runs the command, but no debugger. Change it to

   Arguments: :jvi:jvi-cmd:run --debug-jvm

But this hangs. With a different project, with unmodified actions, 
clicking debug shows


   cd /src/jvi-dev/jvi/jvi-cmd; ../gradlew --configure-on-demand -x
   check run --debug-jvm

Tried

   Arguments: -x check :jvi:jvi-cmd:run --debug-jvm

which fails with "Task 'check' not found in root project 'jvi-ide'.". 
Tried a couple "Hail Mary"s with


   Arguments: -x :jvi:jvi-cmd:check :jvi:jvi-cmd:run --debug-jvm
   Arguments: -x :jvi:check :jvi:jvi-cmd:run --debug-jvm

The first doesn't get an error, but hangs just the same. The second 
doesn't find check in jvi.


I thought about running the debugger from the 'buildInclude' project 
directly, but I suspect in a more general case the dependencies would be 
wrong.


-ernie



On 9/22/22 19:37, Ernie Rael wrote:

On 9/22/22 9:15 AM, László Kishalmi wrote:

You may find reading this one useful:
https://docs.gradle.org/current/userguide/composite_builds.html

Thanks, this looks promising. I started, only for one project, with 
settings.gradle


   rootProject.name = 'jvi-ide'

   includeBuild '/src/jvi-dev/jvi'

Mixed in some build.gradle

   def jvi_proj = [ ':jvi-core', ':jvi-swing', ':jvi-cmd' ]

   void deps(Task t, String proj, List subprojs, String subt) {
        for(sp in subprojs) {
        t.dependsOn gradle.includedBuild(proj).task(sp + subt)
        }
   }

   tasks.register('clean') { task ->
        deps(task, 'jvi', jvi_proj, ':clean')
   }
   ...
   tasks.register('run') {
        dependsOn gradle.includedBuild('jvi').task(':jvi-cmd:run')
   }

I thought it was weird that I had to enumerate the sub-projects, but 
some think I'm weird.


Opening this project in ide I can build, clean, Use the GREEN button 
to run the project, but the DEBUG button fails. Suggestions? IDE output:


cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run
...
> Configure project :jvi:jvi-swing
namedservicesMerge-1: project ':jvi:jvi-swing' 
'jVi/init/com.raelity.jvi.ViInitialization'

Configuration on demand is an incubating feature.

> Task :jvi:jvi-core:compileJava UP-TO-DATE
...

> Task :jvi:jvi-cmd:run

==
cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run --debug-jvm
...
> Configure project :jvi:jvi-swing
namedservicesMerge-1: project ':jvi:jvi-swing' 
'jVi/init/com.raelity.jvi.ViInitialization'

Configuration on demand is an incubating feature.

FAILURE: Build failed with an exception.

* What went wrong:
Problem configuring task :run from command line.
> Unknown command-line option '--debug-jvm'.



-
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

Re: Gradle: how to get IDE pickup source from open project

[Ernie Rael]

On 9/22/22 9:15 AM, László Kishalmi wrote:

You may find reading this one useful:
https://docs.gradle.org/current/userguide/composite_builds.html

Thanks, this looks promising. I started, only for one project, with 
settings.gradle


   rootProject.name = 'jvi-ide'

   includeBuild '/src/jvi-dev/jvi'

Mixed in some build.gradle

   def jvi_proj = [ ':jvi-core', ':jvi-swing', ':jvi-cmd' ]

   void deps(Task t, String proj, List subprojs, String subt) {
    for(sp in subprojs) {
    t.dependsOn gradle.includedBuild(proj).task(sp + subt)
    }
   }

   tasks.register('clean') { task ->
    deps(task, 'jvi', jvi_proj, ':clean')
   }
   ...
   tasks.register('run') {
    dependsOn gradle.includedBuild('jvi').task(':jvi-cmd:run')
   }

I thought it was weird that I had to enumerate the sub-projects, but 
some think I'm weird.


Opening this project in ide I can build, clean, Use the GREEN button to 
run the project, but the DEBUG button fails. Suggestions? IDE output:


cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run
...
> Configure project :jvi:jvi-swing
namedservicesMerge-1: project ':jvi:jvi-swing' 
'jVi/init/com.raelity.jvi.ViInitialization'

Configuration on demand is an incubating feature.

> Task :jvi:jvi-core:compileJava UP-TO-DATE
...

> Task :jvi:jvi-cmd:run

==
cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run --debug-jvm
...
> Configure project :jvi:jvi-swing
namedservicesMerge-1: project ':jvi:jvi-swing' 
'jVi/init/com.raelity.jvi.ViInitialization'

Configuration on demand is an incubating feature.

FAILURE: Build failed with an exception.

* What went wrong:
Problem configuring task :run from command line.
> Unknown command-line option '--debug-jvm'.


-
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

Re: Using the same userdir from previous release

[Ernie Rael]

On 9/16/22 9:09 AM, Michael Bien wrote:

On 16.09.22 17:19, Ernie Rael wrote:

On 9/15/22 10:44 PM, Michael Bien wrote:

On 16.09.22 07:31, Laszlo Kishalmi wrote:
I started to reply on this, but not sure if I really pressed the 
send button, and I do not see my reply. So I'm sorry if I'm 
repeating myself.


So the Snap distribution does exactly the same (Snap provides the 
infrastructure for that). Whenever NetBeans updated the user dir 
gets copied from the current version to the new version and an 
empty cache dir is created. 


Good to know, I'll stay with copying and keep my eyes open for 
non-compatible changes, or at least the squawking if one happens.


The huge advantage of copying the userdir is not having to install 
plugins again.


BTW, my plugin has a lot of stuff in preferences and it defines 
include/exclude in layers so it works well with the "Tools > Options 
> Import/Export" buttons. But since it is not in the release compiled 
layers...


yeah this area needs some improvements. I see periodically issues when 
users import plugins from old NB versions (e.g 11) and break things. 
(its probably nb-javac, since it changed namespace at some point which 
allows it to be installed twice, resetting the config fixes it).
I use some plugins, like quickfilechooser and form-binding, which are 
from 8.2.


So there needs to be some cap. e.g nb_version - 2. But first of all, 
the plugin portal probably needs to be fixed (i believe someone is 
working on it), so that it isn't empty on new releases when most 
people update.


I haven't seen any comments on it being fixed, just hopes and prayers. 
Is there a spec/proposal for the changes? Is the plugin portal part of 
the apache netbeans project?




The import/export module config might be stored somewhere in the 
module. If it is, it could automatically migrate the stable config on 
plugin import from an older config. Since you say it works with the 
explicit import/export via options but not with the auto import on 
first start? 


It does work on initial import (I just tried again to make sure), my 
comment were based on not understanding how the netbeans.import file works.


-ernie


If true, this is either a bug or a missing feature since I don't see 
why it would behave differently :)


best regards,

michael



Thanks for the info,
-ernie

It is relatively safe to do that in the last few years, no one 
really touched the config settings part.


The import from previous version does the same, however it has some 
rules importing from NetBeans 5.5, 6.0, pretty old versions 
(probably we can remove that code).


it should use the include/exclude list in etc/netbeans.import, which 
is generated by the layer at build time ("OptionsExport" folder).


I didn't know that either but I figured this out when I added the 
migration of the jackpot rule files so I didn't have to copy them 
manually.


So you can influence what is migrated simply by editing this file 
before first launch :)


-mbien



On 9/15/22 10:34, Ernie Rael wrote:

On 9/14/22 5:55 PM, Michael Bien wrote:


On 10.09.22 01:53, Ernie Rael wrote:

With release 15 I did something like

   mkdir 15
   cp -a 14/userdir 15/userdir

Then start NetBeans-15 using 15/userdir and a fresh cachedir.

Simpler than import settings. Is there any problem/downside 
doing this?


the downside is that NB doesn't expect this to happen. So it 
might work, or it might break (something). Since the config 
format might have changed somewhere in between versions.


Yeah. And if it mostly works, that's the worst.



If you would just start NB 15 normally without a 15 folder, it 
will ask you to migrate some of the config of 14.


I've had a non-standard setup/directories since windows days; 
can't remember why exactly; maybe just cause I thought it sucked 
on windows. Kept it when I moved to linux last year. Have my own 
startup scripts.


I looked for  a --initial-startup-import-from option, couldn't 
find it :-)


Is it the same (or close enough) to use "Tools > Options > 
Import", and grab everything from the prev userdir on first 
startup? Don't think it is, but it might be after installing 
favorite plugins, so what to import is defined.


Making a symlink got it too work. "cd ~/.netbeans; ln -s 
~/.nb/.../prevudir 15" works. Something to add to my install new 
NB process. This seems to pull everything from Preferences, even 
if the plugins aren't installed yet.


Thanks for waving me off use prev udir,
-ernie



It will import settings like project groups, platforms, editor 
config (even custom jackpot rules now), theme etc. but window 
setup for example is reset. Thats usually how I upgrade - setting 
up the windows again is only a few clicks, most of the rest is 
already migrated.


I actually wanted to take a look if it would be feasible to 
migrate some of the window setup too, have that somewhere on my 
TOD

Re: Using the same userdir from previous release

[Ernie Rael]

On 9/15/22 10:44 PM, Michael Bien wrote:

On 16.09.22 07:31, Laszlo Kishalmi wrote:
I started to reply on this, but not sure if I really pressed the send 
button, and I do not see my reply. So I'm sorry if I'm repeating myself.


So the Snap distribution does exactly the same (Snap provides the 
infrastructure for that). Whenever NetBeans updated the user dir gets 
copied from the current version to the new version and an empty cache 
dir is created. 


Good to know, I'll stay with copying and keep my eyes open for 
non-compatible changes, or at least the squawking if one happens.


The huge advantage of copying the userdir is not having to install 
plugins again.


BTW, my plugin has a lot of stuff in preferences and it defines 
include/exclude in layers so it works well with the "Tools > Options > 
Import/Export" buttons. But since it is not in the release compiled 
layers...


Thanks for the info,
-ernie

It is relatively safe to do that in the last few years, no one really 
touched the config settings part.


The import from previous version does the same, however it has some 
rules importing from NetBeans 5.5, 6.0, pretty old versions (probably 
we can remove that code).


it should use the include/exclude list in etc/netbeans.import, which 
is generated by the layer at build time ("OptionsExport" folder).


I didn't know that either but I figured this out when I added the 
migration of the jackpot rule files so I didn't have to copy them 
manually.


So you can influence what is migrated simply by editing this file 
before first launch :)


-mbien



On 9/15/22 10:34, Ernie Rael wrote:

On 9/14/22 5:55 PM, Michael Bien wrote:


On 10.09.22 01:53, Ernie Rael wrote:

With release 15 I did something like

   mkdir 15
   cp -a 14/userdir 15/userdir

Then start NetBeans-15 using 15/userdir and a fresh cachedir.

Simpler than import settings. Is there any problem/downside doing 
this?


the downside is that NB doesn't expect this to happen. So it might 
work, or it might break (something). Since the config format might 
have changed somewhere in between versions.


Yeah. And if it mostly works, that's the worst.



If you would just start NB 15 normally without a 15 folder, it will 
ask you to migrate some of the config of 14.


I've had a non-standard setup/directories since windows days; can't 
remember why exactly; maybe just cause I thought it sucked on 
windows. Kept it when I moved to linux last year. Have my own 
startup scripts.


I looked for  a --initial-startup-import-from option, couldn't find 
it :-)


Is it the same (or close enough) to use "Tools > Options > Import", 
and grab everything from the prev userdir on first startup? Don't 
think it is, but it might be after installing favorite plugins, so 
what to import is defined.


Making a symlink got it too work. "cd ~/.netbeans; ln -s 
~/.nb/.../prevudir 15" works. Something to add to my install new NB 
process. This seems to pull everything from Preferences, even if the 
plugins aren't installed yet.


Thanks for waving me off use prev udir,
-ernie



It will import settings like project groups, platforms, editor 
config (even custom jackpot rules now), theme etc. but window setup 
for example is reset. Thats usually how I upgrade - setting up the 
windows again is only a few clicks, most of the rest is already 
migrated.


I actually wanted to take a look if it would be feasible to migrate 
some of the window setup too, have that somewhere on my TODO list, 
but never looked into it.


-mbien



-ernie


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

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/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







-
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






-
To unsu

Re: Using the same userdir from previous release

[Ernie Rael]

On 9/14/22 5:55 PM, Michael Bien wrote:


On 10.09.22 01:53, Ernie Rael wrote:

With release 15 I did something like

   mkdir 15
   cp -a 14/userdir 15/userdir

Then start NetBeans-15 using 15/userdir and a fresh cachedir.

Simpler than import settings. Is there any problem/downside doing this?


the downside is that NB doesn't expect this to happen. So it might 
work, or it might break (something). Since the config format might 
have changed somewhere in between versions.


Yeah. And if it mostly works, that's the worst.



If you would just start NB 15 normally without a 15 folder, it will 
ask you to migrate some of the config of 14.


I've had a non-standard setup/directories since windows days; can't 
remember why exactly; maybe just cause I thought it sucked on windows. 
Kept it when I moved to linux last year. Have my own startup scripts.


I looked for  a --initial-startup-import-from option, couldn't find it :-)

Is it the same (or close enough) to use "Tools > Options > Import", and 
grab everything from the prev userdir on first startup? Don't think it 
is, but it might be after installing favorite plugins, so what to import 
is defined.


Making a symlink got it too work. "cd ~/.netbeans; ln -s 
~/.nb/.../prevudir 15" works. Something to add to my install new NB 
process. This seems to pull everything from Preferences, even if the 
plugins aren't installed yet.


Thanks for waving me off use prev udir,
-ernie



It will import settings like project groups, platforms, editor config 
(even custom jackpot rules now), theme etc. but window setup for 
example is reset. Thats usually how I upgrade - setting up the windows 
again is only a few clicks, most of the rest is already migrated.


I actually wanted to take a look if it would be feasible to migrate 
some of the window setup too, have that somewhere on my TODO list, but 
never looked into it.


-mbien



-ernie


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

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/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







-
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

fix needs review (undo/redo don't work is part of the issue)

[Ernie Rael]

The bug

   Editor with Keyboard focus is not active TopComponent (undo/redo
   don't work while editing)#4437
   https://github.com/apache/netbeans/issues/4437

Has a fix

   Keyboard focus can activate top component #4603
   https://github.com/apache/netbeans/pull/4603

which needs review. It's a small patch to core.windows. Anyone with some 
familiarity of this area who can take a look at this small patch?


-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

Re: Sudden File Lock Freeze

[Ernie Rael]

There a program that will tell you what windows processes have a given 
file open, maybe other info about the file. That might be informative.


-ernie

(I'm rushed, can't look for it now)


On 9/13/22 7:20 AM, Ömer Halit Çizmeci wrote:

Well. It is still a possibility but I doubt that because it's a high end
new PC. If that ever happens again, do you need me to do anything
specifically? Just keep in mind that NetBeans does not respond at all.

On Tue, Sep 13, 2022, 5:16 PM Eirik Bakke  wrote:


One possibility--perhaps less likely than a bug in NetBeans, but still
worth considering--is a failing hard drive or SSD drive. It might be a good
time to take a backup of your files, just in case.

-- Eirik

-Original Message-
From: Ömer Halit Çizmeci 
Sent: Tuesday, September 13, 2022 2:50 AM
To: dev@netbeans.apache.org
Subject: Re: Sudden File Lock Freeze

I only encountered this while editing .java files but I am not sure if it
is file type specific. It is part of a Java Web Application project file
and I can guarantee that the file is not opened in any other application. I
don't have any antivirus program other than Windows Defender and I don't
have a virus on my computer.

On Tue, Sep 13, 2022, 4:58 AM Laszlo Kishalmi 
wrote:


One of the most important information is missing.

What type of file are you editing?

On 9/12/22 17:01, Ömer Halit Çizmeci wrote:

Hi,

I have been having this problem I think since NB13 and it occurs in
NB14 and NB15. The application suddenly freezes entirely with no
response at

all

when I hit CTRL+S to save a file. There is no pattern I could figure
out but when this happens, it is extremely hard to revert it back to

normal.

Restarting NetBeans does not help. Restarting my PC does not help.

Whenever

I save on that specific file, NetBeans freezes immediately and the
only

way

is to force close in task manager.

After this incident repeat so many times, I had to look for a

workaround.

The only way I was able to resume NetBeans without having to force
close was to navigate to the file via file explorer and rename that
specific file. Then NB would pop-up the file modified outside of NB
and ask if I want to reload. After this point, NB continues to run
as normal but if I hit CTRL+S again on that file, NB will freeze.
And restarting Windows or NetBeans does not help.

After a long time of investigating, I was able to find a way to fix
it

for

that moment. I'd open that specific file in Notepad and make a
slight modification and save it. Then NetBeans is able to save on
that file and runs normally until this random bug appears. It is
like the file is

locked

by another process and NetBeans cannot get hold of that file and

freezes.

This happens randomly with random files.

This happens in Windows 10 and Windows 11 using NB15 with Java 17.

What else should I provide to contribute to this?


-
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

Re: Plugin/Code donation

[Ernie Rael]

On 9/7/22 12:33 AM, Christian Pervoelz wrote:

But as I think, the features are too good to be just thrown away, I'd like
to donate the code.


Perhaps they could find a home at 
https://github.com/mbien/jackpot-inspections


-ernie


Hello everybody,

while cleaning up my repos on GitHub I found a plugin I wrote a couple of
years ago:
https://github.com/ChristianPervoelz/netbeans-java-hints
(See details below or in the repo itself)

*Function:* Checking some aspects of code quality.

- Cognitive Complexity
- Statement nesting
- too many return statements in a method
- too many break/continue statements in a loop

*State*:

- At least in NB 12.6 it used to work pretty well
- worked with Java 14 (and below)

*License:* APL 2.0

For some reasons, I don't have the time (and the desire) to create a plugin
available via the portal.
But as I think, the features are too good to be just thrown away, I'd like
to donate the code.

How could I do that? Which steps are required from my side? Is it possible
at all?

Best regards
-- C.




-
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