Re: netbeans-vm: Java available?
Yep: netbeans-vm:~$ java -version openjdk version "1.8.0_252" OpenJDK Runtime Environment (build 1.8.0_252-8u252-b09-1~16.04-b09) OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode) netbeans-vm:~$ javac -version javac 1.8.0_252 El 29/5/20 a las 20:20, Neil C Smith escribió: On Fri, 29 May 2020 at 19:11, Matthias Bläsing wrote: It also feels nuts as our primary language has perfectly working parsers and so I'd like to implement the parser converter in java. Well, it's got OpenJDK 8 on it. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: netbeans-vm: Java available?
Hi again, Having said that, we may want to set up a Jenkins job to prepare all that stuff you want to prepare in another Jenkins worker box (and not on our netbeans-vm), and then download the results to the netbeans-vm box periodically (or on demand after the job finishes successfully). Cheers, Antonio El 30/5/20 a las 9:47, antonio escribió: Yep: netbeans-vm:~$ java -version openjdk version "1.8.0_252" OpenJDK Runtime Environment (build 1.8.0_252-8u252-b09-1~16.04-b09) OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode) netbeans-vm:~$ javac -version javac 1.8.0_252 El 29/5/20 a las 20:20, Neil C Smith escribió: On Fri, 29 May 2020 at 19:11, Matthias Bläsing wrote: It also feels nuts as our primary language has perfectly working parsers and so I'd like to implement the parser converter in java. Well, it's got OpenJDK 8 on it. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[DISCUSS] update centre and plugin portal for dev (master) builds
Hi, Just bringing the discussion part of https://github.com/apache/netbeans-website/pull/473 on to here. Matthias correctly pointed out in the above PR that we've not kept redirects for the master branch update centre and plugin portal always in line with the current release branch. Not just for 12.0 - probably over each release for the last year. This is one reason a current issue with the plugin portal may have gone unnoticed. Over the last year or two we've moved to having all inbound links from the IDE come in under https://netbeans.apache.org/nb. This has a variety of benefits, one being we can easily manage redirecting things to the right place in https://github.com/apache/netbeans-website/blob/master/netbeans.apache.org/src/content/.htaccess Useful, particularly during transition from Oracle to Apache infrastructure, to change things without requiring IDE updates. It has also given us predictable links for update centre and plugin portal for each release and master, even with underlying changes. After 12.0 is released we should probably make the following 3 changes, only the third part of which was really cause for discussion on the PR. # Stage 1 Change the dev redirects in the .htaccess to - Redirect 302 /nb/updates/dev/ https://netbeans-vm.apache.org/uc/dev/ Redirect 302 /nb/plugins/dev/ https://plugins.netbeans.apache.org/data/dev/ This will require setting up /dev endpoints for the UC on the VM and on the plugin portal. Initially as symlinks for 12.0? # Stage 2 Once the above is working, we can remove a lot of the redirects and move everything up a level - then we have no need to update the .htaccess for each release - Redirect 302 /nb/updates/ https://netbeans-vm.apache.org/uc/ Redirect 302 /nb/plugins/ https://plugins.netbeans.apache.org/data/ We could also just proxy those links from those places without redirect? Might help with issue of being blocked when processing a lot of updates? # Stage 3 We can then make a decision on what update centre and plugin portal catalogues make sense for dev builds. IMO, and the bit that really caused discussion, we adjust the latest master build on Jenkins to serve the NBMs and point at that (via the VM). I think this is what happened before the Apache transition? https://builds.apache.org/view/M-R/view/NetBeans/job/netbeans-TLP/job/netbeans/job/master/lastSuccessfulBuild/artifact/ Antonio raised concerns on the PR that infra might not appreciate that - obviously we don't have to do it, but considering we've been distributing beta builds direct from Jenkins, it's probably a very minor increase in bandwidth. Would it actually be useful? We could also consider a dev / next specific section on the plugin portal to allow plugin authors to test with master? Or to try new plugin portal features? Sorry about the long email about what feel like minor changes, but given the discussion on the PR, be good to know this is what we're heading for, or not. Losing track of how much of this has happened by release manager convention, and how much is an actual plan! :-) Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Beta 6 Step Backwards
I just loaded beta 6 and it wants to load nb-javac. The last beta I used, beta 4, allowed me to choose with a check box if I wanted it. So I'm curious, should I file a JIRA report or was a decision made to return to nb-javac? I then looked into the plugins dialog where something I never noticed before called User Installed Plugins is really nb-javac. Previously, to remove it I deleted the three nb-javac files directly from the modules folder of userdir leaving behind the JavaFX plugin. This time from the Plugins dialog I selected it and said to uninstall. What happened next was bizarre, the entire modules folder that also included the JavaFX for Windows module was deleted. If I restarted NetBeans and went to the plugins dialog it complained that the Linux and Mac JavaFX plugins could not be found. What am I missing here? Ken
Re: Beta 6 Step Backwards
Just make sure you really have Beta 6, maybe start with a fresh user directory. Beta 6 is explicitly there because it fixes bugs around your scenario and indeed you should be able to decide to not install nb-javac. Also, can you think carefully about the subject lines of your e-mails. In this case, an informative subject line would be “Forced to install nb-javac with Beta 6”, if this is what the problem is. The less emotion and the more concise steps to reproduce a problem you provide, the better. Gj On Sat, 30 May 2020 at 18:13, Kenneth Fogel wrote: > I just loaded beta 6 and it wants to load nb-javac. The last beta I used, > beta 4, allowed me to choose with a check box if I wanted it. So I’m > curious, should I file a JIRA report or was a decision made to return to > nb-javac? I then looked into the plugins dialog where something I never > noticed before called User Installed Plugins is really nb-javac. > Previously, to remove it I deleted the three nb-javac files directly from > the modules folder of userdir leaving behind the JavaFX plugin. This time > from the Plugins dialog I selected it and said to uninstall. What happened > next was bizarre, the entire modules folder that also included the JavaFX > for Windows module was deleted. If I restarted NetBeans and went to the > plugins dialog it complained that the Linux and Mac JavaFX plugins could > not be found. What am I missing here? > > > > Ken > > > > > > >
Re: [DISCUSS] update centre and plugin portal for dev (master) builds
Hi all, I regret having to say this whole thing of UC and plugins is quite complicated for me :-). During the years we have been improving things (adding https, proxying for the old Oracle hosted update center in netbeans-vm.apache.org/pluginportal2, etc.) As far as I understand the PP2 will remain untouched. This is so because URLs are already fixed in code and because NetBeans < 12.0 uses plain http for plugins, whereas 12.0+ uses https. For simplicity, let's abbreviate: NAO - netbeans.apache.org PNAO - plugins.netbeans.apache.org (hosted as virtual server in netbeans-vm.apache.org [1]) What about this? https://NAO/nb/updates/dev -302-> https://PNAO/dev/updates https://NAO/nb/plugins/dev -302-> https://PNAO/dev/plugins https://NAO/nb/updates -302-> https://PNAO/12.0/updates https://NAO/nb/plugins -302-> https://PNAO/12.0/plugins Of course this will require hosting the binaries in PNAO (which may be somewhat slow, but faster than hosting them in the Jenkins builds). We are already synchronizing javadocs, so there's no reason why we can't synchronize binaries (note that Jenkins builds don't support rsync, though, so we'll have to download whole zips, and this may be slow). What say? Did I understand things correctly? Will this work? Cheers, Antonio [1] https://github.com/apache/infrastructure-puppet/blob/9bb6860a8f07c3a04e77177ba752012fb0c629d9/data/nodes/netbeans-vm.apache.org.yaml#L207 El 30/5/20 a las 15:32, Neil C Smith escribió: Hi, Just bringing the discussion part of https://github.com/apache/netbeans-website/pull/473 on to here. Matthias correctly pointed out in the above PR that we've not kept redirects for the master branch update centre and plugin portal always in line with the current release branch. Not just for 12.0 - probably over each release for the last year. This is one reason a current issue with the plugin portal may have gone unnoticed. Over the last year or two we've moved to having all inbound links from the IDE come in under https://netbeans.apache.org/nb. This has a variety of benefits, one being we can easily manage redirecting things to the right place in https://github.com/apache/netbeans-website/blob/master/netbeans.apache.org/src/content/.htaccess Useful, particularly during transition from Oracle to Apache infrastructure, to change things without requiring IDE updates. It has also given us predictable links for update centre and plugin portal for each release and master, even with underlying changes. After 12.0 is released we should probably make the following 3 changes, only the third part of which was really cause for discussion on the PR. # Stage 1 Change the dev redirects in the .htaccess to - Redirect 302 /nb/updates/dev/ https://netbeans-vm.apache.org/uc/dev/ Redirect 302 /nb/plugins/dev/ https://plugins.netbeans.apache.org/data/dev/ This will require setting up /dev endpoints for the UC on the VM and on the plugin portal. Initially as symlinks for 12.0? # Stage 2 Once the above is working, we can remove a lot of the redirects and move everything up a level - then we have no need to update the .htaccess for each release - Redirect 302 /nb/updates/ https://netbeans-vm.apache.org/uc/ Redirect 302 /nb/plugins/ https://plugins.netbeans.apache.org/data/ We could also just proxy those links from those places without redirect? Might help with issue of being blocked when processing a lot of updates? # Stage 3 We can then make a decision on what update centre and plugin portal catalogues make sense for dev builds. IMO, and the bit that really caused discussion, we adjust the latest master build on Jenkins to serve the NBMs and point at that (via the VM). I think this is what happened before the Apache transition? https://builds.apache.org/view/M-R/view/NetBeans/job/netbeans-TLP/job/netbeans/job/master/lastSuccessfulBuild/artifact/ Antonio raised concerns on the PR that infra might not appreciate that - obviously we don't have to do it, but considering we've been distributing beta builds direct from Jenkins, it's probably a very minor increase in bandwidth. Would it actually be useful? We could also consider a dev / next specific section on the plugin portal to allow plugin authors to test with master? Or to try new plugin portal features? Sorry about the long email about what feel like minor changes, but given the discussion on the PR, be good to know this is what we're heading for, or not. Losing track of how much of this has happened by release manager convention, and how much is an actual plan! :-) Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To u
jlink in JavaFX project
This is a more general question. NB 12 b6 now has a jlink option for the JavaFX Simple project. Cool, I haven't used this feature of Java yet. As the module-info.java file did not indicate what to include or exclude (remember I don't know how to use jlink) I believe that what was generated in the target/image folder was the equivalent of a JRE. I make this assumption because the folder is 60 mb in size. Heck, I just searched thru the image and found keytool.exe. I should ask the jlink group at Oracle about this. My ignorance is on display. So here is my question. Without jpackage creating an executable package what is the value of jlink? To everyone who is working on NB you have my utmost respect. You are doing amazing work. I'll be doing a Jakarta EE tech talk at the Eclipse foundation on June 9 at 11 AM DST and I will be using NetBeans (they know I will be). Ken
Re: Beta 6 Step Backwards
On Sat, 30 May 2020 at 17:22, Geertjan Wielenga wrote: > Just make sure you really have Beta 6, maybe start with a fresh user > directory. Beta 6 is explicitly there because it fixes bugs around your > scenario and indeed you should be able to decide to not install nb-javac. To be clear, the bug fix in beta6 was to make that dialog cancellable (amongst other issues). It still shows up on project load or import settings. That is a much bigger change to be looked at during 12.1 phase. The addition of checkboxes to choose only JavaFX only happens in the New Project wizard. It doesn't solve the problem in other areas. The dialog showing up is not a step backwards - follow same steps in 11.3 or any 12.0 beta and you'll see the same, just not be able to cancel it and carry on working. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Beta 6 Step Backwards
Hi, Am Samstag, den 30.05.2020, 16:13 + schrieb Kenneth Fogel: > I just loaded beta 6 and it wants to load nb-javac. The last beta I > used, beta 4, allowed me to choose with a check box if I wanted it. > So I’m curious, should I file a JIRA report or was a decision made to > return to nb-javac? Only if you can reproduce a problem. nbjavac was and will never be optional for running NetBeans Java Editing on JDK 8. It is required in that case. > I then looked into the plugins dialog where something I never noticed > before called User Installed Plugins is really nb-javac. No it is not. nbjavac is _one of several_ plugins. Ensure you check "Show details" in the plugins dialog, then the individual plugins are listed. This behaviour (to group all "non core" plugins under "User installed plugins" is in NetBeans at least since 8 and most probably even longer. > Previously, to remove it I deleted the three nb-javac files directly > from the modules folder of userdir leaving behind the JavaFX plugin. That will still work. > This time from the Plugins dialog I selected it and said to > uninstall. What happened next was bizarre, the entire modules folder > that also included the JavaFX for Windows module was deleted. You removed _all_ user installed plugins and not only nbjavac was removed, but JavaFX also. > If I restarted NetBeans and went to the plugins dialog it complained > that the Linux and Mac JavaFX plugins could not be found. What am I > missing here? I think the comments above give some insight. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] update centre and plugin portal for dev (master) builds
Hi, Thanks for thoughts. On Sat, 30 May 2020 at 17:27, antonio wrote: > As far as I understand the PP2 will remain untouched. This is so because > URLs are already fixed in code and because NetBeans < 12.0 uses plain > http for plugins, whereas 12.0+ uses https. It's only fixed in code for 11.0 and below. I'm fairly sure the JSON file is accurate for the old builds too thanks to Eric - https://github.com/apache/netbeans-jenkins-lib/blob/master/meta/netbeansrelease.json I switched plugins to https and via NAO in 11.1. As soon as we decide to stop supporting 11.0 we're in a better position, although that links direct to old plugin portal anyway. > What about this? > > https://NAO/nb/updates/dev -302-> https://PNAO/dev/updates > https://NAO/nb/plugins/dev -302-> https://PNAO/dev/plugins > https://NAO/nb/updates -302-> https://PNAO/12.0/updates > https://NAO/nb/plugins -302-> https://PNAO/12.0/plugins We already redirect updates via the NetBeans VM - there's probably no point in hitting the plugin centre for it - the NBMs are actually downloaded from Apache mirrors for all releases. But the catalog XML file itself must be on the VM. Also, the point would be to have updates/12.0, updates/dev, etc. on the other end so we can blanket redirect nb/plugins/* and nb/updates/* We only need two redirects then. > Of course this will require hosting the binaries in PNAO (which may be > somewhat slow, but faster than hosting them in the Jenkins builds). Release update NBMs are already served by the Apache mirrors. The key thing served from Jenkins for dev (as is already the case with all the 12.0 betas) would be the catalog XML for update checking. Unless a spec version in that is updated, no NBM will be downloaded. It will be a seldom used testing thing for developers, if it's useful at all?! And we could just keep the dev UC pointing at the last release 12.0 as we have done. It's just better if we can handle this on the other end with the others, rather than treat dev differently IMO. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: jlink in JavaFX project
On 5/30/2020 9:41 AM, Kenneth Fogel wrote: This is a more general question. NB 12 b6 now has a jlink option for the JavaFX Simple project. Cool, I haven’t used this feature of Java yet. As the module-info.java file did not indicate what to include or exclude (remember I don’t know how to use jlink) I believe that what was generated in the target/image folder was the equivalent of a JRE. I make this assumption because the folder is 60 mb in size. Heck, I just searched thru the image and found keytool.exe. I should ask the jlink group at Oracle about this. My ignorance is on display. So here is my question. Without jpackage creating an executable package what is the value of jlink? I'm not sure what you're looking for, or what jdk you're running, and I don't know anything about jpackage other than what I can intuit from the name. I think it's recent, There is: jdk-14.0.1/bin/jpackage.exe. Also in case you're not aware, you can cd /target/image/bin and then, assuming your package is org.play.proj and the main class is App, run your app by doing ./java org.play.proj.App -ernie To everyone who is working on NB you have my utmost respect. You are doing amazing work. I’ll be doing a Jakarta EE tech talk at the Eclipse foundation on June 9 at 11 AM DST and I will be using NetBeans (they know I will be). Ken - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
RE: jlink in JavaFX project
Thank you for the info. jpackage was first fxpackage, then became jpackage, then was dropped when FX was dropped, and then just returned. One of its uses was to create installable packages, either exe, dmg or whatever your flavour of Linux needs. I am not fond of CLI, I believe my picture is on dart boards of Linux aficionados everywhere 😊. I believe your CLI suggestion is using the system installed Java runtime on your system and not the jlink Java runtime. On my system if I went into the image folder I could get it to run with the jlink rather than system Java with "bin\java com.mycompany.test2.App". The old Shade plugin could do that but it required Java installed. I thought jlink working with jpackage could do that. Answering your email forced me to looking into the image folder. Hiding in a file called modules in the lib folder is your code. So when you enter "bin\java com.mycompany.test2.App" Its pulling the code from the images\lib\modules. Therefore it does not depend on the presence of a system Java. What I am not sure of is whether or not this image will work on a Mac or Linux, my guess is it won't. So it all comes back to what is the purpose of jlink if it doesn't also create something that allows you to run your code with a single command on the command line or as a clickable file in a GUI system. I appreciate that it creates an instance of Java that can run your code without needing to download Java first. It feels like NetBeans is not completing the task by just using jlink. As always I assume the misunderstanding of its purpose is my fault. Bringing this back to NetBeans, I think that generated code should include comments that either explain the purpose or provide a link to documentation that explains it. I think that jlink is an incomplete solution and that should be explained. Could explain why modules still have not caught on. Now I will crawl back under my rock. Ken -Original Message- From: Ernie Rael Sent: May 30, 2020 1:47 PM To: dev@netbeans.apache.org Subject: Re: jlink in JavaFX project On 5/30/2020 9:41 AM, Kenneth Fogel wrote: > > This is a more general question. NB 12 b6 now has a jlink option for > the JavaFX Simple project. Cool, I haven’t used this feature of Java > yet. As the module-info.java file did not indicate what to include or > exclude (remember I don’t know how to use jlink) I believe that what > was generated in the target/image folder was the equivalent of a JRE. > I make this assumption because the folder is 60 mb in size. Heck, I > just searched thru the image and found keytool.exe. I should ask the > jlink group at Oracle about this. My ignorance is on display. > > So here is my question. Without jpackage creating an executable > package what is the value of jlink? > I'm not sure what you're looking for, or what jdk you're running, and I don't know anything about jpackage other than what I can intuit from the name. I think it's recent, There is: jdk-14.0.1/bin/jpackage.exe. Also in case you're not aware, you can cd /target/image/bin and then, assuming your package is org.play.proj and the main class is App, run your app by doing ./java org.play.proj.App -ernie > > To everyone who is working on NB you have my utmost respect. You are > doing amazing work. I’ll be doing a Jakarta EE tech talk at the > Eclipse foundation on June 9 at 11 AM DST and I will be using NetBeans > (they know I will be). > > Ken > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: jlink in JavaFX project
What happened when you put “jlink netbeans” into Google search? I see lots of articles... Gj On Sat, 30 May 2020 at 20:26, Kenneth Fogel wrote: > Thank you for the info. jpackage was first fxpackage, then became > jpackage, then was dropped when FX was dropped, and then just returned. One > of its uses was to create installable packages, either exe, dmg or whatever > your flavour of Linux needs. > > I am not fond of CLI, I believe my picture is on dart boards of Linux > aficionados everywhere 😊. I believe your CLI suggestion is using the > system installed Java runtime on your system and not the jlink Java > runtime. On my system if I went into the image folder I could get it to run > with the jlink rather than system Java with "bin\java > com.mycompany.test2.App". The old Shade plugin could do that but it > required Java installed. I thought jlink working with jpackage could do > that. > > Answering your email forced me to looking into the image folder. Hiding in > a file called modules in the lib folder is your code. So when you enter > "bin\java com.mycompany.test2.App" Its pulling the code from the > images\lib\modules. Therefore it does not depend on the presence of a > system Java. What I am not sure of is whether or not this image will work > on a Mac or Linux, my guess is it won't. > > So it all comes back to what is the purpose of jlink if it doesn't also > create something that allows you to run your code with a single command on > the command line or as a clickable file in a GUI system. I appreciate that > it creates an instance of Java that can run your code without needing to > download Java first. It feels like NetBeans is not completing the task by > just using jlink. As always I assume the misunderstanding of its purpose is > my fault. > > Bringing this back to NetBeans, I think that generated code should include > comments that either explain the purpose or provide a link to documentation > that explains it. I think that jlink is an incomplete solution and that > should be explained. Could explain why modules still have not caught on. > Now I will crawl back under my rock. > > Ken > > > -Original Message- > From: Ernie Rael > Sent: May 30, 2020 1:47 PM > To: dev@netbeans.apache.org > Subject: Re: jlink in JavaFX project > > On 5/30/2020 9:41 AM, Kenneth Fogel wrote: > > > > This is a more general question. NB 12 b6 now has a jlink option for > > the JavaFX Simple project. Cool, I haven’t used this feature of Java > > yet. As the module-info.java file did not indicate what to include or > > exclude (remember I don’t know how to use jlink) I believe that what > > was generated in the target/image folder was the equivalent of a JRE. > > I make this assumption because the folder is 60 mb in size. Heck, I > > just searched thru the image and found keytool.exe. I should ask the > > jlink group at Oracle about this. My ignorance is on display. > > > > So here is my question. Without jpackage creating an executable > > package what is the value of jlink? > > > I'm not sure what you're looking for, or what jdk you're running, and I > don't know anything about jpackage other than what I can intuit from the > name. I think it's recent, > > There is: jdk-14.0.1/bin/jpackage.exe. > > Also in case you're not aware, you can cd > /target/image/bin and then, assuming your package is > org.play.proj and the main class is App, run your app by doing > > ./java org.play.proj.App > > -ernie > > > > To everyone who is working on NB you have my utmost respect. You are > > doing amazing work. I’ll be doing a Jakarta EE tech talk at the > > Eclipse foundation on June 9 at 11 AM DST and I will be using NetBeans > > (they know I will be). > > > > Ken > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: jlink in JavaFX project
Maybe read this: https://medium.com/azulsystems/using-jlink-to-build-java-runtimes-for-non-modular-applications-9568c5e70ef4 Gj On Sat, 30 May 2020 at 20:32, Geertjan Wielenga wrote: > What happened when you put “jlink netbeans” into Google search? I see lots > of articles... > > Gj > > On Sat, 30 May 2020 at 20:26, Kenneth Fogel > wrote: > >> Thank you for the info. jpackage was first fxpackage, then became >> jpackage, then was dropped when FX was dropped, and then just returned. One >> of its uses was to create installable packages, either exe, dmg or whatever >> your flavour of Linux needs. >> >> I am not fond of CLI, I believe my picture is on dart boards of Linux >> aficionados everywhere 😊. I believe your CLI suggestion is using the >> system installed Java runtime on your system and not the jlink Java >> runtime. On my system if I went into the image folder I could get it to run >> with the jlink rather than system Java with "bin\java >> com.mycompany.test2.App". The old Shade plugin could do that but it >> required Java installed. I thought jlink working with jpackage could do >> that. >> >> Answering your email forced me to looking into the image folder. Hiding >> in a file called modules in the lib folder is your code. So when you enter >> "bin\java com.mycompany.test2.App" Its pulling the code from the >> images\lib\modules. Therefore it does not depend on the presence of a >> system Java. What I am not sure of is whether or not this image will work >> on a Mac or Linux, my guess is it won't. >> >> So it all comes back to what is the purpose of jlink if it doesn't also >> create something that allows you to run your code with a single command on >> the command line or as a clickable file in a GUI system. I appreciate that >> it creates an instance of Java that can run your code without needing to >> download Java first. It feels like NetBeans is not completing the task by >> just using jlink. As always I assume the misunderstanding of its purpose is >> my fault. >> >> Bringing this back to NetBeans, I think that generated code should >> include comments that either explain the purpose or provide a link to >> documentation that explains it. I think that jlink is an incomplete >> solution and that should be explained. Could explain why modules still have >> not caught on. Now I will crawl back under my rock. >> >> Ken >> >> >> -Original Message- >> From: Ernie Rael >> Sent: May 30, 2020 1:47 PM >> To: dev@netbeans.apache.org >> Subject: Re: jlink in JavaFX project >> >> On 5/30/2020 9:41 AM, Kenneth Fogel wrote: >> > >> > This is a more general question. NB 12 b6 now has a jlink option for >> > the JavaFX Simple project. Cool, I haven’t used this feature of Java >> > yet. As the module-info.java file did not indicate what to include or >> > exclude (remember I don’t know how to use jlink) I believe that what >> > was generated in the target/image folder was the equivalent of a JRE. >> > I make this assumption because the folder is 60 mb in size. Heck, I >> > just searched thru the image and found keytool.exe. I should ask the >> > jlink group at Oracle about this. My ignorance is on display. >> > >> > So here is my question. Without jpackage creating an executable >> > package what is the value of jlink? >> > >> I'm not sure what you're looking for, or what jdk you're running, and I >> don't know anything about jpackage other than what I can intuit from the >> name. I think it's recent, >> >> There is: jdk-14.0.1/bin/jpackage.exe. >> >> Also in case you're not aware, you can cd >> /target/image/bin and then, assuming your package is >> org.play.proj and the main class is App, run your app by doing >> >> ./java org.play.proj.App >> >> -ernie >> > >> > To everyone who is working on NB you have my utmost respect. You are >> > doing amazing work. I’ll be doing a Jakarta EE tech talk at the >> > Eclipse foundation on June 9 at 11 AM DST and I will be using NetBeans >> > (they know I will be). >> > >> > Ken >> > >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org >> For additional commands, e-mail: dev-h...@netbeans.apache.org >> >> For further information about the NetBeans mailing lists, visit: >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >> >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org >> For additional commands, e-mail: dev-h...@netbeans.apache.org >> >> For further information about the NetBeans mailing lists, visit: >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >> >> >> >>
RE: Beta 6 Step Backwards
Got it, found it in Show Details. A tree structure might be a better UI but I now have a technique I can explain to my students. Thanks, Ken -Original Message- From: Matthias Bläsing Sent: May 30, 2020 1:24 PM To: dev@netbeans.apache.org Subject: Re: Beta 6 Step Backwards Hi, Am Samstag, den 30.05.2020, 16:13 + schrieb Kenneth Fogel: > I just loaded beta 6 and it wants to load nb-javac. The last beta I > used, beta 4, allowed me to choose with a check box if I wanted it. > So I’m curious, should I file a JIRA report or was a decision made to > return to nb-javac? Only if you can reproduce a problem. nbjavac was and will never be optional for running NetBeans Java Editing on JDK 8. It is required in that case. > I then looked into the plugins dialog where something I never noticed > before called User Installed Plugins is really nb-javac. No it is not. nbjavac is _one of several_ plugins. Ensure you check "Show details" in the plugins dialog, then the individual plugins are listed. This behaviour (to group all "non core" plugins under "User installed plugins" is in NetBeans at least since 8 and most probably even longer. > Previously, to remove it I deleted the three nb-javac files directly > from the modules folder of userdir leaving behind the JavaFX plugin. That will still work. > This time from the Plugins dialog I selected it and said to uninstall. > What happened next was bizarre, the entire modules folder that also > included the JavaFX for Windows module was deleted. You removed _all_ user installed plugins and not only nbjavac was removed, but JavaFX also. > If I restarted NetBeans and went to the plugins dialog it complained > that the Linux and Mac JavaFX plugins could not be found. What am I > missing here? I think the comments above give some insight. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
RE: jlink in JavaFX project
Too much command line for my liking. Dart board with my photo attached. Ken -Original Message- From: Geertjan Wielenga Sent: May 30, 2020 2:35 PM To: dev@netbeans.apache.org Subject: Re: jlink in JavaFX project Maybe read this: https://medium.com/azulsystems/using-jlink-to-build-java-runtimes-for-non-modular-applications-9568c5e70ef4 Gj On Sat, 30 May 2020 at 20:32, Geertjan Wielenga wrote: > What happened when you put “jlink netbeans” into Google search? I see > lots of articles... > > Gj > > On Sat, 30 May 2020 at 20:26, Kenneth Fogel > > wrote: > >> Thank you for the info. jpackage was first fxpackage, then became >> jpackage, then was dropped when FX was dropped, and then just >> returned. One of its uses was to create installable packages, either >> exe, dmg or whatever your flavour of Linux needs. >> >> I am not fond of CLI, I believe my picture is on dart boards of Linux >> aficionados everywhere 😊. I believe your CLI suggestion is using the >> system installed Java runtime on your system and not the jlink Java >> runtime. On my system if I went into the image folder I could get it >> to run with the jlink rather than system Java with "bin\java >> com.mycompany.test2.App". The old Shade plugin could do that but it >> required Java installed. I thought jlink working with jpackage could >> do that. >> >> Answering your email forced me to looking into the image folder. >> Hiding in a file called modules in the lib folder is your code. So >> when you enter "bin\java com.mycompany.test2.App" Its pulling the >> code from the images\lib\modules. Therefore it does not depend on the >> presence of a system Java. What I am not sure of is whether or not >> this image will work on a Mac or Linux, my guess is it won't. >> >> So it all comes back to what is the purpose of jlink if it doesn't >> also create something that allows you to run your code with a single >> command on the command line or as a clickable file in a GUI system. I >> appreciate that it creates an instance of Java that can run your code >> without needing to download Java first. It feels like NetBeans is not >> completing the task by just using jlink. As always I assume the >> misunderstanding of its purpose is my fault. >> >> Bringing this back to NetBeans, I think that generated code should >> include comments that either explain the purpose or provide a link to >> documentation that explains it. I think that jlink is an incomplete >> solution and that should be explained. Could explain why modules >> still have not caught on. Now I will crawl back under my rock. >> >> Ken >> >> >> -Original Message- >> From: Ernie Rael >> Sent: May 30, 2020 1:47 PM >> To: dev@netbeans.apache.org >> Subject: Re: jlink in JavaFX project >> >> On 5/30/2020 9:41 AM, Kenneth Fogel wrote: >> > >> > This is a more general question. NB 12 b6 now has a jlink option >> > for the JavaFX Simple project. Cool, I haven’t used this feature of >> > Java yet. As the module-info.java file did not indicate what to >> > include or exclude (remember I don’t know how to use jlink) I >> > believe that what was generated in the target/image folder was the >> > equivalent of a JRE. >> > I make this assumption because the folder is 60 mb in size. Heck, I >> > just searched thru the image and found keytool.exe. I should ask >> > the jlink group at Oracle about this. My ignorance is on display. >> > >> > So here is my question. Without jpackage creating an executable >> > package what is the value of jlink? >> > >> I'm not sure what you're looking for, or what jdk you're running, and >> I don't know anything about jpackage other than what I can intuit >> from the name. I think it's recent, >> >> There is: jdk-14.0.1/bin/jpackage.exe. >> >> Also in case you're not aware, you can cd >> /target/image/bin and then, assuming your package >> is org.play.proj and the main class is App, run your app by doing >> >> ./java org.play.proj.App >> >> -ernie >> > >> > To everyone who is working on NB you have my utmost respect. You >> > are doing amazing work. I’ll be doing a Jakarta EE tech talk at the >> > Eclipse foundation on June 9 at 11 AM DST and I will be using >> > NetBeans (they know I will be). >> > >> > Ken >> > >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org >> For additional commands, e-mail: dev-h...@netbeans.apache.org >> >> For further information about the NetBeans mailing lists, visit: >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >> >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org >> For additional commands, e-mail: dev-h...@netbeans.apache.org >> >> For further information about the NetBeans mailing lists, visit: >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >> >>
RE: jlink in JavaFX project - Dart Board Link
Sorry, dart board didn’t come thru. You can get it here: https://drive.google.com/drive/folders/1NtHcUOW4MWkE5kE5FE1_lQvw-K4oTxjd?usp=sharing -Original Message- From: Kenneth Fogel Sent: May 30, 2020 2:41 PM To: dev@netbeans.apache.org Subject: RE: jlink in JavaFX project Too much command line for my liking. Dart board with my photo attached. Ken -Original Message- From: Geertjan Wielenga Sent: May 30, 2020 2:35 PM To: dev@netbeans.apache.org Subject: Re: jlink in JavaFX project Maybe read this: https://medium.com/azulsystems/using-jlink-to-build-java-runtimes-for-non-modular-applications-9568c5e70ef4 Gj On Sat, 30 May 2020 at 20:32, Geertjan Wielenga wrote: > What happened when you put “jlink netbeans” into Google search? I see > lots of articles... > > Gj > > On Sat, 30 May 2020 at 20:26, Kenneth Fogel > > wrote: > >> Thank you for the info. jpackage was first fxpackage, then became >> jpackage, then was dropped when FX was dropped, and then just >> returned. One of its uses was to create installable packages, either >> exe, dmg or whatever your flavour of Linux needs. >> >> I am not fond of CLI, I believe my picture is on dart boards of Linux >> aficionados everywhere 😊. I believe your CLI suggestion is using the >> system installed Java runtime on your system and not the jlink Java >> runtime. On my system if I went into the image folder I could get it >> to run with the jlink rather than system Java with "bin\java >> com.mycompany.test2.App". The old Shade plugin could do that but it >> required Java installed. I thought jlink working with jpackage could >> do that. >> >> Answering your email forced me to looking into the image folder. >> Hiding in a file called modules in the lib folder is your code. So >> when you enter "bin\java com.mycompany.test2.App" Its pulling the >> code from the images\lib\modules. Therefore it does not depend on the >> presence of a system Java. What I am not sure of is whether or not >> this image will work on a Mac or Linux, my guess is it won't. >> >> So it all comes back to what is the purpose of jlink if it doesn't >> also create something that allows you to run your code with a single >> command on the command line or as a clickable file in a GUI system. I >> appreciate that it creates an instance of Java that can run your code >> without needing to download Java first. It feels like NetBeans is not >> completing the task by just using jlink. As always I assume the >> misunderstanding of its purpose is my fault. >> >> Bringing this back to NetBeans, I think that generated code should >> include comments that either explain the purpose or provide a link to >> documentation that explains it. I think that jlink is an incomplete >> solution and that should be explained. Could explain why modules >> still have not caught on. Now I will crawl back under my rock. >> >> Ken >> >> >> -Original Message- >> From: Ernie Rael >> Sent: May 30, 2020 1:47 PM >> To: dev@netbeans.apache.org >> Subject: Re: jlink in JavaFX project >> >> On 5/30/2020 9:41 AM, Kenneth Fogel wrote: >> > >> > This is a more general question. NB 12 b6 now has a jlink option >> > for the JavaFX Simple project. Cool, I haven’t used this feature of >> > Java yet. As the module-info.java file did not indicate what to >> > include or exclude (remember I don’t know how to use jlink) I >> > believe that what was generated in the target/image folder was the >> > equivalent of a JRE. >> > I make this assumption because the folder is 60 mb in size. Heck, I >> > just searched thru the image and found keytool.exe. I should ask >> > the jlink group at Oracle about this. My ignorance is on display. >> > >> > So here is my question. Without jpackage creating an executable >> > package what is the value of jlink? >> > >> I'm not sure what you're looking for, or what jdk you're running, and >> I don't know anything about jpackage other than what I can intuit >> from the name. I think it's recent, >> >> There is: jdk-14.0.1/bin/jpackage.exe. >> >> Also in case you're not aware, you can cd >> /target/image/bin and then, assuming your package >> is org.play.proj and the main class is App, run your app by doing >> >> ./java org.play.proj.App >> >> -ernie >> > >> > To everyone who is working on NB you have my utmost respect. You >> > are doing amazing work. I’ll be doing a Jakarta EE tech talk at the >> > Eclipse foundation on June 9 at 11 AM DST and I will be using >> > NetBeans (they know I will be). >> > >> > Ken >> > >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org >> For additional commands, e-mail: dev-h...@netbeans.apache.org >> >> For further information about the NetBeans mailing lists, visit: >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >> >> >> >> >>
Re: jlink in JavaFX project
Hi, Am Samstag, den 30.05.2020, 18:40 + schrieb Kenneth Fogel: > Too much command line for my liking. don't take this wrong, but the first thing your students should learn is, that CLI is your friend. It is the base of all automation and tools like docker, travis, jenkins, github-action would not be useful if not CLI tools existed. The other good thing is, that CLI tools have the tendency to be closer to the "real" background, so if the GUI tool of your choosing stops working or reaches the end of its preprogammed limits, CLI tools often take you farther. Just my 2cents Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NetBeans and the Octopus
https://www.zdnet.com/article/github-warns-java-developers-of-new-malware-poisoning-netbeans-projects/ On Fri, 29 May 2020 at 15:46, Jesse Glick wrote: > A further note: > > > the malware also infected any JAR files that were available in the > project, such as dependencies—not necessarily just build artifacts > > If I understand correctly what is being said here, this kind of attack > only makes sense for a build system which keeps binary dependencies in > the source tree, which of course is a bad idea anyway, but was an > aspect of the original managed Ant project type. Speaking as the > architect of that system, it should be deprecated and removed from the > default download. (If a viable version of Maven or Ivy had been > available at that time, we would have used it.) > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
