Re: Java Call Hierarchy Bug?
Any further feedback on this? Mitch On 6/14/24 12:30, Mitch Claborn wrote: See attached zip file with minimal source and a screen shot of what I see in the Java Call Hierarchy output. I contend that test1()::Test1 should not appear in the output, because it is not a caller of getFullSku()::OrderDetail which is stated (or at least strongly implied) in the hierarchy display. The display would be accurate if the 2nd line was getFullSku()::IOrderItem. It would be considerably more useful in my situation if the 2nd line remained as shown and the results only included uses of getFullSku()::OrderDetail. Mitch On 6/14/24 12:02, Pieter van den Hombergh wrote: add the full code of hierarchy and caller or at least a minimal working example. at first glance I see nothing odd here. Maybe a matter of misunderstanding? met vriendelijke groet Pieter van den Hombergh Op vr 14 jun 2024, 18:10 schreef Mitch Claborn <mailto:mitch...@claborn.net>>: See details below. This seems like a bug. Do you agree? Want to confirm before I file a bug report. Class OrderDetailBase defines method: public String getSku(). I am doing a Java Call Hierarchy on this method. Class OrderDetail is a subclass of OrderDetailBase and defines this method that calls getSku(): public String getFullSku(). This method is also defined in interface IOrderItem which is implemented by OrderDetail. Cart is another class that implements IOrderItem. The Java Call Hierarchy display shows this: level 0: OrderDetailBase.getSku() level 1: OrderDetail.getFullSku() level 2: a usage of Cart.getFullSku() This level 2 entry seems like the bug. It shouldn't be showing usages of Cart.getFullSku(), only OrderDetail.getFullSku(). I'm guessing that the Hierarchy display is showing uses of IOrderItem.getFullSku() rather than OrderDetail.getFullSku(). -- Mitch - To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org <mailto:users-unsubscr...@netbeans.apache.org> For additional commands, e-mail: users-h...@netbeans.apache.org <mailto:users-h...@netbeans.apache.org> For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists <https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists> - 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: 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
Re: Java Call Hierarchy Bug?
See attached zip file with minimal source and a screen shot of what I
see in the Java Call Hierarchy output. I contend that test1()::Test1
should not appear in the output, because it is not a caller of
getFullSku()::OrderDetail which is stated (or at least strongly implied)
in the hierarchy display.
The display would be accurate if the 2nd line was getFullSku()::IOrderItem.
It would be considerably more useful in my situation if the 2nd line
remained as shown and the results only included uses of
getFullSku()::OrderDetail.
Mitch
On 6/14/24 12:02, Pieter van den Hombergh wrote:
add the full code of hierarchy and caller or at least a minimal working
example.
at first glance I see nothing odd here. Maybe a matter of misunderstanding?
met vriendelijke groet
Pieter van den Hombergh
Op vr 14 jun 2024, 18:10 schreef Mitch Claborn <mailto:mitch...@claborn.net>>:
See details below. This seems like a bug. Do you agree? Want to confirm
before I file a bug report.
Class OrderDetailBase defines method: public String getSku(). I am
doing
a Java Call Hierarchy on this method.
Class OrderDetail is a subclass of OrderDetailBase and defines this
method that calls getSku(): public String getFullSku(). This method is
also defined in interface IOrderItem which is implemented by
OrderDetail.
Cart is another class that implements IOrderItem.
The Java Call Hierarchy display shows this:
level 0: OrderDetailBase.getSku()
level 1: OrderDetail.getFullSku()
level 2: a usage of Cart.getFullSku()
This level 2 entry seems like the bug. It shouldn't be showing
usages of
Cart.getFullSku(), only OrderDetail.getFullSku(). I'm guessing that the
Hierarchy display is showing uses of IOrderItem.getFullSku() rather
than
OrderDetail.getFullSku().
--
Mitch
-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
<mailto:users-unsubscr...@netbeans.apache.org>
For additional commands, e-mail: users-h...@netbeans.apache.org
<mailto:users-h...@netbeans.apache.org>
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
<https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists>
<>
-
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
Re: Java Call Hierarchy Bug?
add the full code of hierarchy and caller or at least a minimal working example. at first glance I see nothing odd here. Maybe a matter of misunderstanding? met vriendelijke groet Pieter van den Hombergh Op vr 14 jun 2024, 18:10 schreef Mitch Claborn : > See details below. This seems like a bug. Do you agree? Want to confirm > before I file a bug report. > > Class OrderDetailBase defines method: public String getSku(). I am doing > a Java Call Hierarchy on this method. > > Class OrderDetail is a subclass of OrderDetailBase and defines this > method that calls getSku(): public String getFullSku(). This method is > also defined in interface IOrderItem which is implemented by OrderDetail. > > Cart is another class that implements IOrderItem. > > The Java Call Hierarchy display shows this: > level 0: OrderDetailBase.getSku() > level 1: OrderDetail.getFullSku() > level 2: a usage of Cart.getFullSku() > > This level 2 entry seems like the bug. It shouldn't be showing usages of > Cart.getFullSku(), only OrderDetail.getFullSku(). I'm guessing that the > Hierarchy display is showing uses of IOrderItem.getFullSku() rather than > OrderDetail.getFullSku(). > > > -- > Mitch > > - > 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 > >
Java Call Hierarchy Bug?
See details below. This seems like a bug. Do you agree? Want to confirm before I file a bug report. Class OrderDetailBase defines method: public String getSku(). I am doing a Java Call Hierarchy on this method. Class OrderDetail is a subclass of OrderDetailBase and defines this method that calls getSku(): public String getFullSku(). This method is also defined in interface IOrderItem which is implemented by OrderDetail. Cart is another class that implements IOrderItem. The Java Call Hierarchy display shows this: level 0: OrderDetailBase.getSku() level 1: OrderDetail.getFullSku() level 2: a usage of Cart.getFullSku() This level 2 entry seems like the bug. It shouldn't be showing usages of Cart.getFullSku(), only OrderDetail.getFullSku(). I'm guessing that the Hierarchy display is showing uses of IOrderItem.getFullSku() rather than OrderDetail.getFullSku(). -- Mitch - 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
Glassfish Java DB
I am trying to start Java DB from Glassfish 7.0.14, but it hangs, nothing happens. Has somebody got it working? - 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
Re: Can;t link src/test/java to package being tested.
Thanks. Almost there.
Sigh. You were correct. There were two main programs. One was deleted
leaving the main main.
I tried right-click->Debug and it worked.
I tried Debug->File and it worked.
I tried Debug->Main Program and it did not work. The error is:
ERROR: transport error 202: connect failed: Connection refused
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports
initialized
[t:\workspace\open\src\jdk.jdwp.agent\share\native\libjdwp\debugInit.c:734]
Command execution failed.
I changed com.mycompany.slip.Slip to
test.main On the first version, Debug
gave me a pom error saying it could not find the main file. On the
second version I got the above error. My guess is that I' m going to
have to read and understand Maven and relate Maven to some required
folder architecture. I'm not sure about this. Right now it's only a guess.
I would like to use the debugged API in other projects, so the issue is
persistent and important. Any help would be good. No help just means
that I have to struggle through documentation to find the little nugget
needed to make the project work as expected. And yeah, I know. This is
one of those 'easy' ones that everyone knows.
art
On 4/2/2024 11:28 AM, Michael Bien wrote:
the exec.mainClass property of pom.xml is the main entry point of your
program and becomes relevant if you want to run the project in the
shell or once its built.
NB can run anything which has a main method or any test simply via
right click -> run/debug. It doesn't really care what is in the
property so you don't have to permanently change it just so that you
can test something. You can even remove it and it will run fine if you
press play.
My guess is that you ran the project once and NB asked you what Main
class to start (do you have two?). The default setting of the dialog
remembers the choice for the rest of the session and won't ask again.
Then you moved or renamed the class and now it can't find it, NB
should ask again if you restart.
-mbien
On 02.04.24 20:19, slipbits wrote:
Thanks Tamás;
I didn't know that and I'm glad you mentioned it. But the real
question is how do I test the fool thing. I compiled everything
successfully under NB. I built everything successfully under NB. Now
here is where my ignorance shows. I don't want the fool thing located
under "com.mycompany.slip.Slip". I know that this is referenced in
the pom.xml file, but, if I change the pom entry my question is what
do I have to do to the source folders? Going from
com.mycompany.slip.Slip to
Slip will this work and do I have to
change the folder structure in some way? Or quite baldly, 'what do I
do now coach"?
I'm reading the Maven document to find out how changing
effects the folder architecture but a little word of
wisdom would save me a lot of time.
thanks
The run output dialog is below.
JPDA Listening Start...
JPDA Address: 127.0.0.1:52253
Port:52253
cd D:\home\skidmarks\Projects\Unique\Project\slip;
"JAVA_HOME=C:\\Program Files\\Java\\jdk-17.0.1" cmd /c "\"C:\\Program
Files\\NetBeans\\NetBeans-20\\netbeans\\java\\maven\\bin\\mvn.cmd\"
-Dexec.vmArgs=-agentlib:jdwp=transport=dt_socket,server=n,address=52253
\"-Dexec.args=${exec.vmArgs} -classpath %classpath ${exec.mainClass}
${exec.appArgs}\" -Dexec.appArgs=
-Dexec.mainClass=com.mycompany.slip.Slip
\"-Dexec.executable=C:\\Program
Files\\Java\\jdk-17.0.1\\bin\\java.exe\" -Djpda.listen=true
-Djpda.address=52253 \"-Dmaven.ext.class.path=C:\\Program
Files\\NetBeans\\NetBeans-20\\netbeans\\java\\maven-nblib\\netbeans-eventspy.jar\"
-Dfile.encoding=UTF-8 process-classes
org.codehaus.mojo:exec-maven-plugin:3.1.0:exec"
Scanning for projects...
-< com.slipbits:slip >--
Building slip 1.0-SNAPSHOT
from pom.xml
[ jar ]-
--- resources:3.3.1:resources (default-resources) @ slip ---
skip non existing resourceDirectory
D:\home\skidmarks\Projects\Unique\Project\slip\src\main\resources
--- compiler:3.11.0:compile (default-compile) @ slip ---
Nothing to compile - all classes are up to date
--- exec:3.1.0:exec (default-cli) @ slip ---
Error: Could not find or load main class com.mycompany.slip.Slip
Caused by: java.lang.ClassNotFoundException: com.mycompany.slip.Slip
Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an
error: 1 (Exit value: 1)
at org.apache.commons.exec.DefaultExecutor.executeInternal
(DefaultExecutor.java:404)
at org.apache.commons.exec.DefaultExecutor.execute
(DefaultExecutor.java:166)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine
(ExecMojo.java:1000)
at org.codehaus.mojo.exec.ExecMojo.executeComman
Re: Can;t link src/test/java to package being tested.
the exec.mainClass property of pom.xml is the main entry point of your
program and becomes relevant if you want to run the project in the shell
or once its built.
NB can run anything which has a main method or any test simply via right
click -> run/debug. It doesn't really care what is in the property so
you don't have to permanently change it just so that you can test
something. You can even remove it and it will run fine if you press play.
My guess is that you ran the project once and NB asked you what Main
class to start (do you have two?). The default setting of the dialog
remembers the choice for the rest of the session and won't ask again.
Then you moved or renamed the class and now it can't find it, NB should
ask again if you restart.
-mbien
On 02.04.24 20:19, slipbits wrote:
Thanks Tamás;
I didn't know that and I'm glad you mentioned it. But the real
question is how do I test the fool thing. I compiled everything
successfully under NB. I built everything successfully under NB. Now
here is where my ignorance shows. I don't want the fool thing located
under "com.mycompany.slip.Slip". I know that this is referenced in the
pom.xml file, but, if I change the pom entry my question is what do I
have to do to the source folders? Going from
com.mycompany.slip.Slip to
Slip will this work and do I have to
change the folder structure in some way? Or quite baldly, 'what do I
do now coach"?
I'm reading the Maven document to find out how changing
effects the folder architecture but a little word of
wisdom would save me a lot of time.
thanks
The run output dialog is below.
JPDA Listening Start...
JPDA Address: 127.0.0.1:52253
Port:52253
cd D:\home\skidmarks\Projects\Unique\Project\slip;
"JAVA_HOME=C:\\Program Files\\Java\\jdk-17.0.1" cmd /c "\"C:\\Program
Files\\NetBeans\\NetBeans-20\\netbeans\\java\\maven\\bin\\mvn.cmd\"
-Dexec.vmArgs=-agentlib:jdwp=transport=dt_socket,server=n,address=52253
\"-Dexec.args=${exec.vmArgs} -classpath %classpath ${exec.mainClass}
${exec.appArgs}\" -Dexec.appArgs=
-Dexec.mainClass=com.mycompany.slip.Slip
\"-Dexec.executable=C:\\Program
Files\\Java\\jdk-17.0.1\\bin\\java.exe\" -Djpda.listen=true
-Djpda.address=52253 \"-Dmaven.ext.class.path=C:\\Program
Files\\NetBeans\\NetBeans-20\\netbeans\\java\\maven-nblib\\netbeans-eventspy.jar\"
-Dfile.encoding=UTF-8 process-classes
org.codehaus.mojo:exec-maven-plugin:3.1.0:exec"
Scanning for projects...
-< com.slipbits:slip >--
Building slip 1.0-SNAPSHOT
from pom.xml
[ jar ]-
--- resources:3.3.1:resources (default-resources) @ slip ---
skip non existing resourceDirectory
D:\home\skidmarks\Projects\Unique\Project\slip\src\main\resources
--- compiler:3.11.0:compile (default-compile) @ slip ---
Nothing to compile - all classes are up to date
--- exec:3.1.0:exec (default-cli) @ slip ---
Error: Could not find or load main class com.mycompany.slip.Slip
Caused by: java.lang.ClassNotFoundException: com.mycompany.slip.Slip
Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an
error: 1 (Exit value: 1)
at org.apache.commons.exec.DefaultExecutor.executeInternal
(DefaultExecutor.java:404)
at org.apache.commons.exec.DefaultExecutor.execute
(DefaultExecutor.java:166)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine
(ExecMojo.java:1000)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine
(ExecMojo.java:947)
at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:471)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:328)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:316)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:174)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
(MojoExecutor.java:75)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
(MojoExecutor.java:162)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
(DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:159)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:105)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:73)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:53)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStar
Re: Can;t link src/test/java to package being tested.
Thanks Tamás;
I didn't know that and I'm glad you mentioned it. But the real question
is how do I test the fool thing. I compiled everything successfully
under NB. I built everything successfully under NB. Now here is where my
ignorance shows. I don't want the fool thing located under
"com.mycompany.slip.Slip". I know that this is referenced in the pom.xml
file, but, if I change the pom entry my question is what do I have to do
to the source folders? Going from
com.mycompany.slip.Slip to
Slip will this work and do I have to
change the folder structure in some way? Or quite baldly, 'what do I do
now coach"?
I'm reading the Maven document to find out how changing
effects the folder architecture but a little word of wisdom would save
me a lot of time.
thanks
The run output dialog is below.
JPDA Listening Start...
JPDA Address: 127.0.0.1:52253
Port:52253
cd D:\home\skidmarks\Projects\Unique\Project\slip;
"JAVA_HOME=C:\\Program Files\\Java\\jdk-17.0.1" cmd /c "\"C:\\Program
Files\\NetBeans\\NetBeans-20\\netbeans\\java\\maven\\bin\\mvn.cmd\"
-Dexec.vmArgs=-agentlib:jdwp=transport=dt_socket,server=n,address=52253
\"-Dexec.args=${exec.vmArgs} -classpath %classpath ${exec.mainClass}
${exec.appArgs}\" -Dexec.appArgs=
-Dexec.mainClass=com.mycompany.slip.Slip \"-Dexec.executable=C:\\Program
Files\\Java\\jdk-17.0.1\\bin\\java.exe\" -Djpda.listen=true
-Djpda.address=52253 \"-Dmaven.ext.class.path=C:\\Program
Files\\NetBeans\\NetBeans-20\\netbeans\\java\\maven-nblib\\netbeans-eventspy.jar\"
-Dfile.encoding=UTF-8 process-classes
org.codehaus.mojo:exec-maven-plugin:3.1.0:exec"
Scanning for projects...
-< com.slipbits:slip >--
Building slip 1.0-SNAPSHOT
from pom.xml
[ jar ]-
--- resources:3.3.1:resources (default-resources) @ slip ---
skip non existing resourceDirectory
D:\home\skidmarks\Projects\Unique\Project\slip\src\main\resources
--- compiler:3.11.0:compile (default-compile) @ slip ---
Nothing to compile - all classes are up to date
--- exec:3.1.0:exec (default-cli) @ slip ---
Error: Could not find or load main class com.mycompany.slip.Slip
Caused by: java.lang.ClassNotFoundException: com.mycompany.slip.Slip
Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error:
1 (Exit value: 1)
at org.apache.commons.exec.DefaultExecutor.executeInternal
(DefaultExecutor.java:404)
at org.apache.commons.exec.DefaultExecutor.execute
(DefaultExecutor.java:166)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine
(ExecMojo.java:1000)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine
(ExecMojo.java:947)
at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:471)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:328)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:316)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:174)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
(MojoExecutor.java:75)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
(MojoExecutor.java:162)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
(DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:159)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:105)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:73)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:53)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:118)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native
Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:77)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:568)
at org
Re: Can;t link src/test/java to package being tested.
Howdy, src/main/java and src/test/java is the maven standard... T On Tue, Apr 2, 2024, 19:46 slipbits wrote: > I know this is a dumb question but I'm stumped. I created a new project > and NB created src/main and src/test subdirectories. When I created my test > code in src/test/... NB recognized the main package and I could link to it > i n the editor and run compiles. But when I try to execute in in the > debugger (debug->run) it fails to load because it can't find the main > package. > > The project is a maven project, and I am beginning to read the maven > material to see if that will help. But, can you shortcut the process and > please tell me how to correct the issue and give me a hint as to where I > can look for additional resources. > > thatnks >
Can;t link src/test/java to package being tested.
I know this is a dumb question but I'm stumped. I created a new project and NB created src/main and src/test subdirectories. When I created my test code in src/test/... NB recognized the main package and I could link to it i n the editor and run compiles. But when I try to execute in in the debugger (debug->run) it fails to load because it can't find the main package. The project is a maven project, and I am beginning to read the maven material to see if that will help. But, can you shortcut the process and please tell me how to correct the issue and give me a hint as to where I can look for additional resources. thatnks
Java Import NetBeans 21
Hey, as of NetBeans 21 I have some Java classes that hitherto have been fine on using the “Fix All Imports” command SHIFT+COMMAND+I now always wanting to import “com.google<http://com.google>.protobuf.JavaFeaturesProto.java”. Any idea on why this might be? The project is maven 3.8.8, Java 11 based. Thanks Chris Product Version: Apache NetBeans IDE 21 Java: 21.0.2; Java HotSpot(TM) 64-Bit Server VM 21.0.2+13-LTS-58 Runtime: Java(TM) SE Runtime Environment 21.0.2+13-LTS-58 System: Mac OS X version 14.3.1 running on aarch64; UTF-8; en_GB (nb) [Screenshot 2024-03-22 at 16.51.35.png]
How to activate "Java Web and EE" plugin ?
Hello again, I'm trying to activate the Java Web and EE plugin in NetBeans 21. I have activated the "HTML5", "PHP", and "Base IDE", but the button "Activate" for the "Java Web and EE" plugin is disabled. I'm working with the "OpenJDK 21.0.2" in "Ubuntu 22.04.4". Thank you in advance for any suggestions. Klerman.
No new project from "Java Project from existing Sources"
Hi, I have old java sources, which I want to work on with NetBeans 21. Location of the existing sources is: ~/Projects/Palm/NetbeansProjects/DesktopFiles_src/ Location for the new project is: ~/Projects/Palm/NetbeansProjects/DesktopFiles/ So these are separate paths, but I get: ! Project Folder has to be located outside of the folder containing packages. So what I'm doing wrong? -Ulf - 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
No new project from "Java Project from existing Sources"
Hi, I have old java sources, which I want to work on with NetBeans 21. Location of the existing sources is: ~/Projects/Palm/NetbeansProjects/DesktopFiles_src/ Location for the new project is: ~/Projects/Palm/NetbeansProjects/DesktopFiles/ So these are separate paths, but I get: ! Project Folder has to be located outside of the folder containing packages. So what I'm doing wrong? -Ulf - 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
Re: Netbeans 21 always showing wrong Java dependency for Maven project
Hi Michael, thanks for your answer. On 2024/02/28 14:40:34 Michael Bien wrote: > Hi, > > On 28.02.24 11:23, Francesco Chicchiriccò wrote: > > Hi there, > > I am using Netbeans since 6.0 and still enjoying it as main > > development platform for Java: nice job! > > > > I am experiencing an annoying behavior with Maven projects: even > > though JDK 21 is correctly reported under project properties -> > > sources -> source/binary format and also under build -> compile (as > > set by Maven's pom.xml), Netbeans keeps showing JDK 11 under Java > > dependencies. > > I can reproduce this, switching JDKs doesn't update the tree under "Java > Dependencies". Reopening the project or restarting NB does fix it - so > this looks like a (UI only?) bug, however: > > > > The unwanted consequence of this is that I can only browse JDK 11 > > sources when CTRL + clicking on my project's sources. > > this I can't reproduce. It always navigated to the right JDK sources. > Building/running the project does also use the JDK selected in project > properties. > > If you create a brand new maven project using the standard template, > does the same problem occur? I confirm that with a brand new maven project it navigates to the JDK sources as defined in project properties. This issue is occurring to me with Apache Syncope sources, for any of the submodules - maybe because it is multi-module or because it defines some properties / plugins that are interfering? FTR I was able to finally browse JDK 21 sources after setting back to "JDK 21 (Default)" the configuration under Tools -> Java -> Maven -> Default JDK Regards. > > I have both platforms correctly defined, including sources. > > Netbeans itself runs on JDK 21. > > > > What could be the issue? TIA > > Regards. - 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
Re: Netbeans 21 always showing wrong Java dependency for Maven project
Hi, On 28.02.24 11:23, Francesco Chicchiriccò wrote: Hi there, I am using Netbeans since 6.0 and still enjoying it as main development platform for Java: nice job! I am experiencing an annoying behavior with Maven projects: even though JDK 21 is correctly reported under project properties -> sources -> source/binary format and also under build -> compile (as set by Maven's pom.xml), Netbeans keeps showing JDK 11 under Java dependencies. I can reproduce this, switching JDKs doesn't update the tree under "Java Dependencies". Reopening the project or restarting NB does fix it - so this looks like a (UI only?) bug, however: The unwanted consequence of this is that I can only browse JDK 11 sources when CTRL + clicking on my project's sources. this I can't reproduce. It always navigated to the right JDK sources. Building/running the project does also use the JDK selected in project properties. If you create a brand new maven project using the standard template, does the same problem occur? -mbien I have both platforms correctly defined, including sources. Netbeans itself runs on JDK 21. What could be the issue? TIA Regards. - 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
Netbeans 21 always showing wrong Java dependency for Maven project
Hi there, I am using Netbeans since 6.0 and still enjoying it as main development platform for Java: nice job! I am experiencing an annoying behavior with Maven projects: even though JDK 21 is correctly reported under project properties -> sources -> source/binary format and also under build -> compile (as set by Maven's pom.xml), Netbeans keeps showing JDK 11 under Java dependencies. The unwanted consequence of this is that I can only browse JDK 11 sources when CTRL + clicking on my project's sources. I have both platforms correctly defined, including sources. Netbeans itself runs on JDK 21. What could be the issue? TIA Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/ - 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
Re: Java DB
You can probably install the Derby drivers from here: https://db.apache.org/derby/derby_downloads.html On 2/3/24 12:34, Tom wrote: Hi, I am trying to connec to the Glassfish Java DB sample database. I am getting this error message: Unable to connect. Connection failed: Unable to find a suitable driver (jdbc:derby:/localhost:1527/sample using org.apache.derby.jdbc.ClientDriver). How can I fix that? I have tried different Netbeans versions and I am getting always the same error.
Java DB
Hi, I am trying to connec to the Glassfish Java DB sample database. I am getting this error message: Unable to connect. Connection failed: Unable to find a suitable driver (jdbc:derby:/localhost:1527/sample using org.apache.derby.jdbc.ClientDriver). How can I fix that? I have tried different Netbeans versions and I am getting always the same error.
Re: Apache NetBeans 20 released - Java Versions
If this is at NB startup…Not sure if this has changed in newer NB versions but in the Netbean folders etc/netbeans.conf the default netbeans_jdkhome in use property points to default jdk version that NB runs on. (1). It’s also possible to specify the location from command line when starting NB. Believe this is the version NB is running on (which should at minimum be compatible with version that NB was built with). Not to be confused with the Project Java property in use or the available installed Java Platforms. As I recall, Java 8 was the last non-openjdk release by Oracle after which the release process and cadence change with emphasis on openjdk (open source based). Oracle still offers security updates (especially if there is a support contract) but many of the older versions are reaching End Of Life (EOL). Java 8 I believe is the last version with Java with update monitoring; I believe this was removed or not actively supported in the openjdk version. Reference (1) https://stackoverflow.com/questions/6950960/how-can-i-set-the-jdk-netbeans-runs-on Eric Bresie ebre...@gmail.com On Thu, Dec 21, 2023 at 6:17 AM Michael Bien wrote: > On 21.12.23 13:01, Judi Rastall wrote: > > > One small niggle remains: when I start NB20, it complains it cannot find > JDK8 and can it use the default. I click 'yes' and all is well. I have > found how to point NB to JDK21 at project level but I cannot find a way to > switch this at global level. Is there an environment variable I need to > know about here? > > projects can use JDKs other than the JDK NetBeans itself is running on. So > what happened there most likely was that NetBeans told you that the JDK the > project was configured to use, wasn't there anymore after you uninstalled > it and it is going to use the default JDK as fallback. The "default JDK" is > the JDK NetBeans is running on. > > You can select the JDK in the project properties window (right click on > project -> properties). > > Registering new JDKs would be via tools -> java platforms as previously > mentioned. > > > but this sounds to me like you don't have to do anything, NB probably > simply set it to the default which would be JDK 21 you just installed. > > -mbien > > > >
Re: Apache NetBeans 20 released - Java Versions
On 21.12.23 13:01, Judi Rastall wrote: One small niggle remains: when I start NB20, it complains it cannot find JDK8 and can it use the default. I click 'yes' and all is well. I have found how to point NB to JDK21 at project level but I cannot find a way to switch this at global level. Is there an environment variable I need to know about here? projects can use JDKs other than the JDK NetBeans itself is running on. So what happened there most likely was that NetBeans told you that the JDK the project was configured to use, wasn't there anymore after you uninstalled it and it is going to use the default JDK as fallback. The "default JDK" is the JDK NetBeans is running on. You can select the JDK in the project properties window (right click on project -> properties). Registering new JDKs would be via tools -> java platforms as previously mentioned. but this sounds to me like you don't have to do anything, NB probably simply set it to the default which would be JDK 21 you just installed. -mbien
Re: Apache NetBeans 20 released - Java Versions
Thank you to those of you who have responded with encouragement, that has helped a lot. Just to close out this query, I took the plunge and installed JDK21 (after first uninstalling JDK8) and opened up my project. No errors reported but the appearance and layout of my various screens was wrecked. After a bit of Googling I found that the way to set look & feel had changed from that which I have previously used. After copying and pasting the revised code into my project - nearly 30 source files - all is well. One small niggle remains: when I start NB20, it complains it cannot find JDK8 and can it use the default. I click 'yes' and all is well. I have found how to point NB to JDK21 at project level but I cannot find a way to switch this at global level. Is there an environment variable I need to know about here? Judi Rastall On 20/12/2023 11:53, Michael Bien wrote: On 20.12.23 01:30, Judi Rastall wrote: If I may introduce myself: I am a hobbyist. I am teaching myself Java through reading books and other online sources... cool! This is probably one of the best ways how to get into programming. Find something you want to write and then try to get there somehow with the help of books/guides etc. ... I didn't realise that the professional development community had moved on and was now plugged into Oracle and Java.net which seem to be under totally different care and maintenance. NetBeans has also a JDK downloader integrated, if you want to see all the different versions and vendors you can access it under: Tools -> Java Platforms -> Add Platform -> Download OpenJDK So it seems that I need to refocus my attention to JDK21 from Oracle and cross my fingers and hope that my current project survives the sudden upgrade. If you encounter problems, upgrade in steps, 8->11->17->21. But most programs will work fine on 21 if you don't have too many trouble making dependencies. best regards, -mbien Regards, Judi Rastall On 19/12/2023 23:25, Scott Palmer wrote: Some of this confusion is caused by the fact that there is no longer a separate JRE download. Java.com was targeted at end users, not developers. There is indeed no update to the Java 8 JRE as the JRE is discontinued. The JDK is a different story. Scott On Dec 18, 2023, at 2:55 PM, Leo Donahue wrote: On Mon, Dec 18, 2023, 13:09 Stephen Winnall wrote: Why is everyone avoiding answering Judi’s question? On the NetBeans main page, it says indirectly that you can't install with java 8, you need 11+ Deployment Platforms The Apache NetBeans 20 binary releases require JDK 11+, and officially support running on JDK 11, 17 and 21. https://netbeans.apache.org/front/main/download/nb20/ I don’t pretend to be the expert but the answer to Judi’s question is: download newer (post-v8) versions of Java from Zulu (https://www.azul.com/downloads/?package=jdk#zulu) or some other OpenJDK site. Cheers, Steve On 18 Dec 2023, at 19:04, Michael Bien wrote: On 18.12.23 18:22, Judi Rastall wrote: I go to my Java installation (which says it is Java v8 update 391), click on check for updates, and it tells me I have the latest version. java isn't going to update to the next major version on windows. I don't think the newer JDKs have even an updater anymore (not sure, might be vendor dependent). The easiest way to get started on windows is to use one of the community installers which bundle a current JDK with NB in one package. If you don't want that, then check the requirements on the download page and install a supported JDK of a vendor you prefer. -mbien - 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
Re: Apache NetBeans 20 released - Java Versions
On 20.12.23 01:30, Judi Rastall wrote:
If I may introduce myself: I am a hobbyist. I am teaching myself Java
through reading books and other online sources...
cool! This is probably one of the best ways how to get into programming.
Find something you want to write and then try to get there somehow with
the help of books/guides etc.
... I didn't realise that the professional development community had
moved on and was now plugged into Oracle and Java.net which seem to be
under totally different care and maintenance.
NetBeans has also a JDK downloader integrated, if you want to see all
the different versions and vendors you can access it under:
Tools -> Java Platforms -> Add Platform -> Download OpenJDK
So it seems that I need to refocus my attention to JDK21 from Oracle
and cross my fingers and hope that my current project survives the
sudden upgrade.
If you encounter problems, upgrade in steps, 8->11->17->21. But most
programs will work fine on 21 if you don't have too many trouble making
dependencies.
best regards,
-mbien
Regards,
Judi Rastall
On 19/12/2023 23:25, Scott Palmer wrote:
Some of this confusion is caused by the fact that there is no longer
a separate JRE download. Java.com was targeted at end users, not
developers. There is indeed no update to the Java 8 JRE as the JRE is
discontinued. The JDK is a different story.
Scott
On Dec 18, 2023, at 2:55 PM, Leo Donahue wrote:
On Mon, Dec 18, 2023, 13:09 Stephen Winnall wrote:
Why is everyone avoiding answering Judi’s question?
On the NetBeans main page, it says indirectly that you can't install
with java 8, you need 11+
Deployment Platforms
The Apache NetBeans 20 binary releases require JDK 11+, and
officially support running on JDK 11, 17 and 21.
https://netbeans.apache.org/front/main/download/nb20/
I don’t pretend to be the expert but the answer to Judi’s
question is: download newer (post-v8) versions of Java from Zulu
(https://www.azul.com/downloads/?package=jdk#zulu) or some other
OpenJDK site.
Cheers,
Steve
On 18 Dec 2023, at 19:04, Michael Bien wrote:
On 18.12.23 18:22, Judi Rastall wrote:
I go to my Java installation (which says it is Java v8 update
391), click on check for updates, and it tells me I have the
latest version.
java isn't going to update to the next major version on
windows. I don't think the newer JDKs have even an updater
anymore (not sure, might be vendor dependent).
The easiest way to get started on windows is to use one of the
community installers which bundle a current JDK with NB in one
package. If you don't want that, then check the requirements on
the download page and install a supported JDK of a vendor you
prefer.
-mbien
-
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
Re: Apache NetBeans 20 released - Java Versions
Dear all, I seem to have raised a bit of a storm initially that then blew over as quickly as it started. One of the criticisms levelled was that the conversation was being held on the [ANNOUNCE] thread so I've removed that from the subject line now - but any one of us could have done that earlier. If I may introduce myself: I am a hobbyist. I am teaching myself Java through reading books and other online sources (some of which are more help than others) and feel I'm making good progress. So I guess I fall half way between an end-user and a developer. I have inherited an application written in Delphi and which runs only on Windows. Since I wanted a way of offering the app on other platforms I decided that Java seemed the right way to go. This means I am part way through a complete rewrite from scratch since attempting a port direct from Delphi would only lead to tears. Since I am a hobbyist there is no way I can ever justify paying for cross-compilers for different OSs, hence my choice of Java. I have received updates for my Java installation at regular intervals so I *assumed* I had the latest version, the most recent being dated October 2023. I now realise that this is from Java.com and is fixed to updating/bugfixing Java 8. I didn't realise that the professional development community had moved on and was now plugged into Oracle and Java.net which seem to be under totally different care and maintenance. So it seems that I need to refocus my attention to JDK21 from Oracle and cross my fingers and hope that my current project survives the sudden upgrade. By the way, the app I'm working on is described at wagonflow.co.uk if anyone's interested. Regards, Judi Rastall On 19/12/2023 23:25, Scott Palmer wrote: Some of this confusion is caused by the fact that there is no longer a separate JRE download. Java.com was targeted at end users, not developers. There is indeed no update to the Java 8 JRE as the JRE is discontinued. The JDK is a different story. Scott On Dec 18, 2023, at 2:55 PM, Leo Donahue wrote: On Mon, Dec 18, 2023, 13:09 Stephen Winnall wrote: Why is everyone avoiding answering Judi’s question? On the NetBeans main page, it says indirectly that you can't install with java 8, you need 11+ Deployment Platforms The Apache NetBeans 20 binary releases require JDK 11+, and officially support running on JDK 11, 17 and 21. https://netbeans.apache.org/front/main/download/nb20/ I don’t pretend to be the expert but the answer to Judi’s question is: download newer (post-v8) versions of Java from Zulu (https://www.azul.com/downloads/?package=jdk#zulu) or some other OpenJDK site. Cheers, Steve On 18 Dec 2023, at 19:04, Michael Bien wrote: On 18.12.23 18:22, Judi Rastall wrote: I go to my Java installation (which says it is Java v8 update 391), click on check for updates, and it tells me I have the latest version. java isn't going to update to the next major version on windows. I don't think the newer JDKs have even an updater anymore (not sure, might be vendor dependent). The easiest way to get started on windows is to use one of the community installers which bundle a current JDK with NB in one package. If you don't want that, then check the requirements on the download page and install a supported JDK of a vendor you prefer. -mbien - 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
Re: Java version: 21 ... not supported by Gradle 8.5
Hi Owen, On Wed, 2023-12-06 at 14:01 +1100, Owen Thomas wrote: > I might use Maven in the future, and I'll hang on to my gradle build at the > moment (I'm getting incompatibility errors in my build but these don't seem > to have a material influence on what is being built), but I may yet turn back > to Ant. definitely a good choice and I would be the last one trying to evangelise you. > > I think Gradle is making things too complicated for Java users. Bad. Although this is where is disagree strongly: One of the beauties of Gradle is its ability to include java code snippets as part of the build, which comes very handy whenever you exceed the standard features. I want to illustrate this with one example: Building native C libraries on varies architectures and bundle them into a Jar, where they are called by JNA depends on a certain convention on Names and Folders. In Gradle you script such a mapping logic easily in Java/Groovy. I would have no idea how to do that in Maven. One more thing I found very neat is dependency resolution with SNAPSHOT artifacts and "LATEST.RELEASE". One big contra is the Gradle's API "stability" though, I won't lie about that. At the end it all boils down to personal preference and taste (I for myself despise Maven) and the beauty is about having the choice. I think that 95% of the users won't even experience any major advantage of Maven over Gradle or Gradle over Maven, so just choose what you like most. ANT is dead as dodo for good, you may be better off with CMAKE if both Gradle and Maven are not for you. Cheers Andreas
Re: Java version: 21 ... not supported by Gradle 8.5
On Wed, 6 Dec 2023 at 10:38, Andreas Reichel wrote: > 1) dependency resolution (including the understanding, what Class format > the artifact is providing) > 2) compiling and packaging based on the built classpath > > For 2), any Gradle will do. > But for 1) Gradle needs to understand the particular Class formats and > thus depends on the JDK version strictly. > Hmm... thanks for this info Andreas. I would think that the JVM version is given in a jar's environment setup. It might have to be known to the build tool only to check that the destination JVM for the build is able to run the built artefact and all its dependencies. Anyway, I think Gradle is trying to make me appropriate someone else's problems. I might use Maven in the future, and I'll hang on to my gradle build at the moment (I'm getting incompatibility errors in my build but these don't seem to have a material influence on what is being built), but I may yet turn back to Ant. Although in a future time I may, I currently use no third party libraries. I think Gradle is making things too complicated for Java users. Bad. >
Re: Java version: 21 ... not supported by Gradle 8.5
On 06.12.23 00:32, Owen Thomas wrote: This matrix is just doing my head in, because all I can gather from the page disclosed is a mechanism - I don't understand why the mechanism needs to exist in the first place. because gradle uses kotlin and groovy as the config file format language, languages which are implemented on top of java (its more complicated but this is the simple version). They will always lack a bit behind in supporting the latest java version. Gradle has to wait for all dependencies to be ready before it can claim in a release that it supports Java X. The exact same thing happens in NB, gradle 8.5 was released too late to be tested and integrated into NB 20, so it ships with gradle 8.4. NB 21 will whip with whatever is ready when the release candidate phase starts. btw upgrading gradle in NB is relatively easy, you can do it yourself, open a PR and you have a NB dev build which includes a jdk 21 compatible gradle release, example: https://github.com/apache/netbeans/pull/6553 Now lets compare this with other build tools like apache maven or ant, they use XML as their file format. The last spec change to XML was in the year 1820 (estimated). I just tested it, and even a 14 years old release of maven (2.1) works fine on JDK 21 (but please don't try this at home, running end-of-life network connected libs is not a good idea - this was just an experiment to proof a point). This problem essentially doesn't exist with maven and ant. hope this helps, -mbien I don't think the version of a build tool should need to be matched with a version of the JVM - but this is indeed probably merey my ignorance of the justification for this necessity speaking. Is there a page that informs my ignorance? On Wed, 6 Dec 2023 at 03:23, Bernd Michaely wrote: https://docs.gradle.org/current/userguide/compatibility.html On 04.12.23 01:24, Owen Thomas wrote: > > Is there a page I can read that outlines how Gradle will work with > Java in the future? This stuff is giving me a headache. >
Re: Java version: 21 ... not supported by Gradle 8.5
Owen, from what I understand, Gradle solves 2 different tasks: 1) dependency resolution (including the understanding, what Class format the artifact is providing) 2) compiling and packaging based on the built classpath For 2), any Gradle will do. But for 1) Gradle needs to understand the particular Class formats and thus depends on the JDK version strictly. Cheers!
Re: Java version: 21 ... not supported by Gradle 8.5
Thanks for that; Maybe I'm not keeping enough attention to what is going on here to really make a constructive comment, butI was looking more for justification of the existence of this "compatibility matrix" and Gradle's future intentions in supporting Java. This matrix is just doing my head in, because all I can gather from the page disclosed is a mechanism - I don't understand why the mechanism needs to exist in the first place. I don't think the version of a build tool should need to be matched with a version of the JVM - but this is indeed probably merey my ignorance of the justification for this necessity speaking. Is there a page that informs my ignorance? On Wed, 6 Dec 2023 at 03:23, Bernd Michaely wrote: > https://docs.gradle.org/current/userguide/compatibility.html > > On 04.12.23 01:24, Owen Thomas wrote: > > > > Is there a page I can read that outlines how Gradle will work with > > Java in the future? This stuff is giving me a headache. > > >
Re: Java version: 21 ... not supported by Gradle 8.5
https://docs.gradle.org/current/userguide/compatibility.html On 04.12.23 01:24, Owen Thomas wrote: Is there a page I can read that outlines how Gradle will work with Java in the future? This stuff is giving me a headache. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Java version: 21 ... not supported by Gradle 8.5
Indeed you are right! 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. Oh, so many things to do... On 12/4/23 16:41, Ernie Rael wrote: Thanks for the discussion Laszlo, After reading your post (more than once) I tried a variety of different things, including settings the toolchain version to "21" and also "options.release = 21" for the hell of it. gradleproject1:lib > properties > Sources > Source/Binary Format is 21. When I add the line import java.util.SequencedCollection; It's highlighted as an error in the editor; though it does clean/build. It looks like the Source/Binary Format property, which /is being picked up by gradle/, is not being used by the IDE-editor. (I remember https://github.com/apache/netbeans/pull/4711 which fixed this value for gradle because "This information is used by editor/hints.", but things evolve). And when I change gradleproject1 > properties > Build > GradleExecution > Java Runtime to JDK 21, the editor errors go away but the warnings from project problems comes on. Bottom line, AFAICT, NB-20 Cannot open a "gradle with Java" project that uses JDK-21 APIs without warnings/errors no matter how the project is setup. -ernie On 23/12/03 5:58 PM, Laszlo Kishalmi wrote: Well, the rapid changes of Java put pressure on the tool platforms, and JVM based languages. That makes our life more difficult. As of NetBeans, it was quite a fight to move away from Java 8 as a runtime platform. That does not mean that NetBeans does not support Java 8 any more, rather, that You need to run NetBeans at least on Java 11. As of NetBeans 20, It runs on Java 11 - Java 21, while supports Java 8 - Java 21 As of Gradle. Gradle supports Groovy and Kotlin as base of its DSL. Usually when the new JVM comes out both Groovy and Kotlin takes some time to support running on the new JVM. So they are not in an easy position, especially as they still need to support running on Java 8 fro a while. In order to cope with that challenge Gradle stated to use a Java Toolchain system, which decouples the Runtime Gradle is running on from the Java version it is using during the builds. If I remember well, on 8.4 they found themself in the situation with Java 21, where the Groovy parts were able to run on Java 21 while the Kotlin related things were not able to run on Java 21 VM. Java 21 Toolchain was ready by then. That means Gradle 8.4 itself is not able to run on Java 21, but able to use Java 21 for builds. With Gradle 8.5, it is also able to run on Java 21 VM. It would be nice if NetBeans would be automatically select a good Java Runtime for Gradle out of the box though. We have all the parts in NetBeans to be able to make it happen, somebody just would need to do the job. Addendum: Before Gradle 8.5, Gradle java projects, generated with Gradle were using the Java version of the Gradle Runtime as the Jave version for the new project. That's been changed as of: https://docs.gradle.org/8.5/release-notes.html#build-init So what is happening now when creating a new project on NB20 is running on Java 21 with Gradle 8.4 Tooling (that's the one NB20 is bundling), when using the defaults . 1. NetBeans invokes gradle init with Java 21, as Gradle 8.4 Groovy parts works with Java 21, it will create a new project, with java toolchain 21 2. NetBeans knows that Gradle 8.4 is not Java 21 Runtime comaptible (that's hard coded in NB). So it simply refuse to load the project, while the Gradle Java runtime is set to Java 21 (Default). That's when people get confused. Again NB should do a better job selecting the Gradle Java runtime. On 12/3/23 17:20, Ernie Rael wrote: On 23/12/03 3:51 PM, Laszlo Kishalmi wrote: Well, unfortunately gradle init only supports java version specification since Gradle 8.5 NB20 is bundled with Gradle 8.4. The gradle 8.4 release notes say "Java 21 is now supported" if that matters. There is a bit workaround needed to run Java 21 projects with Gradle. I can run the project tests with no workaround. Also, I manually set the gradle version for the project to 8.5 ./gradlew wrapper --gradle-version 8.5 The problem icon is still there and the message says "Java version: 21 ... not supported by Gradle 8.5" Both 8.4 and 8.5 claim to support JDK-21. This all makes no sense. I think (I don't remember) that I could run the project tests when it was gradle 8.4 as well with no workaround. This all makes me wonder if there's something hardcoded in NetBeans about JDK-21 and gradle. -ernie Set the Java Runtime version for Gradle in Tools > Options > Java > Gradle to Java 20 or below. From there you can use any Java version in your Gradle projects, whatever that Gradle version support.
Re: Java version: 21 ... not supported by Gradle 8.5
Thanks for the discussion Laszlo,
After reading your post (more than once) I tried a variety of different
things, including settings the toolchain version to "21" and also
"options.release = 21" for the hell of it.
gradleproject1:lib > properties > Sources > Source/Binary Format
is 21. When I add the line
import java.util.SequencedCollection;
It's highlighted as an error in the editor; though it does clean/build.
It looks like the Source/Binary Format property, which /is being picked
up by gradle/, is not being used by the IDE-editor. (I remember
https://github.com/apache/netbeans/pull/4711 which fixed this value for
gradle because "This information is used by editor/hints.", but things
evolve).
And when I change
gradleproject1 > properties > Build > GradleExecution > Java Runtime
to JDK 21, the editor errors go away but the warnings from project
problems comes on.
Bottom line, AFAICT,
NB-20 Cannot open a "gradle with Java" project that uses JDK-21 APIs
without warnings/errors
no matter how the project is setup.
-ernie
On 23/12/03 5:58 PM, Laszlo Kishalmi wrote:
Well, the rapid changes of Java put pressure on the tool platforms,
and JVM based languages. That makes our life more difficult.
As of NetBeans, it was quite a fight to move away from Java 8 as a
runtime platform. That does not mean that NetBeans does not support
Java 8 any more, rather, that You need to run NetBeans at least on
Java 11. As of NetBeans 20, It runs on Java 11 - Java 21, while
supports Java 8 - Java 21
As of Gradle. Gradle supports Groovy and Kotlin as base of its DSL.
Usually when the new JVM comes out both Groovy and Kotlin takes some
time to support running on the new JVM. So they are not in an easy
position, especially as they still need to support running on Java 8
fro a while.
In order to cope with that challenge Gradle stated to use a Java
Toolchain system, which decouples the Runtime Gradle is running on
from the Java version it is using during the builds.
If I remember well, on 8.4 they found themself in the situation with
Java 21, where the Groovy parts were able to run on Java 21 while the
Kotlin related things were not able to run on Java 21 VM. Java 21
Toolchain was ready by then. That means Gradle 8.4 itself is not able
to run on Java 21, but able to use Java 21 for builds.
With Gradle 8.5, it is also able to run on Java 21 VM.
It would be nice if NetBeans would be automatically select a good Java
Runtime for Gradle out of the box though. We have all the parts in
NetBeans to be able to make it happen, somebody just would need to do
the job.
Addendum: Before Gradle 8.5, Gradle java projects, generated with
Gradle were using the Java version of the Gradle Runtime as the Jave
version for the new project. That's been changed as of:
https://docs.gradle.org/8.5/release-notes.html#build-init
So what is happening now when creating a new project on NB20 is
running on Java 21 with Gradle 8.4 Tooling (that's the one NB20 is
bundling), when using the defaults .
1. NetBeans invokes gradle init with Java 21, as Gradle 8.4 Groovy
parts works with Java 21, it will create a new project, with java
toolchain 21
2. NetBeans knows that Gradle 8.4 is not Java 21 Runtime comaptible
(that's hard coded in NB). So it simply refuse to load the project,
while the Gradle Java runtime is set to Java 21 (Default).
That's when people get confused.
Again NB should do a better job selecting the Gradle Java runtime.
On 12/3/23 17:20, Ernie Rael wrote:
On 23/12/03 3:51 PM, Laszlo Kishalmi wrote:
Well, unfortunately gradle init only supports java version
specification since Gradle 8.5
NB20 is bundled with Gradle 8.4.
The gradle 8.4 release notes say
"Java 21 is now supported"
if that matters.
There is a bit workaround needed to run Java 21 projects with Gradle.
I can run the project tests with no workaround.
Also, I manually set the gradle version for the project to 8.5
./gradlew wrapper --gradle-version 8.5
The problem icon is still there and the message says
"Java version: 21 ... not supported by Gradle 8.5"
Both 8.4 and 8.5 claim to support JDK-21. This all makes no sense.
I think (I don't remember) that I could run the project tests when it
was gradle 8.4 as well with no workaround.
This all makes me wonder if there's something hardcoded in NetBeans
about JDK-21 and gradle.
-ernie
Set the Java Runtime version for Gradle in Tools > Options > Java >
Gradle to Java 20 or below.
From there you can use any Java version in your Gradle projects,
whatever that Gradle version support.
Gradle 8.4 does support Java 21 using Java Toolchain, should work.
java {
toolchain {
languageVersion = JavaLanguageVersion.of(21)
}
}
On 12/3/23 13:30, Ernie Rael wrote:
Running NB-20, jdk21.
The goal is to play with some JD
Re: Java version: 21 ... not supported by Gradle 8.5
Well, the rapid changes of Java put pressure on the tool platforms, and
JVM based languages. That makes our life more difficult.
As of NetBeans, it was quite a fight to move away from Java 8 as a
runtime platform. That does not mean that NetBeans does not support
Java 8 any more, rather, that You need to run NetBeans at least on Java
11. As of NetBeans 20, It runs on Java 11 - Java 21, while supports Java
8 - Java 21
As of Gradle. Gradle supports Groovy and Kotlin as base of its DSL.
Usually when the new JVM comes out both Groovy and Kotlin takes some
time to support running on the new JVM. So they are not in an easy
position, especially as they still need to support running on Java 8 fro
a while.
In order to cope with that challenge Gradle stated to use a Java
Toolchain system, which decouples the Runtime Gradle is running on from
the Java version it is using during the builds.
If I remember well, on 8.4 they found themself in the situation with
Java 21, where the Groovy parts were able to run on Java 21 while the
Kotlin related things were not able to run on Java 21 VM. Java 21
Toolchain was ready by then. That means Gradle 8.4 itself is not able to
run on Java 21, but able to use Java 21 for builds.
With Gradle 8.5, it is also able to run on Java 21 VM.
It would be nice if NetBeans would be automatically select a good Java
Runtime for Gradle out of the box though. We have all the parts in
NetBeans to be able to make it happen, somebody just would need to do
the job.
Addendum: Before Gradle 8.5, Gradle java projects, generated with Gradle
were using the Java version of the Gradle Runtime as the Jave version
for the new project. That's been changed as of:
https://docs.gradle.org/8.5/release-notes.html#build-init
So what is happening now when creating a new project on NB20 is running
on Java 21 with Gradle 8.4 Tooling (that's the one NB20 is bundling),
when using the defaults .
1. NetBeans invokes gradle init with Java 21, as Gradle 8.4 Groovy
parts works with Java 21, it will create a new project, with java
toolchain 21
2. NetBeans knows that Gradle 8.4 is not Java 21 Runtime comaptible
(that's hard coded in NB). So it simply refuse to load the project,
while the Gradle Java runtime is set to Java 21 (Default).
That's when people get confused.
Again NB should do a better job selecting the Gradle Java runtime.
On 12/3/23 17:20, Ernie Rael wrote:
On 23/12/03 3:51 PM, Laszlo Kishalmi wrote:
Well, unfortunately gradle init only supports java version
specification since Gradle 8.5
NB20 is bundled with Gradle 8.4.
The gradle 8.4 release notes say
"Java 21 is now supported"
if that matters.
There is a bit workaround needed to run Java 21 projects with Gradle.
I can run the project tests with no workaround.
Also, I manually set the gradle version for the project to 8.5
./gradlew wrapper --gradle-version 8.5
The problem icon is still there and the message says
"Java version: 21 ... not supported by Gradle 8.5"
Both 8.4 and 8.5 claim to support JDK-21. This all makes no sense.
I think (I don't remember) that I could run the project tests when it
was gradle 8.4 as well with no workaround.
This all makes me wonder if there's something hardcoded in NetBeans
about JDK-21 and gradle.
-ernie
Set the Java Runtime version for Gradle in Tools > Options > Java >
Gradle to Java 20 or below.
From there you can use any Java version in your Gradle projects,
whatever that Gradle version support.
Gradle 8.4 does support Java 21 using Java Toolchain, should work.
java {
toolchain {
languageVersion = JavaLanguageVersion.of(21)
}
}
On 12/3/23 13:30, Ernie Rael wrote:
Running NB-20, jdk21.
The goal is to play with some JDK-21 APIs...
Creating a project using NB's "New Project > Java with Gradle".
I can build and run the default "Library" and test. But there's the
warning icon and "Resolve Project Problems".
Any way to get rid of the warning?
-ernie
"Resolve Project Problems"
The Java version: 21, that is selected for the project is not
supported by
Gradle 8.4.The IDE will attempt to use Gradle 8.4 to gather the project
information.
Possible solutions:
Upgrade your Gradle version on your project
Select Java Runtime 20 (or below), on Build > Gradle Execution
settings, to avoid this problem!
-
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: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org
For further in
Re: Java version: 21 ... not supported by Gradle 8.5
gradle 8.4 release notes:
> Java 21 is now supported for compiling, testing, and running such
projects.
gradle 8.5 release notes:
> Gradle now supports running on Java 21.
(I fell for it too the first time I read it, Gradle 8.4 can not run on
Java 21)
-mbien
On 04.12.23 02:20, Ernie Rael wrote:
On 23/12/03 3:51 PM, Laszlo Kishalmi wrote:
Well, unfortunately gradle init only supports java version
specification since Gradle 8.5
NB20 is bundled with Gradle 8.4.
The gradle 8.4 release notes say
"Java 21 is now supported"
if that matters.
There is a bit workaround needed to run Java 21 projects with Gradle.
I can run the project tests with no workaround.
Also, I manually set the gradle version for the project to 8.5
./gradlew wrapper --gradle-version 8.5
The problem icon is still there and the message says
"Java version: 21 ... not supported by Gradle 8.5"
Both 8.4 and 8.5 claim to support JDK-21. This all makes no sense.
I think (I don't remember) that I could run the project tests when it
was gradle 8.4 as well with no workaround.
This all makes me wonder if there's something hardcoded in NetBeans
about JDK-21 and gradle.
-ernie
Set the Java Runtime version for Gradle in Tools > Options > Java >
Gradle to Java 20 or below.
From there you can use any Java version in your Gradle projects,
whatever that Gradle version support.
Gradle 8.4 does support Java 21 using Java Toolchain, should work.
java {
toolchain {
languageVersion = JavaLanguageVersion.of(21)
}
}
On 12/3/23 13:30, Ernie Rael wrote:
Running NB-20, jdk21.
The goal is to play with some JDK-21 APIs...
Creating a project using NB's "New Project > Java with Gradle".
I can build and run the default "Library" and test. But there's the
warning icon and "Resolve Project Problems".
Any way to get rid of the warning?
-ernie
"Resolve Project Problems"
The Java version: 21, that is selected for the project is not
supported by
Gradle 8.4.The IDE will attempt to use Gradle 8.4 to gather the project
information.
Possible solutions:
Upgrade your Gradle version on your project
Select Java Runtime 20 (or below), on Build > Gradle Execution
settings, to avoid this problem!
-
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: 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
Re: Java version: 21 ... not supported by Gradle 8.5
On 23/12/03 3:51 PM, Laszlo Kishalmi wrote:
Well, unfortunately gradle init only supports java version
specification since Gradle 8.5
NB20 is bundled with Gradle 8.4.
The gradle 8.4 release notes say
"Java 21 is now supported"
if that matters.
There is a bit workaround needed to run Java 21 projects with Gradle.
I can run the project tests with no workaround.
Also, I manually set the gradle version for the project to 8.5
./gradlew wrapper --gradle-version 8.5
The problem icon is still there and the message says
"Java version: 21 ... not supported by Gradle 8.5"
Both 8.4 and 8.5 claim to support JDK-21. This all makes no sense.
I think (I don't remember) that I could run the project tests when it
was gradle 8.4 as well with no workaround.
This all makes me wonder if there's something hardcoded in NetBeans
about JDK-21 and gradle.
-ernie
Set the Java Runtime version for Gradle in Tools > Options > Java >
Gradle to Java 20 or below.
From there you can use any Java version in your Gradle projects,
whatever that Gradle version support.
Gradle 8.4 does support Java 21 using Java Toolchain, should work.
java {
toolchain {
languageVersion = JavaLanguageVersion.of(21)
}
}
On 12/3/23 13:30, Ernie Rael wrote:
Running NB-20, jdk21.
The goal is to play with some JDK-21 APIs...
Creating a project using NB's "New Project > Java with Gradle".
I can build and run the default "Library" and test. But there's the
warning icon and "Resolve Project Problems".
Any way to get rid of the warning?
-ernie
"Resolve Project Problems"
The Java version: 21, that is selected for the project is not
supported by
Gradle 8.4.The IDE will attempt to use Gradle 8.4 to gather the project
information.
Possible solutions:
Upgrade your Gradle version on your project
Select Java Runtime 20 (or below), on Build > Gradle Execution
settings, to avoid this problem!
-
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: 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
Re: Java version: 21 ... not supported by Gradle 8.5
What's going on with Java and Gradle? Would I be right in supposing that it
would be simpler just to go back to Ant?
Is there a page I can read that outlines how Gradle will work with Java in
the future? This stuff is giving me a headache.
On Mon, 4 Dec 2023 at 10:51, Laszlo Kishalmi
wrote:
> Well, unfortunately gradle init only supports java version specification
> since Gradle 8.5
>
> NB20 is bundled with Gradle 8.4.
>
> There is a bit workaround needed to run Java 21 projects with Gradle.
>
> Set the Java Runtime version for Gradle in Tools > Options > Java >
> Gradle to Java 20 or below.
>
> From there you can use any Java version in your Gradle projects,
> whatever that Gradle version support.
>
> Gradle 8.4 does support Java 21 using Java Toolchain, should work.
>
> java {
> toolchain {
> languageVersion = JavaLanguageVersion.of(21)
> }
> }
>
> On 12/3/23 13:30, Ernie Rael wrote:
> > Running NB-20, jdk21.
> >
> > The goal is to play with some JDK-21 APIs...
> >
> > Creating a project using NB's "New Project > Java with Gradle".
> >
> > I can build and run the default "Library" and test. But there's the
> > warning icon and "Resolve Project Problems".
> >
> > Any way to get rid of the warning?
> >
> > -ernie
> >
> >
> > "Resolve Project Problems"
> >
> > The Java version: 21, that is selected for the project is not
> > supported by
> > Gradle 8.4.The IDE will attempt to use Gradle 8.4 to gather the project
> > information.
> > Possible solutions:
> > Upgrade your Gradle version on your project
> > Select Java Runtime 20 (or below), on Build > Gradle Execution
> > settings, to avoid this problem!
> >
> >
> >
> >
> > -
> > 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: 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
>
>
Re: Java version: 21 ... not supported by Gradle 8.5
Well, unfortunately gradle init only supports java version specification
since Gradle 8.5
NB20 is bundled with Gradle 8.4.
There is a bit workaround needed to run Java 21 projects with Gradle.
Set the Java Runtime version for Gradle in Tools > Options > Java >
Gradle to Java 20 or below.
From there you can use any Java version in your Gradle projects,
whatever that Gradle version support.
Gradle 8.4 does support Java 21 using Java Toolchain, should work.
java {
toolchain {
languageVersion = JavaLanguageVersion.of(21)
}
}
On 12/3/23 13:30, Ernie Rael wrote:
Running NB-20, jdk21.
The goal is to play with some JDK-21 APIs...
Creating a project using NB's "New Project > Java with Gradle".
I can build and run the default "Library" and test. But there's the
warning icon and "Resolve Project Problems".
Any way to get rid of the warning?
-ernie
"Resolve Project Problems"
The Java version: 21, that is selected for the project is not
supported by
Gradle 8.4.The IDE will attempt to use Gradle 8.4 to gather the project
information.
Possible solutions:
Upgrade your Gradle version on your project
Select Java Runtime 20 (or below), on Build > Gradle Execution
settings, to avoid this problem!
-
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: 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
Java version: 21 ... not supported by Gradle 8.5
Running NB-20, jdk21. The goal is to play with some JDK-21 APIs... Creating a project using NB's "New Project > Java with Gradle". I can build and run the default "Library" and test. But there's the warning icon and "Resolve Project Problems". Any way to get rid of the warning? -ernie "Resolve Project Problems" The Java version: 21, that is selected for the project is not supported by Gradle 8.4.The IDE will attempt to use Gradle 8.4 to gather the project information. Possible solutions: Upgrade your Gradle version on your project Select Java Runtime 20 (or below), on Build > Gradle Execution settings, to avoid this problem! - 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
Java Wrapper around the fast FPNG encoder, AVX/SSE optimised
Greetings. Please allow me to apologise for hijacking this list: I assume there are a lots of Java interested people gathered here. We wrapped the SSE/AVX optimised PNG encoders into a Java library. The results look promising: 27x faster than ImageIO and still 11x faster than Java PNG Encoder, at very competitive compression rates. Please see details here: https://github.com/manticore-projects/fpng-java Although I would like to ask for some help: The GitHub Runner for x64 MacOS is segfaulting occasionally and I have no idea why. Everything works great on x64 Linux and x64 Windows. If someone with MacOS experience and hardware would like to lend me a helping hand investigating this, I would be eternally grateful. Beverages would be on me of course. Also I wonder, how to build for arm64 MacOS, since there is no GitHub Runner for this. Sure, I could cross compile -- but how to test after? Any feedback and suggestion and question would be most welcome and appreciated. Thank you for your time and patience, cheers! Andreas
Re: [EXTERNAL] Re: Converting Java 8 to 17+, conflicts with modules
All great advice. I was able to solve the compile issue using the following,
but I'll need to refine my deps and module declarations. Each of these were
added explicitly because they're used, include several classes/packages from
org.eclipse.persistence.*.
jakarta.inject
jakarta.inject-api
2.0.1
provided
jar
jakarta.enterprise
jakarta.enterprise.cdi-api
4.0.1
provided
jar
jakarta.json
jakarta.json-api
2.1.3
provided
jar
jakarta.ws.rs
jakarta.ws.rs-api
3.1.0
provided
jar
jakarta.json.bind
jakarta.json.bind-api
3.0.0
provided
jar
jakarta.validation
jakarta.validation-api
3.0.2
provided
jar
jakarta.ejb
jakarta.ejb-api
4.0.1
provided
jar
jakarta.servlet
jakarta.servlet-api
6.0.0
provided
jar
jakarta.persistence
jakarta.persistence-api
3.1.0
provided
jar
jakarta.xml.bind
jakarta.xml.bind-api
4.0.1
provided
jar
org.glassfish.jersey.media
jersey-media-multipart
3.1.3
provided
org.glassfish.jersey.core
jersey-client
${project.dependency.jersey.version}
provided
org.eclipse.persistence
org.eclipse.persistence.core
3.0.4
provided
jar
org.eclipse.persistence
org.eclipse.persistence.jpa
4.0.2
provided
jar
requires jakarta.cdi;
requires jakarta.ejb;
requires jakarta.inject;
requires jakarta.json;
requires jakarta.json.bind;
requires jakarta.servlet;
requires jakarta.validation;
requires jakarta.ws.rs;
requires jakarta.xml.bind;
requires jersey.client;
requires jersey.media.multipart;
requires org.eclipse.persistence.jpa;
From: Stephen G. Parry
Sent: Saturday, November 11, 2023 11:47 AM
To: Bradley Willcott ; John Manko ;
users@netbeans.apache.org
Subject: [EXTERNAL] Re: Converting Java 8 to 17+, conflicts with modules
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
>From my experience, minimize your direct Maven dependencies. Try to use
>services as much as possible. For example. eclipselink should be a runtime,
>not a compile time dependency and should be injected as service:
module-info.java:
requires jakarta.persistence;
uses jakarta.persistence.spi.PersistenceProvider;
pom.xml:
org.eclipse.persistence
eclipselink
4.0.1
runtime
Basically, strip the dependencies back to nothing and only add the ones that
stop the compilation from failing or the code from running, one mod at a time.
Some of your dependencies may fail to load because they are not fully modular
yet. Your options then are:
a) make your application non-modular, for now. This still works for most things
apart from Java FX. Doing non-modular FX is like urinating into a stiff breeze.
b) use moditect to patch the non-modular dependencies, until modular ones are
available. It's a hack, but it works surprisingly well.
On 11/11/2023 15:42, Bradley Willcott wrote:
Hi John.
Check out this site:
https://www.digitalocean.com/community/tutorials/maven-dependency-tree-resolving-conflicts<https://urldefense.com/v3/__https://www.digitalocean.com/community/tutorials/maven-dependency-tree-resolving-conflicts__;!!HzYX23eHnp2Wbe4!UJMA1Rmsp-1cH7vOEIOeagJSpQlcBx-0D0STmQ9DCsdCC3uI-7hcS--YJXfnhsVXFxbD1fEqbNnV3bw$>.
It should give you what you need to know.
Regards,
Brad.
On 11/11/23 06:20, John Manko wrote:
This might not be a purely Netbeans issue, but maybe NB has some tooling to
assist, or someone can answer a quick question.
I'm in the middle of converting Java 8 project to Java 17/21 (A little late in
the game, I know! I'm beholden to other forces beyond my control.), and I have
a library module with a module-info like such:
module com.my.lib {
requires com.google.common;
requires com.google.gson;
requires eclipselink;
requires jakarta.jakartaee.api;
requires java.loggin
Re: Converting Java 8 to 17+, conflicts with modules
From my experience, minimize your direct Maven dependencies. Try to use
services as much as possible. For example. eclipselink should be a
runtime, not a compile time dependency and should be injected as service:
module-info.java:
requires jakarta.persistence;
uses jakarta.persistence.spi.PersistenceProvider;
pom.xml:
org.eclipse.persistence
eclipselink
4.0.1
runtime
Basically, strip the dependencies back to nothing and only add the ones
that stop the compilation from failing or the code from running, one mod
at a time.
Some of your dependencies may fail to load because they are not fully
modular yet. Your options then are:
a) make your application non-modular, for now. This still works for most
things apart from Java FX. Doing non-modular FX is like urinating into a
stiff breeze.
b) use moditect to patch the non-modular dependencies, until modular
ones are available. It's a hack, but it works surprisingly well.
On 11/11/2023 15:42, Bradley Willcott wrote:
Hi John.
Check out this site:
https://www.digitalocean.com/community/tutorials/maven-dependency-tree-resolving-conflicts.
It should give you what you need to know.
Regards,
Brad.
On 11/11/23 06:20, John Manko wrote:
This might not be a purely Netbeans issue, but maybe NB has some
tooling to assist, or someone can answer a quick question.
I'm in the middle of converting Java 8 project to Java 17/21 (A
little late in the game, I know! I'm beholden to other forces beyond
my control.), and I have a library module with a module-info like such:
module com.my.lib {
requires com.google.common;
requires com.google.gson;
requires eclipselink;
requires jakarta.jakartaee.api;
requires java.logging;
requires java.sql;
requires jersey.client;
requires jersey.media.multipart;
requires org.apache.pdfbox;
requires org.apache.fontbox;
exports com.my.package;
}
I get the following error message in Netbeans:
module com.my.lib reads package jakarta.faces.context from both
jakarta.faces.api and jakarta.jakartaee.web.api
What am I'm doing wrong here? Is there any tooling in NB to help
create the module-info based on declared maven dependencies?
Below is are pom.xml deps (test deps removed):
jakarta.platform
jakarta.jakartaee-api
10.0.0
provided
org.eclipse.persistence
eclipselink
4.0.2
provided
org.glassfish.jersey.core
jersey-client
3.1.3
provided
org.glassfish.jersey.media
jersey-media-multipart
3.1.3
provided
com.google.code.gson
gson
2.9.1
com.google.guava
guava
32.1.3-jre
org.apache.pdfbox
pdfbox
3.0.0
Re: Converting Java 8 to 17+, conflicts with modules
Hi John.
Check out this site:
https://www.digitalocean.com/community/tutorials/maven-dependency-tree-resolving-conflicts.
It should give you what you need to know.
Regards,
Brad.
On 11/11/23 06:20, John Manko wrote:
This might not be a purely Netbeans issue, but maybe NB has some
tooling to assist, or someone can answer a quick question.
I'm in the middle of converting Java 8 project to Java 17/21 (A little
late in the game, I know! I'm beholden to other forces beyond my
control.), and I have a library module with a module-info like such:
module com.my.lib {
requires com.google.common;
requires com.google.gson;
requires eclipselink;
requires jakarta.jakartaee.api;
requires java.logging;
requires java.sql;
requires jersey.client;
requires jersey.media.multipart;
requires org.apache.pdfbox;
requires org.apache.fontbox;
exports com.my.package;
}
I get the following error message in Netbeans:
module com.my.lib reads package jakarta.faces.context from both
jakarta.faces.api and jakarta.jakartaee.web.api
What am I'm doing wrong here? Is there any tooling in NB to help
create the module-info based on declared maven dependencies?
Below is are pom.xml deps (test deps removed):
jakarta.platform
jakarta.jakartaee-api
10.0.0
provided
org.eclipse.persistence
eclipselink
4.0.2
provided
org.glassfish.jersey.core
jersey-client
3.1.3
provided
org.glassfish.jersey.media
jersey-media-multipart
3.1.3
provided
com.google.code.gson
gson
2.9.1
com.google.guava
guava
32.1.3-jre
org.apache.pdfbox
pdfbox
3.0.0
Converting Java 8 to 17+, conflicts with modules
This might not be a purely Netbeans issue, but maybe NB has some tooling to
assist, or someone can answer a quick question.
I'm in the middle of converting Java 8 project to Java 17/21 (A little late in
the game, I know! I'm beholden to other forces beyond my control.), and I have
a library module with a module-info like such:
module com.my.lib {
requires com.google.common;
requires com.google.gson;
requires eclipselink;
requires jakarta.jakartaee.api;
requires java.logging;
requires java.sql;
requires jersey.client;
requires jersey.media.multipart;
requires org.apache.pdfbox;
requires org.apache.fontbox;
exports com.my.package;
}
I get the following error message in Netbeans:
module com.my.lib reads package jakarta.faces.context from both
jakarta.faces.api and jakarta.jakartaee.web.api
What am I'm doing wrong here? Is there any tooling in NB to help create the
module-info based on declared maven dependencies?
Below is are pom.xml deps (test deps removed):
jakarta.platform
jakarta.jakartaee-api
10.0.0
provided
org.eclipse.persistence
eclipselink
4.0.2
provided
org.glassfish.jersey.core
jersey-client
3.1.3
provided
org.glassfish.jersey.media
jersey-media-multipart
3.1.3
provided
com.google.code.gson
gson
2.9.1
com.google.guava
guava
32.1.3-jre
org.apache.pdfbox
pdfbox
3.0.0
Re: How to hide a secret value in my Java code?
Thanks to everyone who replied with different solutions, especially to Neil for this detailed explanation about how to use the actions. Le 04/10/2023 à 19:07, Neil C Smith a écrit : On Wed, 4 Oct 2023 at 10:16, Richard Grin wrote: Is it possible to add an environment variable for *only one* Java project in NetBeans? ... I use Maven to build the project. Incidentally, to do this with Maven projects, use the project properties. Under Actions, choose eg. `Run project` or `Run file via main()`. Use the Add button under Set Properties and choose New Environment Variable. This will add to the text area eg. `Env.FOO=bar`. That will be passed along to your project just when you run it via that action. Best wishes, Neil - 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
RE: How to hide a secret value in my Java code?
I use keepass and the command line interface to access passwords through java. Keepass would require a password and I also use a Key File(stored on a server), and by isolate this password in one class, you should be able to limit access to this one source. Steven M Nelligan From: Laszlo Kishalmi Sent: Wednesday, October 4, 2023 11:59 AM To: users@netbeans.apache.org Subject: Re: How to hide a secret value in my Java code? Well, the zero secret problem (the secret which allows you to access further secrets), are usually solved by providing an environment. It could be as simple as an environment variable, or some confinement, entitled with policies. On 10/4/23 08:33, Richard Grin wrote: I answer your question: it could be, for example, a password of a user of a database, put in a Java variable or used in an annotation, or a secret key for an API. Any way of hiding the secret value in the source code would be appropriate., using Maven or nor. Envoyé depuis mon appareil Galaxy Message d'origine De : Alonso Del Arte <mailto:alonso.dela...@gmail.com> Date : 04/10/2023 16:49 (GMT+01:00) À : Richard Grin <mailto:richard.g...@univ-cotedazur.fr>, NetBeans Mailing List <mailto:users@netbeans.apache.org> Objet : Re: How to hide a secret value in my Java code? I suppose you could encrypt the value in a String field or function in one class and then have another class that decrypts that value. This would be a slightly more laborious version of hiding the key under the welcome mat, but not much safer. Maybe I'm misunderstanding. Is the secret value for Maven's use? Al On Wed, Oct 4, 2023 at 5:16 AM Richard Grin mailto:richard.g...@univ-cotedazur.fr>> wrote: Hello, Is it possible to add an environment variable for *only one* Java project in NetBeans? I have added a Windows user variable in the system parameters but I find the process a bit cumbersome. Is there a better way of hiding a secret value than using an environment variable? A similar problem, but perhaps more difficult to solve: how to hide a secret value used in an *annotation* in my code (I can't use System.getenv). I use Maven to build the project. Kind regards, Richard - To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org<mailto:users-unsubscr...@netbeans.apache.org> For additional commands, e-mail: users-h...@netbeans.apache.org<mailto:users-h...@netbeans.apache.org> For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists<https://urldefense.com/v3/__https:/cwiki.apache.org/confluence/display/NETBEANS/Mailing*lists__;Kw!!DZ3fjg!9hiKGcLFI4tkAZSEs4Lhy3FgokI1Bnf7qX2YJ9WPuDS0vLTJpokzK_6-mQu1gSmsvbJvZPxbPtSbRBW3sFNWpxDemQyV$>
Re: How to hide a secret value in my Java code?
On Wed, 4 Oct 2023 at 10:16, Richard Grin wrote: > Is it possible to add an environment variable for *only one* Java > project in NetBeans? ... > I use Maven to build the project. Incidentally, to do this with Maven projects, use the project properties. Under Actions, choose eg. `Run project` or `Run file via main()`. Use the Add button under Set Properties and choose New Environment Variable. This will add to the text area eg. `Env.FOO=bar`. That will be passed along to your project just when you run it via that action. Best wishes, Neil - 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
Re: How to hide a secret value in my Java code?
Well, the zero secret problem (the secret which allows you to access further secrets), are usually solved by providing an environment. It could be as simple as an environment variable, or some confinement, entitled with policies. On 10/4/23 08:33, Richard Grin wrote: I answer your question: it could be, for example, a password of a user of a database, put in a Java variable or used in an annotation, or a secret key for an API. Any way of hiding the secret value in the source code would be appropriate., using Maven or nor. Envoyé depuis mon appareil Galaxy Message d'origine De : Alonso Del Arte Date : 04/10/2023 16:49 (GMT+01:00) À : Richard Grin , NetBeans Mailing List Objet : Re: How to hide a secret value in my Java code? I suppose you could encrypt the value in a String field or function in one class and then have another class that decrypts that value. This would be a slightly more laborious version of hiding the key under the welcome mat, but not much safer. Maybe I'm misunderstanding. Is the secret value for Maven's use? Al On Wed, Oct 4, 2023 at 5:16 AM Richard Grin wrote: Hello, Is it possible to add an environment variable for *only one* Java project in NetBeans? I have added a Windows user variable in the system parameters but I find the process a bit cumbersome. Is there a better way of hiding a secret value than using an environment variable? A similar problem, but perhaps more difficult to solve: how to hide a secret value used in an *annotation* in my code (I can't use System.getenv). I use Maven to build the project. Kind regards, Richard - 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
RE: How to hide a secret value in my Java code?
I answer your question: it could be, for example, a password of a user of a database, put in a Java variable or used in an annotation, or a secret key for an API. Any way of hiding the secret value in the source code would be appropriate., using Maven or nor. Envoyé depuis mon appareil Galaxy Message d'origine De : Alonso Del Arte Date : 04/10/2023 16:49 (GMT+01:00) À : Richard Grin , NetBeans Mailing List Objet : Re: How to hide a secret value in my Java code? I suppose you could encrypt the value in a String field or function in one class and then have another class that decrypts that value. This would be a slightly more laborious version of hiding the key under the welcome mat, but not much safer. Maybe I'm misunderstanding. Is the secret value for Maven's use? Al On Wed, Oct 4, 2023 at 5:16 AM Richard Grin mailto:richard.g...@univ-cotedazur.fr>> wrote: Hello, Is it possible to add an environment variable for *only one* Java project in NetBeans? I have added a Windows user variable in the system parameters but I find the process a bit cumbersome. Is there a better way of hiding a secret value than using an environment variable? A similar problem, but perhaps more difficult to solve: how to hide a secret value used in an *annotation* in my code (I can't use System.getenv). I use Maven to build the project. Kind regards, Richard - To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org<mailto:users-unsubscr...@netbeans.apache.org> For additional commands, e-mail: users-h...@netbeans.apache.org<mailto:users-h...@netbeans.apache.org> For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: How to hide a secret value in my Java code?
I suppose you could encrypt the value in a String field or function in one class and then have another class that decrypts that value. This would be a slightly more laborious version of hiding the key under the welcome mat, but not much safer. Maybe I'm misunderstanding. Is the secret value for Maven's use? Al On Wed, Oct 4, 2023 at 5:16 AM Richard Grin wrote: > Hello, > > Is it possible to add an environment variable for *only one* Java > project in NetBeans? I have added a Windows user variable in the system > parameters but I find the process a bit cumbersome. > > Is there a better way of hiding a secret value than using an environment > variable? > > A similar problem, but perhaps more difficult to solve: how to hide a > secret value used in an *annotation* in my code (I can't use > System.getenv). > > I use Maven to build the project. > > Kind regards, > > Richard > > > - > 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 > >
How to hide a secret value in my Java code?
Hello, Is it possible to add an environment variable for *only one* Java project in NetBeans? I have added a Windows user variable in the system parameters but I find the process a bit cumbersome. Is there a better way of hiding a secret value than using an environment variable? A similar problem, but perhaps more difficult to solve: how to hide a secret value used in an *annotation* in my code (I can't use System.getenv). I use Maven to build the project. Kind regards, Richard - 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
Re: Java Swing Support
On Thu, 24 Aug 2023 at 06:20, Thomas Kellerer wrote: > Didn't NetBeans drop support for one specific Swing framework? > > I think the "Java Swing" project template used that framework, but I can't > remember the name. There used to be support for Swing Application Framework (withdrawn JSR 296), but I thought that was all dropped quite some time before NetBeans was donated here. See also https://bz.apache.org/netbeans/show_bug.cgi?id=204661 Best wishes, Neil - 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
Re: Java Swing Support
Neil C Smith schrieb am 23.08.2023 um 21:55: > > > On Wed, 23 Aug 2023, 14:15 Plaza, Rob (JSC-CD111)[KBR Wyle Services, > LLC], wrote: > > My organization uses Netbeans 11.2. Recently we have noticed ... > > > Recently?! Why NetBeans 11.2? That's 4 years old and unsupported. > There have been 14 releases since then! And another one in a week or > so. > > No support for Swing has been dropped, or is currently intended to be > dropped. The new project templates were reorganized to give priority > to different build systems. What is the name and description on the > template you think is missing? And from what version? > Didn't NetBeans drop support for one specific Swing framework? I think the "Java Swing" project template used that framework, but I can't remember the name. - 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
Re: Java Swing Support
On Wed, 23 Aug 2023, 14:15 Plaza, Rob (JSC-CD111)[KBR Wyle Services, LLC], wrote: > My organization uses Netbeans 11.2. Recently we have noticed ... > Recently?! Why NetBeans 11.2? That's 4 years old and unsupported. There have been 14 releases since then! And another one in a week or so. No support for Swing has been dropped, or is currently intended to be dropped. The new project templates were reorganized to give priority to different build systems. What is the name and description on the template you think is missing? And from what version? Best wishes, Neil
Re: Java Swing Support
You can choose the 'Java Application' under the Projects. It is a Java SE application. java swing support is still there including JDK17. I have been using Netbeans since version 5, I always have switched to the next version. Right now, it is Netbeans 18. I did not have any issue using the old apps with the new version Netbeans and new version Java. My java 8 apps that have Swing GUI are running with JDK 17 normally. = Mithat Karaoglu Email: mithat.karao...@gmail.com On Wed, Aug 23, 2023 at 9:15 AM Plaza, Rob (JSC-CD111)[KBR Wyle Services, LLC] wrote: > My organization uses Netbeans 11.2. Recently we have noticed that the > NetBeans “New Project” window no longer has an option to create a new Java > Swing project. Is Netbeans dropping support for Swing? Please tell me what > is happening and what will happen going forward to newer versions of > NetBeans. >
Java Swing Support
My organization uses Netbeans 11.2. Recently we have noticed that the NetBeans "New Project" window no longer has an option to create a new Java Swing project. Is Netbeans dropping support for Swing? Please tell me what is happening and what will happen going forward to newer versions of NetBeans.
NB-18 with Java 20.x
Just before I go ahead I'd like to ask if NB-18 is compatible with Java-20.x? Thanks folks! -- ArbolOne.ca Using Fire Fox and Thunderbird. ArbolOne is composed of students and volunteers dedicated to providing free services to charitable organizations. ArbolOne on Java Development is in progress [ í ] - 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
Re: java Netbeans 18 Test compile all JSP during build with jakarta namespace
Just for completeness, this is the errormesg: error: incompatible types: javax.servlet.http.HttpServletRequest cannot be converted to jakarta.servlet.http.HttpServletRequest On Thu, 27 Jul 2023 at 20:00, Stefan Geelen wrote: > HI, > > I have a project I converted from javax.* to jakarta.* namespace where > needed. > At that time I was using Netbeans16 > It was not possible to compile the jsp file (Test compile all JSP during > build) > > I recently switched to NetBeans 18 but still cannot compile there JSPs. > > Is this not possible or do I need to modify some settings ? > > Regards, > > Stefan >
java Netbeans 18 Test compile all JSP during build with jakarta namespace
HI, I have a project I converted from javax.* to jakarta.* namespace where needed. At that time I was using Netbeans16 It was not possible to compile the jsp file (Test compile all JSP during build) I recently switched to NetBeans 18 but still cannot compile there JSPs. Is this not possible or do I need to modify some settings ? Regards, Stefan
[ java ] Help needed: Netbeans Plattform Application (RELEASE150) with JavaHelp not working
Hi there, I am currently trying to set up a NetBeans Platform Application with JavaHelp. It seems to compile correct and there are no Error logs, but when running the application neither context-sensitive Help via F1 nor is there any content under Help | Help Contents. The application is build in Java 17 and can be found under: https://github.com/mwulle/rcp-javahelp-example. I've used these sources trying to get it working: - 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 - https://dzone.com/articles/nb-how-create-javahelp-mavenized I would really appreciate helpful tips or possible reasons for the cause of this problem :) Cheers Melvin publickey - mail@mwulle.com - 0x961695F4.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
RE: ENC: [Java] - Não dá opção de executar o programa no NetBeans
Hi Thomas Keller! Now it worked, I updated to Netbeans version 17 as you recommended. Previously I had downgraded from 12.1 to 12, then I upgraded to 14 but it only worked with 17. Thanks a lot for the help, De: Thomas Kellerer Enviado: quinta-feira, 9 de março de 2023 16:01 Para: users@netbeans.apache.org Assunto: Re: ENC: [Java] - Não dá opção de executar o programa no NetBeans I had many problems with NetBeans and Gradle before NetBeans 16u1 Please try to upgrade your NetBeans version (e.g. to the current version 17) and try again. Clayton Calixto schrieb am 09.03.2023 um 19:39: > > > -- > *De:* Clayton Calixto > *Enviado:* quinta-feira, 9 de março de 2023 15:03 > *Para:* users-subscr...@netbeans.apache.org > > *Assunto:* ENC: [Java] - Não dá opção de executar o programa no NetBeans > > -- > *De:* Clayton Calixto > *Enviado:* quinta-feira, 9 de março de 2023 15:02 > *Para:* users@netbeans.apache.org > *Assunto:* [Java] - Não dá opção de executar o programa no NetBeans > [Java] - Não dá opção de executar o programa no NetBeans > <https://www.guj.com.br/t/nao-da-opcao-de-executar-o-programa-no-netbeans/429737> > > Hi friends, Could you help us with the event that takes place in the Netbeans > IDE that I put in the community? It is not possible to run a simple program! > > Se eeror follow link of the GUJ: Não dá opção de executar o programa no > NetBeans > <https://www.guj.com.br/t/nao-da-opcao-de-executar-o-programa-no-netbeans/429737> > > Thanks, > > > - 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
Re: ENC: [Java] - Não dá opção de executar o programa no NetBeans
I had many problems with NetBeans and Gradle before NetBeans 16u1 Please try to upgrade your NetBeans version (e.g. to the current version 17) and try again. Clayton Calixto schrieb am 09.03.2023 um 19:39: -- *De:* Clayton Calixto *Enviado:* quinta-feira, 9 de março de 2023 15:03 *Para:* users-subscr...@netbeans.apache.org *Assunto:* ENC: [Java] - Não dá opção de executar o programa no NetBeans -- *De:* Clayton Calixto *Enviado:* quinta-feira, 9 de março de 2023 15:02 *Para:* users@netbeans.apache.org *Assunto:* [Java] - Não dá opção de executar o programa no NetBeans [Java] - Não dá opção de executar o programa no NetBeans <https://www.guj.com.br/t/nao-da-opcao-de-executar-o-programa-no-netbeans/429737> Hi friends, Could you help us with the event that takes place in the Netbeans IDE that I put in the community? It is not possible to run a simple program! Se eeror follow link of the GUJ: Não dá opção de executar o programa no NetBeans <https://www.guj.com.br/t/nao-da-opcao-de-executar-o-programa-no-netbeans/429737> Thanks, - 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
ENC: [Java] - Não dá opção de executar o programa no NetBeans
De: Clayton Calixto Enviado: quinta-feira, 9 de março de 2023 15:03 Para: users-subscr...@netbeans.apache.org Assunto: ENC: [Java] - Não dá opção de executar o programa no NetBeans De: Clayton Calixto Enviado: quinta-feira, 9 de março de 2023 15:02 Para: users@netbeans.apache.org Assunto: [Java] - Não dá opção de executar o programa no NetBeans [Java] - Não dá opção de executar o programa no NetBeans<https://www.guj.com.br/t/nao-da-opcao-de-executar-o-programa-no-netbeans/429737> Hi friends, Could you help us with the event that takes place in the Netbeans IDE that I put in the community? It is not possible to run a simple program! Se eeror follow link of the GUJ: Não dá opção de executar o programa no NetBeans<https://www.guj.com.br/t/nao-da-opcao-de-executar-o-programa-no-netbeans/429737> Thanks,
Re: java enterprise
Hi Robert, Hope you are doing well. Can I ask which option you chose when you created the project? Did you choose New - > "Java with Maven" -> "Web Application", or did you choose New -> "Java with Maven" -> "Enterprise Application"? I do not believe that the "Enterprise Application" option has been updated to work with recent versions of Jakarta EE/Java EE. However, the "Web Application" should work (although there are some issues that still need ironing out). If you create the "Web Application" option, and then create a "Jakarta EE 10" project, you should be able to build and deploy to GlassFish 7 immediately. There should be no need to update POM dependencies. The persistence.xml is certainly empty, but that is so you can add your applicable connections. I also did receive the error message when trying to create "Session Bean from Entity Classes", so there is certainly an issue there: Cannot be generated because EJB Lite classes are not available on project classpath Hope this helps a bit. Thanks Josh Juneau On Fri, Mar 3, 2023 at 11:54 AM wrote: > Hello, > > > > I try to develop an java enterprise web program with netbeans 17, > glassfish 7 and maven. > > > > First, I’ve to update manually « org.apache.maven.plugins /maven war > plugin » to 3.3.2 and « maven-dependency-plugin » to 3.5.0 in pom.xml > because the project can’t build and compile. > > > > When trying to create the entity class from database, I get the connection > but I’ve a message « the project has an invalid persistence.xml file. > Indeed, this file is nearby empty. I have to complete it. > > > > And when trying to create session bean from entity, I’ve an error > message : « Cannot be generated because EJB Lite classes are not available on > project classpath. > « . > > > > That’s it. > > > > Can you help me ? > > > > Many thanks. > > > > Best regards. > > > > Robert Simons > > > > > > > > > > > > > > >
java enterprise
Hello, I try to develop an java enterprise web program with netbeans 17, glassfish 7 and maven. First, I've to update manually < org.apache.maven.plugins /maven war plugin > to 3.3.2 and < maven-dependency-plugin > to 3.5.0 in pom.xml because the project can't build and compile. When trying to create the entity class from database, I get the connection but I've a message < the project has an invalid persistence.xml file. Indeed, this file is nearby empty. I have to complete it. And when trying to create session bean from entity, I've an error message : < Cannot be generated because EJB Lite classes are not available on project classpath. < . That's it. Can you help me ? Many thanks. Best regards. Robert Simons
Re: Easier way to change Java platform for all modules of a Gradle project
Thomas Kellerer schrieb am 27.02.2023 um 08:38: > Hello, > > we have a Gradle project with about 40sub-projects. > > I am running NetBeans on Java 17, but the project still uses Java 11. > > However, it does not seem to be enough to switch the JDK on the main Gradle > project. > I need to change the JDK for each sub-project individually (using the > project's properties). > > Is there an easier way to do this? Ah, this is available in NetBeans 17 :) Thank you! Regards Thomas - 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
Easier way to change Java platform for all modules of a Gradle project
Hello, we have a Gradle project with about 40sub-projects. I am running NetBeans on Java 17, but the project still uses Java 11. However, it does not seem to be enough to switch the JDK on the main Gradle project. I need to change the JDK for each sub-project individually (using the project's properties). Is there an easier way to do this? To be honest, I would have expected that NetBeans honors the selection on the main Gradle project for every sub-project. Regards Thomas - 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
Re: A plain Java module shared between multiple Netbeans modules
On Wed, 1 Feb 2023 at 10:36, Admin Netcrystals wrote: > I use Maven. Does this make a difference? Only that the way to do it might be a little different to that mentioned on those pages. > Honestly speaking wrapping each plan Java module is quite a lit if work and > putting them all in one wrapper module is also not a good idea (I have 40 of > them). Personally, if they're a suite of plain Java modules that work together, I'd wrap them in a single shared NetBeans module. Depends what split makes sense in the architecture of your application. But if they're all individual then you'll also have to consider any dependencies between them, what makes sense to be activated independently, and which are intended to be exposed as API. eg. with your A, B and C examples Wrapper wraps A, B and C NX and NY both depend on Wrapper. Best wishes, Neil - 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
Re: A plain Java module shared between multiple Netbeans modules
I use Maven. Does this make a difference?Honestly speaking wrapping each plan Java module is quite a lit if work and putting them all in one wrapper module is also not a good idea (I have 40 of them).However, I understand that Netbeans has to track the dependencies so I will wrap each module. Makes more sense to me.Thanks. Netcrystals Von: Neil C Smith Gesendet: Dienstag, Jänner 31, 2023 5:21 PMAn: ad...@netcrystals.at Cc: users@netbeans.apache.org Betreff: Re: A plain Java module shared between multiple Netbeans modules On Tue, 31 Jan 2023 at 15:53, Admin Netcrystals wrote: > I have got a question regarding modules in Rich Client Platform. > > I have got some plain Java modules. They are not related to Netbeans in any way. They are general libraries. Lets call them A, B and C. > > Now, I program a Netbeans program having two Netbeans Modules, lets say NX an NY. > > NX needs A and B, so I add them. > NY needs B and C, so I add them. > > The problem is that if NX and NY are added to the platform B is loaded twice. > > I suppose that I have to set the scope of B to provided in either NX or NY. However, this seems to be steange to me. > > Can someone tell me the correct way? Check out - https://netbeans.apache.org/wiki/DevFaqWrapperModules.html https://netbeans.apache.org/wiki/DevFaqWhenUseWrapperModule.html Are you using an Ant or Maven project for the RCP? Best wishes, Neil - 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
Re: A plain Java module shared between multiple Netbeans modules
On Tue, 31 Jan 2023 at 15:53, Admin Netcrystals wrote: > I have got a question regarding modules in Rich Client Platform. > > I have got some plain Java modules. They are not related to Netbeans in any > way. They are general libraries. Lets call them A, B and C. > > Now, I program a Netbeans program having two Netbeans Modules, lets say NX an > NY. > > NX needs A and B, so I add them. > NY needs B and C, so I add them. > > The problem is that if NX and NY are added to the platform B is loaded twice. > > I suppose that I have to set the scope of B to provided in either NX or NY. > However, this seems to be steange to me. > > Can someone tell me the correct way? Check out - https://netbeans.apache.org/wiki/DevFaqWrapperModules.html https://netbeans.apache.org/wiki/DevFaqWhenUseWrapperModule.html Are you using an Ant or Maven project for the RCP? Best wishes, Neil - 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
A plain Java module shared between multiple Netbeans modules
Hello,I have got a question regarding modules in Rich Client Platform.I have got some plain Java modules. They are not related to Netbeans in any way. They are general libraries. Lets call them A, B and C.Now, I program a Netbeans program having two Netbeans Modules, lets say NX an NY.NX needs A and B, so I add them.NY needs B and C, so I add them.The problem is that if NX and NY are added to the platform B is loaded twice.I suppose that I have to set the scope of B to provided in either NX or NY. However, this seems to be steange to me.Can someone tell me the correct way?Thanks.Regards Netcrystals - 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
Using the Libre Office UNO Java interface on MacOS with NetBeans
Hi, I am trying to write Java programs to make use of the Libre Office UNO Java interface on MacOS. I am aware of: https://wiki.documentfoundation.org/Main_Page https://wiki.documentfoundation.org/Documentation/DevGuide/LibreOffice_Developers_Guide https://api.libreoffice.org/examples/DevelopersGuide/examples.html#FirstSteps https://api.libreoffice.org/examples/examples.html#Java_examples https://wiki.openoffice.org/wiki/Documentation/DevGuide/OpenOffice.org_Developers_Guide I have succeeded in getting half a dozen of the examples to work. I have NetBeans projects for each of these. Getting the dependencies right was a struggle ! I had to make code changes so that the examples would run on MacOS (changes to the bootstrap to account for a Mac application code structure) and the bug in released version 7.4 issue that now has a fix. I am happy to share these with anyone else that is trying to use UNO. I am perplexed by the UNO interface and unable to access the attributes of the sub-types of the shapes in a diagram. Help would be very welcome ! So, if anyone else is using UNO or trying to use UNO with Libre Office or Apache Open Office do make contact. David Gradwell
Re: NetBeans 16 running on JDK 17 + Gradle 7.5/Java 11 not working
László Kishalmi schrieb am 25.01.2023 um 21:26: > You are most probably seeing https://github.com/apache/netbeans/pull/5271 > It is fixed in NB17 which has the first rc available last week, > or as a workaround use an up-to date Java 17 (Java 17.0.6) wich has a dot in > it's version. Ah, great. Upgrading to 17.0.6 did the trick. Thanks a lot. - 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
Re: NetBeans 16 running on JDK 17 + Gradle 7.5/Java 11 not working
You are most probably seeing https://github.com/apache/netbeans/pull/5271
It is fixed in NB17 which has the first rc available last week,
or as a workaround use an up-to date Java 17 (Java 17.0.6) wich has a dot
in it's version.
On Wed, Jan 25, 2023 at 12:39 AM Thomas Kellerer wrote:
> Hello,
>
> after the 16u1 path, I was able to work with my Gradle 7.5 again (thanks!)
>
> So far I have been running NetBeans on Java 11 (from adoptium if that
> matters) and had no problems.
>
> However, when I start NetBeans using Java 17 (but keep the Gradle projects
> at Java 11), NetBeans doesn't open the projects any more.
>
> This is a Gradle project with about 20 modules. The top project is loaded,
> but none of the modules. e.g. the "Projects" window is empty after a
> restart with Java 17.
>
> In the logfile I can see the following error (once for each module):
>
> INFO
> [org.netbeans.modules.gradle.execute.GradleDistributionProviderImpl]:
> Gradle Distribution for Gradle: server[FULL] is
> GradleDistribution{gradleUserHome=C:\Users\tkellerer\.gradle,
> distributionDir=C:\Users\tkellerer\.gradle\wrapper\dists\gradle-7.5.1-all\1ehga6e77gqps5uk2kc5kf1vc\gradle-7.5.1,
> distributionURI=
> https://services.gradle.org/distributions/gradle-7.5.1-all.zip,
> version=Gradle 7.5.1}
> WARNING [org.netbeans.modules.project.ui.OpenProjectList]
> java.lang.StringIndexOutOfBoundsException: begin 1, end -1, length 4
> at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4601)
> at java.base/java.lang.String.substring(String.java:2704)
> at
> org.netbeans.modules.gradle.GradleJavaCompatProblemsProvider.getJavaMajorVersion(GradleJavaCompatProblemsProvider.java:147)
> at
> org.netbeans.modules.gradle.GradleJavaCompatProblemsProvider.getJavaVersion(GradleJavaCompatProblemsProvider.java:128)
> at
> org.netbeans.modules.gradle.GradleJavaCompatProblemsProvider.getProblems(GradleJavaCompatProblemsProvider.java:91)
> at
> org.netbeans.spi.project.ui.support.UILookupMergerSupport$ProjectProblemsProviderImpl.getProblems(UILookupMergerSupport.java:274)
> at
> org.netbeans.api.project.ui.ProjectProblems.isBroken(ProjectProblems.java:58)
> at
> org.netbeans.modules.gradle.NbGradleProjectImpl$ProjectOpenedHookImpl.lambda$projectOpened$0(NbGradleProjectImpl.java:689)
> at
> org.netbeans.modules.gradle.NbGradleProjectImpl$ProjectOpenedHookImpl.projectOpened(NbGradleProjectImpl.java:696)
> at
> org.netbeans.spi.project.ui.ProjectOpenedHook$1.projectOpened(ProjectOpenedHook.java:60)
> at
> org.netbeans.spi.project.ui.support.UILookupMergerSupport$OpenHookImpl.projectOpened(UILookupMergerSupport.java:219)
> at
> org.netbeans.spi.project.ui.ProjectOpenedHook$1.projectOpened(ProjectOpenedHook.java:60)
> [catch] at
> org.netbeans.modules.project.ui.OpenProjectList.notifyOpened(OpenProjectList.java:1321)
> at
> org.netbeans.modules.project.ui.OpenProjectList.doOpenProject(OpenProjectList.java:1402)
> at
> org.netbeans.modules.project.ui.OpenProjectList.open(OpenProjectList.java:848)
> at org.netbeans.modules.project.ui.groups.Group.open(Group.java:590)
> at
> org.netbeans.modules.project.ui.groups.Group.setActiveGroup(Group.java:180)
> at
> org.netbeans.modules.project.ui.groups.GroupsMenu$4$1.run(GroupsMenu.java:155)
> at
> org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
> at
> org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
> at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
> at
> org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
>
> "server" is the name of one of the modules of the project.
>
> I have configured NetBeans to "Prefer to use Gradle Wrapper that Comes
> with the Project".
>
> Gradle 7.5 is compatible with Java 17, but my project is defined to use
> Java 11.
> It seems NetBeans/Gradle has a problem if the default JDK is not the same
> as the project's JDK.
>
> Any ideas?
>
> Regards
> Thomas
>
>
> -
> 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
>
>
NetBeans 16 running on JDK 17 + Gradle 7.5/Java 11 not working
Hello,
after the 16u1 path, I was able to work with my Gradle 7.5 again (thanks!)
So far I have been running NetBeans on Java 11 (from adoptium if that matters)
and had no problems.
However, when I start NetBeans using Java 17 (but keep the Gradle projects at
Java 11), NetBeans doesn't open the projects any more.
This is a Gradle project with about 20 modules. The top project is loaded, but
none of the modules. e.g. the "Projects" window is empty after a restart with
Java 17.
In the logfile I can see the following error (once for each module):
INFO [org.netbeans.modules.gradle.execute.GradleDistributionProviderImpl]:
Gradle Distribution for Gradle: server[FULL] is
GradleDistribution{gradleUserHome=C:\Users\tkellerer\.gradle,
distributionDir=C:\Users\tkellerer\.gradle\wrapper\dists\gradle-7.5.1-all\1ehga6e77gqps5uk2kc5kf1vc\gradle-7.5.1,
distributionURI=https://services.gradle.org/distributions/gradle-7.5.1-all.zip,
version=Gradle 7.5.1}
WARNING [org.netbeans.modules.project.ui.OpenProjectList]
java.lang.StringIndexOutOfBoundsException: begin 1, end -1, length 4
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4601)
at java.base/java.lang.String.substring(String.java:2704)
at
org.netbeans.modules.gradle.GradleJavaCompatProblemsProvider.getJavaMajorVersion(GradleJavaCompatProblemsProvider.java:147)
at
org.netbeans.modules.gradle.GradleJavaCompatProblemsProvider.getJavaVersion(GradleJavaCompatProblemsProvider.java:128)
at
org.netbeans.modules.gradle.GradleJavaCompatProblemsProvider.getProblems(GradleJavaCompatProblemsProvider.java:91)
at
org.netbeans.spi.project.ui.support.UILookupMergerSupport$ProjectProblemsProviderImpl.getProblems(UILookupMergerSupport.java:274)
at
org.netbeans.api.project.ui.ProjectProblems.isBroken(ProjectProblems.java:58)
at
org.netbeans.modules.gradle.NbGradleProjectImpl$ProjectOpenedHookImpl.lambda$projectOpened$0(NbGradleProjectImpl.java:689)
at
org.netbeans.modules.gradle.NbGradleProjectImpl$ProjectOpenedHookImpl.projectOpened(NbGradleProjectImpl.java:696)
at
org.netbeans.spi.project.ui.ProjectOpenedHook$1.projectOpened(ProjectOpenedHook.java:60)
at
org.netbeans.spi.project.ui.support.UILookupMergerSupport$OpenHookImpl.projectOpened(UILookupMergerSupport.java:219)
at
org.netbeans.spi.project.ui.ProjectOpenedHook$1.projectOpened(ProjectOpenedHook.java:60)
[catch] at
org.netbeans.modules.project.ui.OpenProjectList.notifyOpened(OpenProjectList.java:1321)
at
org.netbeans.modules.project.ui.OpenProjectList.doOpenProject(OpenProjectList.java:1402)
at
org.netbeans.modules.project.ui.OpenProjectList.open(OpenProjectList.java:848)
at org.netbeans.modules.project.ui.groups.Group.open(Group.java:590)
at
org.netbeans.modules.project.ui.groups.Group.setActiveGroup(Group.java:180)
at
org.netbeans.modules.project.ui.groups.GroupsMenu$4$1.run(GroupsMenu.java:155)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at
org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
"server" is the name of one of the modules of the project.
I have configured NetBeans to "Prefer to use Gradle Wrapper that Comes with the
Project".
Gradle 7.5 is compatible with Java 17, but my project is defined to use Java 11.
It seems NetBeans/Gradle has a problem if the default JDK is not the same as
the project's JDK.
Any ideas?
Regards
Thomas
-
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
Re: Tools > Options > Java > Gradle drop down list
btw good that you brought this up since I found a UI bug while trying to reproduce the issue you encountered. https://github.com/apache/netbeans/pull/5343 best regards, michael On 22.01.23 15:49, Emma Atkinson wrote: Hello I'm using NB IDE 16 on UbuntuStudio and I have a minor problem with a dropdown list of Gradle Distribution Versions. To find the drop down list I am talking about navigate as follows: Tools > Options > Java > Gradle > Execution > Gradle Distribution Version > Use Standard Gradle Version I think the problem is that the text I want to see is white text on a white background for most of the entries. The Gradle version I am using is black text on white background. There is a 7.5 in the list too. There are two options with red text on white background way down the list (2.13 and 2.3) The drop down list is long but mainly white options. Running the cursor over the list causes the option under the cursor to change to white on blue background, which I can read. Hence, it's just a mild irritation I don't encounter often. Is there something I can do to fix this for me and get it out of my head space? Thank you Emma - 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
Re: Tools > Options > Java > Gradle drop down list
I was able to reproduce the mentioned behavior on GTK+ Look and Feel with light theme. Please use the default FlatLaf fLight or FlatLaf Dark look and feels for the best result. Unfortunately recent changes in GTK, GTK themes and JVM GTK Support provide an uncertain ground for NetBeans to built on, so we left our GTK support as is. Use FlatLaf where we have greater control to make the IDE look good either Light or Dark. On 1/22/23 06:49, Emma Atkinson wrote: Hello I'm using NB IDE 16 on UbuntuStudio and I have a minor problem with a dropdown list of Gradle Distribution Versions. To find the drop down list I am talking about navigate as follows: Tools > Options > Java > Gradle > Execution > Gradle Distribution Version > Use Standard Gradle Version I think the problem is that the text I want to see is white text on a white background for most of the entries. The Gradle version I am using is black text on white background. There is a 7.5 in the list too. There are two options with red text on white background way down the list (2.13 and 2.3) The drop down list is long but mainly white options. Running the cursor over the list causes the option under the cursor to change to white on blue background, which I can read. Hence, it's just a mild irritation I don't encounter often. Is there something I can do to fix this for me and get it out of my head space? Thank you Emma - 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
Re: Tools > Options > Java > Gradle drop down list
Hi Michael, I'm using the default LAF, pale greys, white background for text input. Have not yet tried the dark LAF. On Sun, 22 Jan 2023, 15:05 Michael Bien, wrote: > what look and feel are you using for NetBeans? Did you change the default? > > the white items shouldn't be white, those should be "grayed out" to make > the other versions stick out more. Red means no longer supported. > > -mbien > > On 22.01.23 15:49, Emma Atkinson wrote: > > Hello > > I'm using NB IDE 16 on UbuntuStudio and I have a minor problem with a > > dropdown list of Gradle Distribution Versions. To find the drop down > > list I am talking about navigate as follows: > > > > Tools > Options > Java > Gradle > Execution > Gradle Distribution > > Version > Use Standard Gradle Version > > > > I think the problem is that the text I want to see is white text on a > > white background for most of the entries. The Gradle version I am > > using is black text on white background. There is a 7.5 in the list > > too. There are two options with red text on white background way down > > the list (2.13 and 2.3) The drop down list is long but mainly white > > options. Running the cursor over the list causes the option under the > > cursor to change to white on blue background, which I can read. > > Hence, it's just a mild irritation I don't encounter often. > > > > Is there something I can do to fix this for me and get it out of my > > head space? > > > > Thank you > > Emma > > > > > > > >
Re: Tools > Options > Java > Gradle drop down list
Hello Emma. I chose 'FlatLaf Dark' as my look and feel in (Tools > Options > Appearance > Preferred look and feel.), reduces my eyestrain a bit. Following the steps you provided I was able to successfully duplicate you process. I recommend you change the look and feel, at least to test your provided process. I hope this helps. On 2023-01-22 9:49 a.m., Emma Atkinson wrote: Hello I'm using NB IDE 16 on UbuntuStudio and I have a minor problem with a dropdown list of Gradle Distribution Versions. To find the drop down list I am talking about navigate as follows: Tools > Options > Java > Gradle > Execution > Gradle Distribution Version > Use Standard Gradle Version I think the problem is that the text I want to see is white text on a white background for most of the entries. The Gradle version I am using is black text on white background. There is a 7.5 in the list too. There are two options with red text on white background way down the list (2.13 and 2.3) The drop down list is long but mainly white options. Running the cursor over the list causes the option under the cursor to change to white on blue background, which I can read. Hence, it's just a mild irritation I don't encounter often. Is there something I can do to fix this for me and get it out of my head space? Thank you Emma - 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
Re: Tools > Options > Java > Gradle drop down list
what look and feel are you using for NetBeans? Did you change the default? the white items shouldn't be white, those should be "grayed out" to make the other versions stick out more. Red means no longer supported. -mbien On 22.01.23 15:49, Emma Atkinson wrote: Hello I'm using NB IDE 16 on UbuntuStudio and I have a minor problem with a dropdown list of Gradle Distribution Versions. To find the drop down list I am talking about navigate as follows: Tools > Options > Java > Gradle > Execution > Gradle Distribution Version > Use Standard Gradle Version I think the problem is that the text I want to see is white text on a white background for most of the entries. The Gradle version I am using is black text on white background. There is a 7.5 in the list too. There are two options with red text on white background way down the list (2.13 and 2.3) The drop down list is long but mainly white options. Running the cursor over the list causes the option under the cursor to change to white on blue background, which I can read. Hence, it's just a mild irritation I don't encounter often. Is there something I can do to fix this for me and get it out of my head space? Thank you Emma - 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
Tools > Options > Java > Gradle drop down list
Hello I'm using NB IDE 16 on UbuntuStudio and I have a minor problem with a dropdown list of Gradle Distribution Versions. To find the drop down list I am talking about navigate as follows: Tools > Options > Java > Gradle > Execution > Gradle Distribution Version > Use Standard Gradle Version I think the problem is that the text I want to see is white text on a white background for most of the entries. The Gradle version I am using is black text on white background. There is a 7.5 in the list too. There are two options with red text on white background way down the list (2.13 and 2.3) The drop down list is long but mainly white options. Running the cursor over the list causes the option under the cursor to change to white on blue background, which I can read. Hence, it's just a mild irritation I don't encounter often. Is there something I can do to fix this for me and get it out of my head space? Thank you Emma
New Simple Gradle Java Application with TestNG
When NB IDE 16.0 creates a "simple" new Gradle Java project I presume it executes *gradle init *with some command line options. The *gradle init* command offers a choice of test frameworks. Netbeans chooses *JUnit Jupiter*. However, the *gradle init* command also offers *JUnit 4* (gradle's default), *TestNG* and *Spock*. Is there a way for me to get NB IDE to choose the TestNG option? More generally speaking, what are the best ways to create projects in NB 16 using the other *gradle init* choices? Thank you
Re: Netbeans only Java 1.8 or less?
Java Module System is not supported, however Java classes with recent Java versions are. So you can have a module using Java 11, 17 On Wed, Jan 4, 2023 at 10:00 AM Admin Netcrystals wrote: > Is it correct that java classes and modules used for building a Rich > Client Netbeans Platform App should have no Jave Source Format larger than > 1.8? Can I use module-info.java JigSaw features and pack those files to an > nbm module? > Thanks. > > Netcrystals > - 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
Re: Netbeans only Java 1.8 or less?
The question is why you would want to do that, the NetBeans modules themselves provide the kinds of features that Jigsaw provides. Gj On Wed, Jan 4, 2023 at 7:00 PM Admin Netcrystals wrote: > > Is it correct that java classes and modules used for building a Rich Client > Netbeans Platform App should have no Jave Source Format larger than 1.8? Can > I use module-info.java JigSaw features and pack those files to an nbm module? > Thanks. > > Netcrystals > - 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: 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
Netbeans only Java 1.8 or less?
Is it correct that java classes and modules used for building a Rich Client Netbeans Platform App should have no Jave Source Format larger than 1.8? Can I use module-info.java JigSaw features and pack those files to an nbm module?Thanks. Netcrystals - 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
Re: [java] locale is changed for derby db in embedded mode
Hi,
It looks not local issue but classpath issue.
I think there are missing optional dependencies outside Netbeans.
Arnaud
Le jeu. 22 déc. 2022, 06:30, Orange Trees a
écrit :
> Hello,
>
> Any suggestions please what and where should I check?
>
> Regards,
> Orange
> --
> *From:* Orange Trees
> *Sent:* 26 November 2022 10:23
> *To:* users@netbeans.apache.org
> *Subject:* [java] locale is changed for derby db in embedded mode
>
> Hello,
>
> There is a simple program which gives different results when I run it from
> the NetBeans IDE and outside IDE:
>
> package derbytest4;
>
> import java.sql.*;
> import java.util.*;
>
> public class DerbyTest4 {
> public static void main(String... args) throws Exception {
> println("Default locale = " + Locale.getDefault());
> Connection conn =
> DriverManager.getConnection("jdbc:derby:memory:db;create=true");
> conn.prepareStatement("CREATE TABLE t (a INT, b INT)").execute();
>
> try {
>
> DriverManager.getConnection("jdbc:derby:memory:db;shutdown=true");
> }
> catch (Exception ex) {
> println(ex.getMessage());
> }
> }
> private static void println(String text) { System.out.println(text); }
> }
>
> Note: Derby DB of the latest version jars should be included to the
> project.
>
> The result from NetBeans IDE is:
> Default locale = en_US
> 08006.D : [0] memory:db
>
> The result from outside IDE is (which is expected):
> Default locale = en_US
> Database 'memory:db' shutdown.
>
>
> As I was hinted in the Apache Derby mailing lists, this behaviour of
> Apache DB message not being printed correctly is related to locale
> settings, although in both cases locale seems ok.
>
> For the older projects, which I have imported from the previous machine,
> everything works as expected, problem is with new projects.
>
> I'm using NetBeans 14 and 13. I believe it is related to some settings,
> although I wasn't able to find something by myself.
>
> My environment:
> Virtualization: oracle
> Operating System: Linux Mint 19.3
> Kernel: Linux 5.0.0-32-generic
> Architecture: x86-64
>
> openjdk version "17.0.5" 2022-10-18
> OpenJDK Runtime Environment Temurin-17.0.5+8 (build 17.0.5+8)
> OpenJDK 64-Bit Server VM Temurin-17.0.5+8 (build 17.0.5+8, mixed mode,
> sharing)
>
> Regards,
> Orange
>
>
>
>
Re: [java] locale is changed for derby db in embedded mode
Hello,
Any suggestions please what and where should I check?
Regards,
Orange
From: Orange Trees
Sent: 26 November 2022 10:23
To: users@netbeans.apache.org
Subject: [java] locale is changed for derby db in embedded mode
Hello,
There is a simple program which gives different results when I run it from the
NetBeans IDE and outside IDE:
package derbytest4;
import java.sql.*;
import java.util.*;
public class DerbyTest4 {
public static void main(String... args) throws Exception {
println("Default locale = " + Locale.getDefault());
Connection conn =
DriverManager.getConnection("jdbc:derby:memory:db;create=true");
conn.prepareStatement("CREATE TABLE t (a INT, b INT)").execute();
try {
DriverManager.getConnection("jdbc:derby:memory:db;shutdown=true");
}
catch (Exception ex) {
println(ex.getMessage());
}
}
private static void println(String text) { System.out.println(text); }
}
Note: Derby DB of the latest version jars should be included to the project.
The result from NetBeans IDE is:
Default locale = en_US
08006.D : [0] memory:db
The result from outside IDE is (which is expected):
Default locale = en_US
Database 'memory:db' shutdown.
As I was hinted in the Apache Derby mailing lists, this behaviour of Apache DB
message not being printed correctly is related to locale settings, although in
both cases locale seems ok.
For the older projects, which I have imported from the previous machine,
everything works as expected, problem is with new projects.
I'm using NetBeans 14 and 13. I believe it is related to some settings,
although I wasn't able to find something by myself.
My environment:
Virtualization: oracle
Operating System: Linux Mint 19.3
Kernel: Linux 5.0.0-32-generic
Architecture: x86-64
openjdk version "17.0.5" 2022-10-18
OpenJDK Runtime Environment Temurin-17.0.5+8 (build 17.0.5+8)
OpenJDK 64-Bit Server VM Temurin-17.0.5+8 (build 17.0.5+8, mixed mode, sharing)
Regards,
Orange
Re: [java] Netbeans 16 platforms
>>>I was wondering if you were affected by this too No, I wasn't. The moment my JDK was set correctly in NB16 I was able to select the same list of remote connections I had before with NB12.5 and they worked immediately. FYI: when selecting Tools -> Java Platforms I've always seen the remote sessions, irrespective of the JDK version I had selected in NB16. -- Best rgds, Geert On 11/12/2022 13:42, Michael Bien wrote: I see - good that it is working for you. There is a related bug where the remote platform can be selected but it wouldn't do anything if you run the project. This would only happen if the remote platforms were imported from an older NB release. Since you mentioned importing them in the first mail I was wondering if you were affected by this too. this should hopefully fix it: https://github.com/apache/netbeans/pull/5067 best regards, michael On 10.12.22 17:53, Geert Vancompernolle wrote: Follow this <https://netbeans.apache.org/kb/docs/java/javase-embedded.html> meticulously. The most important thing you should take care of is that the JDK version selected for your Netbeans project on your Windows (or whatever) machine is the same as the one installed on the Raspberry Pi. In my case, I overlooked the fact that the JDK for my Netbeans project on my Windows PC was defaulted to JDK17 (due to the switch to NB16) while the one on my Raspberry Pi was/is set to JDK11. Changing the JDK for my Netbeans project on my Windows machine to JDK11 was in the end solving the issue. Best rgds, -- Geert On 2022/12/10 16:31:42 Michael Bien wrote: > how did you solve the issue? > > a similar issue just got filed which reports that the migration of > remote platforms doesn't work: > > https://github.com/apache/netbeans/issues/5065 > > Looks like the config import did work in your case or did you patch > something? > > -mbien > > > > On 10.12.22 16:00, Geert Vancompernolle wrote: > > Ok, found the issue myself. Everything is working fine again, I can > > see all my remote platforms. > > > > > - > 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 > > --
Re: [java] Netbeans 16 platforms
I see - good that it is working for you. There is a related bug where the remote platform can be selected but it wouldn't do anything if you run the project. This would only happen if the remote platforms were imported from an older NB release. Since you mentioned importing them in the first mail I was wondering if you were affected by this too. this should hopefully fix it: https://github.com/apache/netbeans/pull/5067 best regards, michael On 10.12.22 17:53, Geert Vancompernolle wrote: Follow this <https://netbeans.apache.org/kb/docs/java/javase-embedded.html> meticulously. The most important thing you should take care of is that the JDK version selected for your Netbeans project on your Windows (or whatever) machine is the same as the one installed on the Raspberry Pi. In my case, I overlooked the fact that the JDK for my Netbeans project on my Windows PC was defaulted to JDK17 (due to the switch to NB16) while the one on my Raspberry Pi was/is set to JDK11. Changing the JDK for my Netbeans project on my Windows machine to JDK11 was in the end solving the issue. Best rgds, -- Geert On 2022/12/10 16:31:42 Michael Bien wrote: > how did you solve the issue? > > a similar issue just got filed which reports that the migration of > remote platforms doesn't work: > > https://github.com/apache/netbeans/issues/5065 > > Looks like the config import did work in your case or did you patch > something? > > -mbien > > > > On 10.12.22 16:00, Geert Vancompernolle wrote: > > Ok, found the issue myself. Everything is working fine again, I can > > see all my remote platforms. > > > > > - > 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 > > -- -- Best rgds, Geert Vancompernolle Varendreef 9 8020 Hertsberge (Oostkamp) 050/220005 0479/680987 -- What3Words <https://what3words.com/> *greets.crowning.founded*
RE: Re: [java] Netbeans 16 platforms
Follow this <https://netbeans.apache.org/kb/docs/java/javase-embedded.html> meticulously. The most important thing you should take care of is that the JDK version selected for your Netbeans project on your Windows (or whatever) machine is the same as the one installed on the Raspberry Pi. In my case, I overlooked the fact that the JDK for my Netbeans project on my Windows PC was defaulted to JDK17 (due to the switch to NB16) while the one on my Raspberry Pi was/is set to JDK11. Changing the JDK for my Netbeans project on my Windows machine to JDK11 was in the end solving the issue. Best rgds, -- Geert On 2022/12/10 16:31:42 Michael Bien wrote: > how did you solve the issue? > > a similar issue just got filed which reports that the migration of > remote platforms doesn't work: > > https://github.com/apache/netbeans/issues/5065 > > Looks like the config import did work in your case or did you patch > something? > > -mbien > > > > On 10.12.22 16:00, Geert Vancompernolle wrote: > > Ok, found the issue myself. Everything is working fine again, I can > > see all my remote platforms. > > > > > - > 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 > > -- -- Best rgds, Geert Vancompernolle Varendreef 9 8020 Hertsberge (Oostkamp) 050/220005 0479/680987 -- What3Words <https://what3words.com/> *greets.crowning.founded*
Re: [java] Netbeans 16 platforms
how did you solve the issue? a similar issue just got filed which reports that the migration of remote platforms doesn't work: https://github.com/apache/netbeans/issues/5065 Looks like the config import did work in your case or did you patch something? -mbien On 10.12.22 16:00, Geert Vancompernolle wrote: Ok, found the issue myself. Everything is working fine again, I can see all my remote platforms. - 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
Re: [java] Netbeans 16 platforms
Ok, found the issue myself. Everything is working fine again, I can see all my remote platforms. -- Best rgds, Geert On 08/12/2022 16:54, Geert Vancompernolle wrote: Hi, I just upgraded Netbeans from 12.5 to 16. I have quite a few Remote Java SE platforms (connecting to different Raspberry Pi SBCs) and they all work perfect with Netbeans 12.5. However, if I create a new Java project in Netbeans 16 and I want to connect the project to one of the Remote Java SE platforms, I don't see any at all. I only see the Project Platform choice for the Runtime Platform field in the Project Properties diaglogue box. Is this a known issue? - 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
[java] Netbeans 16 platforms
Hi, I just upgraded Netbeans from 12.5 to 16. I have quite a few Remote Java SE platforms (connecting to different Raspberry Pi SBCs) and they all work perfect with Netbeans 12.5. However, if I create a new Java project in Netbeans 16 and I want to connect the project to one of the Remote Java SE platforms, I don't see any at all. I only see the Project Platform choice for the Runtime Platform field in the Project Properties diaglogue box. Is this a known issue? -- Best rgds, Geert - 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
[java] Netbeans profiler calibration failed
Hi, Profiler calibration on Mac M1 Pro failed. Thanks in advance for any suggestion/fix. *** Profiler message (Mon Dec 05 21:58:59 CET 2022): Starting target = application... /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/bin/java = -agentpath:/Applications/NetBeans/Apache NetBeans = 12.5.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/= mac/libprofilerinterface.jnilib = -Xbootclasspath/a:/Applications/NetBeans/Apache NetBeans = 12.5.app/Contents/Resources/NetBeans/netbeans/profiler/lib/jfluid-server.j= ar:/Applications/NetBeans/Apache NetBeans = 12.5.app/Contents/Resources/NetBeans/netbeans/profiler/lib/jfluid-server-1= 5.jar org.netbeans.lib.profiler.server.ProfilerServer = /Applications/NetBeans/Apache NetBeans = 12.5.app/Contents/Resources/NetBeans/netbeans/profiler/lib/deployed/jdk16/= mac 5141 10 Profiler+Calibration+Run *** Profiler warning (Mon Dec 05 22:01:33 CET 2022): timed out while = trying to connect to the target JVM. *** Profiler error (Mon Dec 05 22:01:33 CET 2022): connection with = server not open
[java] locale is changed for derby db in embedded mode
Hello,
There is a simple program which gives different results when I run it from the
NetBeans IDE and outside IDE:
package derbytest4;
import java.sql.*;
import java.util.*;
public class DerbyTest4 {
public static void main(String... args) throws Exception {
println("Default locale = " + Locale.getDefault());
Connection conn =
DriverManager.getConnection("jdbc:derby:memory:db;create=true");
conn.prepareStatement("CREATE TABLE t (a INT, b INT)").execute();
try {
DriverManager.getConnection("jdbc:derby:memory:db;shutdown=true");
}
catch (Exception ex) {
println(ex.getMessage());
}
}
private static void println(String text) { System.out.println(text); }
}
Note: Derby DB of the latest version jars should be included to the project.
The result from NetBeans IDE is:
Default locale = en_US
08006.D : [0] memory:db
The result from outside IDE is (which is expected):
Default locale = en_US
Database 'memory:db' shutdown.
As I was hinted in the Apache Derby mailing lists, this behaviour of Apache DB
message not being printed correctly is related to locale settings, although in
both cases locale seems ok.
For the older projects, which I have imported from the previous machine,
everything works as expected, problem is with new projects.
I'm using NetBeans 14 and 13. I believe it is related to some settings,
although I wasn't able to find something by myself.
My environment:
Virtualization: oracle
Operating System: Linux Mint 19.3
Kernel: Linux 5.0.0-32-generic
Architecture: x86-64
openjdk version "17.0.5" 2022-10-18
OpenJDK Runtime Environment Temurin-17.0.5+8 (build 17.0.5+8)
OpenJDK 64-Bit Server VM Temurin-17.0.5+8 (build 17.0.5+8, mixed mode, sharing)
Regards,
Orange
Re: How to maintain *.java and *.form in different directories?
On 18.10.22 19:24, Thorsten Schöning wrote: But images referenced in the *.form files should work in "resources", correct? If i remember correctly, GUI designer and *.form files have nothing to do at all with the build process (in the sense of Gradle), it is part of generating sources and happens before build, so accessing images in forms is all about adapting relative paths to images (if needed) … Bernd - 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
Re: How to maintain *.java and *.form in different directories?
Guten Tag Neil C Smith, am Mittwoch, 19. Oktober 2022 um 14:27 schrieben Sie: > Either we're using different definitions, or there's something odd in > your configuration.[...] I repeated my tests and *.form files are not deployed by default, as long as they are stored alongside *.java. I placed them in "resources" next to images for test purposes and moved them back at some point, though they were still part of the resulting JAR sometimes. But I might have simply made something different wrong, now with closed IDE and stuff the files are not part fo the JAR. >> But images referenced in the *.form files should work in "resources", >> correct? > Do they not? It seems to work in the IDE, but the goal is a test and deployment pipeline without the IDE and am not there yet to test it myself. Therefore I hoped someone could tell me beforehand if I'm doing things entirely wrong or expecting too much or ... :-) Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: +49 5151- 9468- 0 Tel: +49 5151- 9468-55 Mobil: +49 178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. Mit freundlichen Grüßen, Thorsten Schöning Telefon: +49 5151 9468-55 Fax: E-Mail: tschoen...@am-soft.de AM-Soft IT-Service - Bitstore Hameln GmbH Brandenburger Straße 7c 31789 Hameln Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Hinweise zum Datenschutz: bitstore.group/datenschutz - 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
Re: How to maintain *.java and *.form in different directories?
On Wed, 19 Oct 2022 at 13:29, Bernd Michaely wrote: > In doubt *.form files could be deleted from the build dir after > compilation and before deployment, e.g. using doFirst in the deployment > task, something like this: .. > (never tried that myself…) So did you check if they're in there to start with? That was the point of my question, and why I'd be interested to see a project shared where that is the case. Best wishes, Neil - 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
Re: How to maintain *.java and *.form in different directories?
Indeed Gradle keeps different types of files like sources and resources in different subdirectories. *.form files are another type of files, which are created and needed even before compilation and are not to be deployed, so they would reside in their own subdirectory aside sources and resources. Gradle would need to be configured so that NB will find them despite being in a different dir (don't know if that is possible), and to exclude them from deployment… In doubt *.form files could be deleted from the build dir after compilation and before deployment, e.g. using doFirst in the deployment task, something like this: https://docs.gradle.org/current/userguide/common_caching_problems.html#custom_actions (never tried that myself…) Bernd On 18.10.22 18:57, Neil C Smith wrote: On Tue, 18 Oct 2022 at 17:51, Thorsten Schöning wrote: Mostly that non-Java is exactly what is meant to be maintained in "resources". There's not that much difference between images or XML form files. This might even allow to not publish those files as part of the deployment, configure different set of rules in IDEs etc. There's a massive difference between images and .form files - .form files are not meant to be published as part of the deployment. Also, as far as NetBeans is concerned, they are one file - pros and cons to that. Neil - 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: 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
Re: How to maintain *.java and *.form in different directories?
On Tue, 18 Oct 2022 at 18:24, Thorsten Schöning wrote: > > Guten Tag Neil C Smith, > am Dienstag, 18. Oktober 2022 um 18:57 schrieben Sie: > > > There's a massive difference between images and .form files - .form > > files are not meant to be published as part of the deployment. > > But they are when using Gradle. Either we're using different definitions, or there's something odd in your configuration. I suggest sharing a simple project that illustrates the problem. > > Also, as far as NetBeans is concerned, they are one file - pros and > > cons to that. > > But images referenced in the *.form files should work in "resources", > correct? Do they not? Neil - 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
Re: How to maintain *.java and *.form in different directories?
Guten Tag Neil C Smith, am Dienstag, 18. Oktober 2022 um 18:57 schrieben Sie: > There's a massive difference between images and .form files - .form > files are not meant to be published as part of the deployment. But they are when using Gradle. > Also, as far as NetBeans is concerned, they are one file - pros and > cons to that. But images referenced in the *.form files should work in "resources", correct? Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: +49 5151- 9468- 0 Tel: +49 5151- 9468-55 Mobil: +49 178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. Mit freundlichen Grüßen, Thorsten Schöning Telefon: +49 5151 9468-55 Fax: E-Mail: tschoen...@am-soft.de AM-Soft IT-Service - Bitstore Hameln GmbH Brandenburger Straße 7c 31789 Hameln Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Hinweise zum Datenschutz: bitstore.group/datenschutz - 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
