Hi,First of all, I don't have a Macintosh. However, I'm trying to support a person who does. This person is primarily a front end developer and uses a different IDE, but is slowly being brought into the server-side world.
After looking at the convoluted ways various Java providers manage multiple JDK versions, I prompted this person to install Java similar to how I install it on a Linux platform.
1. Create an /opt/Java directory 2. Install various Java versions from tar.gz files in that directory 3. Make soft links to generic directories, such as jre11, jdk11, etc. 4. Add the bin paths to the user's path 5. Add JAVA_HOME, JRE_HOME to the user's environment variablesI have then written a script that will conveniently switch paths, JAVA_HOME, and JRE_HOME based on a user-supplied argument.
In a terminal session, all of this works as expected.Using the NetBeans installer only worked because the user already had a very old version of Java installed in /Library/Java/JavaVirtualMachines. The netbeans.conf file had to be edited in order to point to the correct JDK.
The next of the problem is that NetBeans (at least from the installer, have not tried the zip or tar.gz), does not seem to be aware of the user's PATH environment variable. This was discovered as follows:
1. User has installed svn in /usr/local/bin 2. User checks out Maven project on the command line 3. User changes to that directory, and mvn package is successful 4. During the build (validate), the buildnumber MOJO executes the following: /bin/sh -c cd '/Users/auser/NetBeansProjects/aproject' && 'svn' '--username''auser' '--password' '*****' '--no-auth-cache' '--non-interactive' 'info'
This all works from the command line. In NetBeans, the svn command in the build fails with: Cannot run program "svn" (in directory "/Users/auser/NetBeansProjects/aproject"): error=2, No such file or directoryThe exact same environment works as expected on an Ubuntu 20.04 system (ksh, .kshenv, NetBeans 13 installed via snap). Subversion is installed in /usr/bin, and not /usr/local/bin as it is on the person's Macintosh.
Without .kshenv, the user's PATH does not include /usr/local/bin.I think that I could solve the above problem with a soft link from /usr/local/bin/svn* to /usr/bin, and possibly the Java issues with soft links as well into /Library/Java/JavaVirtualMachines (for the installer).
However, not having a Macintosh, I'm a bit reluctant to instruct the user to further mangle the machine.
What is the Apple-approved way of handling all of this?I will probably get a Macintosh soon just to be able to hack around with this.
Thanks for any ideas. . . . just my two cents /mde/ On 3/24/2022 11:22 AM, Alex Lewis wrote:
Hi, Just to offer an opinion of an average netbeans user regarding Netbeans and sdkman... As of Netbeans 12.1, sdkman is explicitly supported for detecting available JVMs. In my opinion it is an odd inconsistency for the main application to support sdkman but not the installer. Besides that and as far as I know, sdkman is a widely used tool for managing Java versions on macos, even with its avoidance of java_home. In which case, not supporting it in the installer impacts some amount of a large user base. By not supporting sdkman in the installer it means an additional complication at the very first step in using Netbeans and that to me feels unfortunate. If sdkman was an esoteric tool used by a small minority then I could understand any reluctance to put in the effort but, I have the impression that sdkman's user base would be large enough to warrant the effort. I obviously can't quantify that and I may be totally wrong about its popularity, if I am then I apologise. I just think that if it was important enough to include in the main application, doesn't that make it important enough to include support in the installer? The blame may be on sdkman but, as a user I have not yet suffered because of it, it's only when I try to install Netbeans that I run into an issue. If that's true for a significant volume of other users then I suspect people will believe the blame lies with Netbeans, regardless of what might be the truth. I'm happy to install a java version outside of sdkman in order to install Netbeans. I can even remove it after Netbeans is installed, which again points to only the installer needing Java to be in /Library/Java/JavaVirtualMachines. For others it might be enough for them to just give up on Netbeans and not bother, which would be a shame for Netbeans to lose (potential) users that way. I realise the answer may be "We're happy to take your contribution to the installer to add support for sdkman", and I understand why that is the case. I will certainly take a look at the installer to see if there's even a chance I could contribute something even though native macos development is not my forte but, I hope that sdkman support could be considered outside of what I may or may not be able to contribute. I'm a very happy user of Netbeans and it's clear to see Netbeans get better each and every version. I'd like to say a huge thank you to the team for the great work. Cheers On Tue, 22 Mar 2022 at 20:49, Scott Palmer <[email protected]> wrote:JDKs installed by SDKMAN don’t work with /usr/libexec/java_home. That’s why I believe SDKMAN should not be used for Java on macOS, it doesn’t integrate properly. (I brought this up to SDKMAN team and they don’t want to write any files outside of their controlled space. I get it, but the user suffers as a result.) You might be able to work around it by sym-linking the SDKMAN installed JDK into the correct location at /Libraries/Java/JavaVirtualMachines - but if you have to manage it yourself, what is SDKMAN doing for you? ScottOn Mar 22, 2022, at 1:15 PM, John Mc <[email protected]> wrote: +1 (binding) Vote Closed, I will tally up the votes later and move the artefacts over. @Djamel TORCHE <[email protected]> Sorry just seeing this now.Whatoutput do you get when you run this in your terminal"/usr/libexec/java_home"That's how the installer verifies Java exists. Maybe for NB14 I might do an RC for the macOS installer to help verify no late issues in future. JohnOn Tue, 22 Mar 2022 at 14:12, Neil C Smith <[email protected]>wrote:+1 (binding) Checksum and signature checked. Installed and ran successfully. Checked module versions match git hash. JDK 17 Temurin x86_64 running on M1 macOS 12.2.1 Thanks John!!! Best wishes, NeilOn Sat, 19 Mar 2022 at 10:11, John Mc <[email protected]>wrote:This has been a lot longer than I wanted as I got caught up with work,buthere is the updated macOS installer for Apache NetBeans 13. Primary voting artefact :https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/Apache-NetBeans-13-bin-macosx.dmgSHA512 checksum :https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/Apache-NetBeans-13-bin-macosx.dmg.sha51268cd93b697b8fa02013d4ab69f773a93c3c42f92498578470af6d808179d292649b85bdb946a9bc75d9cc94aba3d4c8e0d0a3eb3fee565ab390810ad7b609b49Apache-NetBeans-13-bin-macosx.dmg KEYS file : https://dist.apache.org/repos/dist/release/netbeans/KEYS PGP signature file :https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/Apache-NetBeans-13-bin-macosx.dmg.ascBuilt locally using the artefacts found in the Jenkins job:https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/release130/20/NOTE: The distpreparation artefact from this Jenkins job was replacedwith:https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/distpreparation.zipThe changes can be compared against the PR: https://github.com/apache/netbeans/pull/3699 This vote is going to be open at least 72 hours, vote with +1, 0, and -1 as usual. Please mark your vote with (binding) if you're an Apache NetBeans PMC member. This vote is dependent on the main Apache NetBeans 13 release votepassing.Regards John
OpenPGP_signature
Description: OpenPGP digital signature
