“ 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 is a macOS quirk. Applications launched with a double-click do not get any augmented PATH variable. The entire environment variable set for GUI apps launched by a double-click must be managed via the launchctl tool. (Even with it you may not be able to change the path in later macOS versions.) I strongly recommend to install the JDK in its expected location instead of doing Linux-y hacks. macOS is not Linux. Scott > On Mar 24, 2022, at 3:13 PM, Mark Eggers <[email protected]> > wrote: > > 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 variables > > I 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 > directory > > The 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? >>> >>> Scott >>> >>>> On 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. >>> What >>>> output 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. >>>> >>>> John >>>> >>>>> On 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, >>>>> >>>>> Neil >>>>> >>>>>> On 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, >>>>> but >>>>>> here 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.dmg >>>>>> >>>>>> SHA512 checksum : >>>>>> >>>>> >>> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/Apache-NetBeans-13-bin-macosx.dmg.sha512 >>>>>> >>>>>> >>>>> >>> 68cd93b697b8fa02013d4ab69f773a93c3c42f92498578470af6d808179d292649b85bdb946a9bc75d9cc94aba3d4c8e0d0a3eb3fee565ab390810ad7b609b49 >>>>>> Apache-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.asc >>>>>> >>>>>> Built 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 replaced >>>>> with: >>>>>> >>>>> >>> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/distpreparation.zip >>>>>> The 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 vote >>>>> passing. >>>>>> >>>>>> Regards >>>>>> >>>>>> John > <OpenPGP_signature>
